Ανάπτυξη Συστήματος Σύνθεσης Υπηρεσιών Ιστού

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ - ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ Ανάπτυξη Συστήματος Σύνθεσης Υπηρεσιών Ιστού Διπλωματική Εργασία του Σιδηρόπουλου Ανέστη (ΑΕΜ: 1537) Επιβλέπων Καθηγητής: Δημήτριος Βράκας ΘΕΣΣΑΛΟΝΙΚΗ Φεβρουάριος i-

2 Πρόλογος Το αντικείμενο της παρούσας πτυχιακής είναι η σύνθεση υπηρεσιών διαδικτύου οι οποίες περιγράφονται σε γλώσσα W.S.D.L. Για το σκοπό αυτό υλοποιήθηκε το εργαλείο Web Planner, το οποίο εκτελεί ανάλυση εγγράφων W.S.D.L. και σύνθεση υπηρεσιών. Το θέμα της εργασίας ανήκει στο πλαίσιο των πτυχιακών εργασιών του εργαστηρίου P.L.A.S.E. κατά τη διάρκεια του έτους Η εκπόνηση της εργασίας έγινε στο Εργαστήριο Γλωσσών Προγραμματισμού και Τεχνολογίας Λογισμικού του Τμήματος Πληροφορικής του Αριστοτελείου Πανεπιστημίου Θεσσαλονίκης και σε συνεργασία με την ομάδα Λογισμικού Προγραμματισμού και Ευφυών Συστημάτων (LPIS) του τμήματος. Θερμές ευχαριστίες στον κ. Δημήτριο Βράκα, ο οποίος ήταν ο επιβλέπων καθηγητής καθώς και σε οποιονδήποτε στήριξε με τον τρόπο του την προσπάθεια κατά τη διάρκεια της πτυχιακής. Σιδηρόπουλος Ανέστης 1/2/2011 -i-

3 Περιεχόμενα ΠΡΌΛΟΓΟΣ...I ΠΕΡΙΕΧΌΜΕΝΑ...II 1 ΕΙΣΑΓΩΓΉ ΥΠΗΡΕΣΊΕΣ ΔΙΑΔΥΚΤΊΟΥ, ΠΡΩΤΌΚΟΛΛΑ ΚΑΙ ΑΡΧΙΤΕΚΤΟΝΙΚΈΣ ΠΕΡΙΓΡΑΦΉ ΚΑΙ ΣΎΝΘΕΣΗ ΥΠΗΡΕΣΙΏΝ ΔΙΑΔΙΚΤΎΟΥ ΤΟ ΕΡΓΑΛΕΊΟ WEB PLANNER ΣΥΜΠΕΡΆΣΜΑΤΑ ΚΑΙ ΜΕΛΛΟΝΤΙΚΈΣ ΚΑΤΕΥΘΎΝΣΕΙΣ ΒΙΒΛΙΟΓΡΑΦΊΑ ii-

4 1 Εισαγωγή Οι υπηρεσίες διαδικτύου αποτελούν μια αναδυόμενη τεχνολογία που καθιστά εφικτό σε ανόμοιες εφαρμογές, οι οποίες εκτελούνται σε διαφορετικές μηχανές, να ανταλλάσσουν δεδομένα και να συνεργάζονται μεταξύ τους χωρίς να απαιτούνται επιπρόσθετα ιδιόκτητα λογισμικά ή τμήματα υλικού. Εφαρμογές που βασίζονται στο παράδειγμα των υπηρεσιών διαδικτύου μπορούν να ανταλλάσσουν δεδομένα ασχέτως προγραμματιστικής γλώσσας, πλατφόρμας ή εσωτερικών πρωτοκόλλων που χρησιμοποιούν. Οι υπηρεσίες διαδικτύου αποτελούν τμήματα λογισμικού, προσβάσιμα μέσω δικτύου, τα οποία εκτελούν συμπαγείς επιχειρησιακές λειτουργίες και μπορούν να υλοποιηθούν εύκολα διότι βασίζονται σε κοινά βιομηχανικά πρότυπα και υπάρχουσες τεχνολογίες, όπως XML και HTTP. Μειώνουν το κόστος του interface των εφαρμογών και παρέχουν ένα καθολικό μηχανισμό για τη συνεργασία των επιχειρησιακών διαδικασιών αρχικά στο πλαίσιο μόνο μιας επιχείρησης και έπειτα πολλαπλών. Η σύνθεση των υπηρεσιών διαδικτύου αποτελεί ένα ζήτημα που έχει προσελκύσει το ενδιαφέρον κύριως σε θέματα συνεργασίας και ολοκλήρωσης επιχειρήσεων. Δίνει τη δυνατότητα σε προγραμματιστές να δημιουργούν εφαρμογές βασισμένες στην περιγραφή του υπολογισμού που περιστρέφεται γύρω από υπηρεσίες (Service Oriented Computing). Τέτοιες εφαρμογές αναπτύσσονται ραγδαία και δίνουν τη δυνατότητα επαναχρησιμοποίησης στον προγραμματιστή και τη δυνατότητα χρήσης πολύπλοκων υπηρεσιών στον χρήστη. Στα επόμενα τρία κεφάλαια η πτυχιακή ασχολείται με θέματα που σχετίζονται με τις υπηρεσίες ιστού, πρωτόκολλα, αρχιτεκτονικές, τόπους περιγραφής και σύνθεσής τους καθώς και με το εργαλείο Web Planner. -1-

5 2 Υπηρεσίες διαδυκτίου, πρωτόκολλα και αρχιτεκτονικές Το κεφάλαιο αυτό ασχολείται με τις υπηρεσίες διαδικτύου (Web Services),τις διαφορές των υπηρεσιών διαδικτύου από τις Web-based εφαρμογές και τα components που διανέμονται, τα χαρακτηριστικά και τις προϋποθέσεις που πρέπει να πληρούν οι υπηρεσίες διαδικτύου τα κριτήρια ποιότητας μιας υπηρεσίας (quality of web service), την τεχνολογική στοίβα των υπηρεσιών διαδικτύου, το πρωτόκολλο SOAP, τις αρχιτεκτονικές που περιστρέφονται γύρω από υπηρεσίες (service-oriented architectures- S.O.A.) και τον δίαυλο Enterprise Service Bus. 2.1 Ορισμός υπηρεσίας διαδικτύου (Web Service) Μία Web Service είναι μια διαπλατφορμική (platform-independent) χαλαρής σύνδεσης(loosely coupled) προγραμματιστική εφαρμογή, η οποία μπορεί να περιγραφεί, δημοσιευθεί, ανακτηθεί, συντονισθεί και να διαμορφωθεί με τη χρήση XML τεχνικών με σκοπό να αναπτυχθούν διανεμημένες εφαρμογές με δυνατότητες συνεργασίας μεταξύ τους. Ας αναλύσουμε όμως αυτόν τον ορισμό: Οι υπηρεσίες διαδικτύου είναι χαλαρής σύνδεσης μονάδες λογισμικού, γεγονός που τις διαχωρίζει από τις προγενέστερες διανεμημένες αρχιτεκτονικές υπολογισμού. Ο όρος loosely-coupled αναφέρεται στα πρωτόκολλα, στο interface και στις υπηρεσίες μητρώου (registry) που καθορίζουν τον τρόπο που συνεργάζονται οι υπηρεσίες. Για να επιτευχθεί αυτό, το interface της υπηρεσίας προσδιορίζεται με ουδέτερο τρόπο δηλ, με τέτοιο τρόπο ώστε να είναι ανεξάρτητο από το λειτουργικό σύστημα, την πλατφόρμα και τη γλώσσα προγραμματισμού στην οποία αναπτύχθηκε. Έτσι οι υπηρεσίες μπορούν να αλληλεπιδρούν καθολικά. Οι υπηρεσίες διαδικτύου περικλείουν ξεχωριστή σημασιολογική λειτουργικότητα. Κάθε υπηρεσία αποτελεί μια αυτό συντηρούμενη(self contained) μονάδα λογισμικού που εκτελεί μια απλή λειτουργία. Αυτή η μονάδα περιγράφει η ίδια -2-

6 τα χαρακτηριστικά του interface της όπως τις διαθέσιμες λειτουργίες, τις παραμέτρους που χρησιμοποιεί, τους τύπους δεδομένων, τα πρωτόκολλα με τέτοιο τρόπο ώστε άλλες υπηρεσίες να μπορούν να προσδιορίσουν τι λειτουργία εκτελεί, να επικαλεσθούν τη λειτουργικότητα της και τι αποτέλεσμα να περιμένουν να τους επιστραφεί. Επίσης από τη στιγμή που οι υπηρεσίες περιγράφουν οι ίδιες τα χαρακτηριστικά του interface τους δίνουν τη δυνατότητα σε πελάτες να συνδέονται με αυτήν. Οι υπηρεσίες διαδικτύου είναι προγραμματιστικά προσβάσιμες ( programmatically accessed). Αυτή η ιδιότητα επιτρέπει στις υπηρεσίες να ενσωματώνονται σε εφαρμογές που βρίσκονται σε διαφορετικές απομακρυσμένες τοποθεσίες. Έτσι η πληροφορία μπορεί να διατυπώνεται και να ανανεώνεται με αποτέλεσμα να βελτιώνεται η αποδοτικότητα, η ανταπόκριση και η ακρίβεια τους. Οι υπηρεσίες μπορούν να βρεθούν δυναμικά και να ενσωματωθούν σε εφαρμογές. Οι υπηρεσίες περιγράφονται ακολουθώντας τα πρότυπα της WSDL( Web Service Description Language). Μέσω αυτής της γλώσσας περιγράφουμε λειτουργικά και μη χαρακτηριστικά της υπηρεσίας όπως π.χ. χαρακτηριστικά που περιγράφουν τη γενική συμπεριφορά της, Οι υπηρεσίες διαδικτύου διανέμονται μέσω Internet. Οι υπηρεσίες χρησιμοποιούν ήδη υπάρχοντα πρωτόκολλα μεταφοράς όπως το HTTP. -3-

7 2.2 Διαφορές των υπηρεσιών με τις Web-based εφαρμογές και τα components που διανέμονται Σ αυτό το σημείο πρέπει να διαχωρίσουμε τις υπηρεσίες διαδικτύου από τις Web-based εφαρμογές και τα components. Όσον αφορά τις Web-based εφαρμογές διακρίνονται οι εξής διαφορές : 1. Οι υπηρεσίες διαδικτύου μπορούν να χρησιμοποιηθούν ως πηγές δεδομένων όχι μόνο από ανθρώπους αλλά και από άλλες υπηρεσίες διαδικτύου σε αντίθεση με τις webbased εφαρμογές. 2. Οι web-based εφαρμογές δεν μπορούν να περιγράψουν τα μη λειτουργικά χαρακτηριστικά τους. 3. Οι υπηρεσίες διαδικτύου είναι περισσότερο ορατές και ευκολότερα διαχειρίσημες από τις we-based εφαρμογές. Αυτό συμβαίνει γιατί μέσω συστημάτων workflow και εφαρμογών εξωτερικής διαχείρισης μπορούμε να παρακολουθούμε την κατάσταση της υπηρεσίας και να την διαχειριζόμαστε ασχέτως με τη γλώσσα στην οποία αναπτύχθηκε και τη τοποθεσία της. 4. Σε αντίθεση με τις Web-based εφαρμογές οι υπηρεσίες διαδικτύου, μπορούν να βγουν σε δημοπρασίες. Αν για παράδειγμα υπάρχουν πολλές υπηρεσίες που εκτελούν την ίδια λειτουργία, τότε διάφορες εφαρμογές προσφέρουν τιμές για να μπορέσουν να την χρησιμοποιήσουν. Η ανταγωνιστικότητα αναφέρεται σε μεταβλητές όπως κόστος ταχύτητα και ασφάλεια. Όσον αφορά τα components εντοπίζουμε διαφορές στα εξής σημεία : 1. Τρόπος επικοινωνίας 2. Είδος του coupling 3. Τύπος του interface 4. Τρόπος αναφοράς (ή τρόπος κλήσης) 5. Τρόπος διεκδίκησης στις δημοπρασίες -4-

8 2.3 Χαρακτηριστικά και προυποθέσεις των υπηρεσιών διαδικτύου Τα χαρακτηριστικά στα οποία θα αναφερθώ είναι τα εξής : 1. Τύποι υπηρεσιών, 2. Λειτουργικές και μη ιδιότητες, 3. Ιδιότητες κατάστασης των υπηρεσιών, 4. Loose coupling, 5. Σύνθεση 6. Συγχρονισμός 7. Επαρκής ορισμός 8. Περιεχόμενο της υπηρεσίας με βάση το σκοπό χρήσης της Τύποι υπηρεσιών Τοπολογικά οι υπηρεσίες μπορούν να διαχωριστούν σε δύο κατηγορίες, τις informational (type I) υπηρεσίες οι οποίες υποστηρίζουν μόνο απλές request/response λειτουργίες και ενεργοποιούνται μόνο αν γίνει κάποιο request και τις complex ( type II) υπηρεσίες, οι οποίες εφαρμόζουν μια μορφή συνεργασίας μεταξύ εσωτερικών(inbound) και εξωτερικών(outbound) λειτουργιών. Πιο συγκεκριμένα : Απλές (ή informational) υπηρεσίες Πρόκειται για υπηρεσίες σχετικά απλής φύσης οι οποίες είτε παρέχουν πρόσβαση σε περιεχόμενο μέσω αλληλεπίδρασης με κάποιον χρήστη (με χρήση request/response ακολουθιών) είτε να χρησιμοποιηθούν από άλλες εφαρμογές. Οι απλές υπηρεσίες διακρίνονται σε 3 υποκατηγορίες : 1. Pure content services (υπηρεσίες αμιγούς περιεχομένου), οι οποίες δίνουν πρόσβαση σε περιεχόμενο όπως προβλέψεις καιρού κ.α. 2. Simple trading Services (απλές υπηρεσίες συναλλαγών), οι οποίες αποτελούν πιο πολύπλοκες μορφές υπηρεσιών παρέχουν ενιαία ομαδοποίηση πληροφο- -5-

9 ρίας την οποία αντλεί από διαφορετικές πηγές με σκοπό να λαμβάνονται ενημερωμένες αποφάσεις. 3. Information syndication services, οι οποίες εμφανίζονται ως plug into σε sites με αγοροπωλησίες διαφόρων ειδών. Τέλος οι απλές υπηρεσίες δεν επηρεάζουν τις πηγές από τις οποίες αντλούν δεδομένα (data store) με αποτέλεσμα αυτές να μένουν σε σταθερή κατάσταση. Μια απλή υπηρεσία δεν κρατά στη μνήμη τι συμβαίνει μεταξύ των requests. Για τους παραπάνω λόγους οι απλές υπηρεσίες ονομάζονται και Stateless υπηρεσίες διαδικτύου Λειτουργικές και μη ιδιότητες Οι λειτουργικές ιδιότητες αναφέρονται στα χαρακτηριστικά που καθορίζουν την συνολική συμπεριφορά της υπηρεσίας όπως π.χ. λεπτομέρειες για το πώς ενσωματώνεται η υπηρεσία σε κάποια εφαρμογή. Η λειτουργική περιγραφή των υπηρεσιών επικεντρώνεται περισσότερο σε λεπτομέρειες που αφορούν τη σύνταξη των μηνυμάτων και το ποια πρωτόκολλα θα χρησιμοποιηθούν για την ανταλλαγή τους. Οι μη λειτουργικές ιδιότητες αναφέρονται σε ποιοτικές παραμέτρους της υπηρεσίας όπως π.χ. χρόνος απόκρισης και ακρίβεια, παραμέτρους ασφάλειας, αυθεντικότητα, αξιοπιστία κ.α Ιδιότητες κατάστασης των υπηρεσιών, Οι υπηρεσίες μπορούν να διαχωριστούν σε stateless και stateful. Μια υπηρεσία ονομάζεται stateless εάν μπορεί κάποιος να την επικαλείται συνεχόμενα χωρίς να πρέπει να διατηρεί πληροφορίες για την κατάσταση (state) της. Σε αντίθετη περίπτωση, όταν δηλαδή όταν πρέπει να κρατάμε πληροφορία μεταξύ των κλήσεων, η υπηρεσία ονομάζεται stateful. To πρωτόκολλο πρόσβασης της υπηρεσίας είναι πάντα connectionless. Ένα connectionless πρωτόκολλο είναι το πρωτόκολλο που δεν έχει αντίληψη μιας διεργασίας και δεν κάνει υποθέσεις για ενδεχόμενη παράδοση. -6-

10 2.3.4 Χαλαρή Σύνδεση (Loose coupling) Ο όρος coupling αναφέρεται γενικά στο βαθμό ανεξαρτησίας που παρουσιάζουν δυο οποιαδήποτε συστήματα μεταξύ τους. Υπάρχουν 2 είδη coupling το tight και το loose coupling. Συνοπτικά όσον αφορά το tight coupling, οι εφαρμογές πρέπει να γνωρίζουν πως συμπεριφέρονται οι άλλες εφαρμογές με τις οποίες θα συνεργαστούν, λεπτομέρειες σχετικά με το πώς θα επικοινωνήσουν, τι μεθόδους περιέχουν κ.α. Στην αντίθετη περίπτωση (Loose Coupling) τα συστήματα μπορούν να συνδεθούν και να αλληλεπιδρούν πιο «ελεύθερα». Σε μια τέτοια διαδικασία ανταλλαγής, οι εφαρμογές δεν χρειάζεται να διατηρούν γνώση για τον τρόπο λειτουργίας των άλλων εφαρμογών. Το βασικό πλεονέκτημα είναι ότι οι εφαρμογές μπορούν να χρησιμοποιούν ασύγχρονα μοντέλα αλληλεπίδρασης με αποτέλεσμα να παρέχεται ένα επίπεδο προσαρμοστικότητας και συνεργασίας την οποία δε συναντάμε σε περιβάλλοντα που έχουν παρόμοια λειτουργικά χαρακτηριστικά με τις υπηρεσίες διαδικτύου (διαπλατφορμικότητα κ.λπ.). Έτσι όταν κάποιος κάνει request σε μια υπηρεσία δεν γνωρίζει λεπτομέρειες όπως τη γλώσσα στην οποία προγραμματίστηκε η υπηρεσία, σε ποια πλατφόρμα αναπτύχθηκε διότι δεν του χρειάζονται Σύνθεση-Δομή Οι υπηρεσίες διαδικτύου εκτελούν ένα μεγάλο πλήθος από λειτουργίες, από τις πιο απλές (request/response) μέχρι τις πιο πολύπλοκες ( περίπλοκα συστήματα που αντλούν πληροφορίες από πολλές και διαφορετικές πηγές ). Συνήθως οι απλές υπηρεσίες πληρούν τα κριτήρια ώστε να θεωρούνται καλώς δομημένες. Ωστόσο σε περιπτώσεις περίπλοκων υπηρεσιών, απαιτούνται μεγαλύτερες δομές δεδομένων Συγχρονισμός Ο συγχρονισμός στις υπηρεσίες διαδικτύου μπορεί να επιτευχθεί μέσω από δυο προγραμματιστικά στυλ, το συγχρονισμένο (ή αλλιώς RPC) και το μη συγχρονισμένο (ή message style). Έτσι προκύπτει ο διαχωρισμός σε συγχρονισμένες και μη υπηρεσίες. Στην πρώτη περίπτωση οι χρήστες των υπηρεσιών εκφράζουν την επιθυμία χρήσης (request) ως μια κλήση μεθόδου που δέχεται ως είσοδο ένα πλήθος παραμέτρων και επιστρέφει μία τιμή που αναφέρεται στην απόκριση (response). Σε ένα τέτοιο σενάριο εάν για οποιοδήποτε λόγο κάποια εφαρμογή αποτύχει θα αποτύχουν και όλες οι άλλες. -7-

11 Έτσι οι RPC υπηρεσίες διαδικτύου χρησιμοποιούνται όταν ο πελάτης που καλεί την υπηρεσία θέλει άμεση απόκριση και ο πελάτης και η υπηρεσία επικοινωνούν με το πρότυπο back-and-forth. Όσον αφορά τη δεύτερη περίπτωση, οι μη συγχρονισμένες υπηρεσίες είναι υπηρεσίες που βασίζονται σε έγγραφα (ή ανταλλαγή μηνυμάτων). Όταν κάποιος καλεί την υπηρεσία ουσιαστικά αποστέλλει σ αυτήν ένα ολόκληρο έγγραφο παρά ένα πλήθος από παραμέτρους. Το επόμενο βήμα είναι η αποδοχή του από την υπηρεσία η επεξεργασία του και αποστολή (ή όχι) κάποιου αποτελέσματος. Σε αντίθεση με τις συγχρονισμένες υπηρεσίες ο «πελάτης» δεν αναμένει απόκριση από την υπηρεσία και συνεχίζει την εκτέλεση του τμήματος της εφαρμογής που έπεται. Η απόκριση μπορεί να φτάσει ώρες (ή και μέρες αργότερα). Οι ασύγχρονες υπηρεσίες χρησιμοποιούνται όταν ο πελάτης δεν επιθυμεί άμεση (χρονικά) απάντηση και η υπηρεσία είναι service-oriented (ο πελάτης στέλνει ένα ολόκληρο έγγραφο π.χ. εντολή αγοράς) Επαρκής ορισμός Ένα βασικό χαρακτηριστικό των διαδικτυακών υπηρεσιών είναι η αλληλεπίδραση τους να είναι καλώς ορισμένη. Η WSDL δίνει τη δυνατότητα στις υπηρεσίες να περιγράφουν τους κανόνες της διεπαφής και αλληλεπίδρασης παρέχοντας ένα μηχανισμό περιγραφής θεωρητικών (abstract) Interface των υπηρεσιών. Η περιγραφή αυτή επικεντρώνεται περισσότερο στον τρόπο που οι λειτουργίες αλληλεπιδρούν με την υπηρεσία, τα μηνύματα καλούν τις υπηρεσίες, οδηγίες για την σύνταξη τέτοιων μηνυμάτων και την τοποθεσία που πρέπει να σταλούν αυτά. Είναι σημαντικό σ αυτό το σημείο να αναφερθεί ότι η WSDL δεν περιλαμβάνει τεχνικές λεπτομέρειες για την εφαρμογή της υπηρεσίας (π.χ. γλώσσα στην οποία προγραμματίστηκε) γιατί από τη στιγμή που η υπηρεσία μπορεί να χειρίζεται μηνύματα (SOAP messages) δεν έχει σημασία σε ποια πλατφόρμα αναπτύχθηκε. -8-

12 2.3.8 Περιεχόμενο της υπηρεσίας με βάση το σκοπό χρήσης της. Είναι χρήσιμο να κατηγοριοποιούμε τις υπηρεσίες διαδικτύου ανάλογα με την προοπτική αυτού που την επιθυμεί. Έτσι προκύπτει ο εξής διαχωρισμός των υπηρεσιών σε replaceable και mission-critical. Μια replaceable υπηρεσία παρέχεται από αρκετούς παροχείς και η αντικατάσταση κάποιου από αυτούς με κάποιον άλλο δεν θα επηρεάσει την εφαρμογή λειτουργικά όσο τα interface της υπηρεσίας είναι πανομοιότυπα. Επίσης η παραγωγικότητα της υπηρεσίας δεν θα έχει κανέναν αντίκτυπο εάν η υπηρεσία δεν είναι διαθέσιμη για κάποιο χρονικό διάστημα γιατί θα βρεθεί κάποιος άλλος παροχέας. Μια mission-critical υπηρεσία παρέχεται από ένα και μοναδικό παροχέα ο οποίος αν αντικατασταθεί τίθεται σε ρίσκο η λειτουργικότητα όλης της εφαρμογής. Εάν η υπηρεσία δεν είναι διαθέσιμη για κάποιο χρονικό διάστημα θα μειωθεί δραματικά η παραγωγικότητα της εφαρμογής. 2.4 Κριτήρια ποιοτικότητας των υπηρεσιών διαδικτύου Μια πολύ σημαντική απαίτηση των εφαρμογών είναι να εκτελούνται με τέτοιο τρόπο ώστε να λειτουργούν αξιόπιστα και να αποδίδουν συνεπείς υπηρεσίες. Αυτό απαιτεί μεγάλη προσοχή όχι μόνο στις λειτουργικές ιδιότητες της υπηρεσίας αλλα και στην περιγραφή του περιβάλλοντος που «φιλοξενεί» την υπηρεσία. Είναι προφανές λοιπόν ότι η ποιοτηκότητα της υπηρεσίας είναι ένα θέμα που έχει μεγάλη βαρύτητα τόσο για τους παροχείς όσο και για τους πελάτες. Η ποιοτηκότητα της υπηρεσίας αναφέρεται στη δυνατότητα της υπηρεσίας να ανταποκρίνεται σε αναμενόμενες κλήσεις της και να τις εκπληρώνει σε βαθμό που να είναι ικανοποιητικός σύμφωνα με τις απαιτήσεις τόσο του παροχέα όσο και του πελάτη. Μέτρα της ποιοτικότητας μιας υπηρεσίας είναι ένα πλήθος χαρακτηριστικών. Αυτά τα χαρακτηριστικά αποτελούν αναγκαίες προϋποθέσεις ώστε να γίνει κατανοητή η καθολική συμπεριφορά της υπηρεσίας έτσι ώστε άλλες εφαρμογές και υπηρεσίες μπορούν να συνδεθούν με αυτήν και να την εκτελέσουν ως τμήμα της διαδικασίας. Συγκεκριμένα τα στοιχεία που καθορίζουν την ποιοτηκότητα των υπηρεσιών διαδικτύου είναι τα εξής : -9-

13 Διαθεσιμότητα : αποτελεί την πιθανότητα μια υπηρεσία να είναι διαθέσιμη. Μεγάλες τιμές της παραμέτρου αυτής δείχνουν ότι η υπηρεσία αυτή είναι πάντα έτοιμη για χρήση ενώ μικρές δείχνουν ότι δεν μπορούμε να προβλέψουμε εάν η υπηρεσία είναι διαθέσιμη σε κάποια συγκεκριμένη χρονική στιγμή. Μια ακόμα παράμετρος που σχετίζεται με την διαθεσιμότητα είναι ο χρόνος επισκευής ( Time to Repair ) δηλ, ο χρόνος που απαιτείται για να επιδιορθωθεί η υπηρεσία εάν αποτύχει. Προφανώς είναι προτιμότερο να έχει μικρή τιμή. Προσβασιμότητα : αντιπροσωπεύει τον βαθμό που εξυπηρετείται μια κλήση κάποιας υπηρεσίας. Μπορεί να εκφραστεί επίσης ως την μέτρηση της πιθανότητας που υποδηλώνει το ποσοστό επιτυχίας για κάποια χρονική στιγμή. Μεγάλες τιμές της παραμέτρου υποδηλώνουν ότι μια υπηρεσία είναι διαθέσιμη για μεγάλο αριθμό πελατών και ότι αυτοί μπορούν να την χρησιμοποιούν σχετικά εύκολα. Συμφωνία ως προς τα πρότυπα : περιγράφει τον αν η υπηρεσία είναι σύμφωνη με τα πρότυπα. Η αυστηρή προσκόλληση σε σωστές εκδόσεις των προτύπων από τη μεριά των παροχέων είναι απαραίτητη για τη σωστή κλήση της υπηρεσίας από τους πελάτες. Ακεραιότητα : περιγράφει τον βαθμό στον οποίο μια υπηρεσία εκτελεί μία εργασία με βάση την WSDL περιγραφή της καθώς επίσης και τον βαθμό συμφωνίας ως προς την SLA (Service Level Agreement). Επίδοση : η επίδοση μετριέται μέσω δύο συντελεστών, του συνολικού όγκου έργου και του χρόνου λανθάνουσας κατάστασης. Ο συνολικός όγκος του έργου αναπαριστά το πλήθος των requests για την υπηρεσία που εξυπηρετούνται για μια δεδομένη χρονική περίοδο ενώ ο χρόνος λανθάνουσας κατάστασης αναπαριστά το τμήμα του χρόνου μεταξύ της αίτησης και της απόκρισης. Αξιοπιστία : αναπαριστά την δυνατότητα της υπηρεσίας να λειτουργεί ορθά και με συνέπεια καθώς και τη δυνατότητα να παρέχει την ίδια ποιότητα ανεξαρτήτως συστήματος και σφαλμάτων δικτύου. η αξιοπιστία μετράται ως ο αριθμός των αποτυχημένων συναλλαγών ανά μήνα ή χρόνο. Κλιμάκωση (Scalability) : αναφέρεται στη δυνατότητα της συνεπούς εξυπηρέτησης των αιτήσεων προς την υπηρεσία ανεξαρτήτως του πλήθους των αιτήσεων που γίνονται. -10-

14 Ασφάλεια : η ασφάλεια αναφέρεται έννοιες όπως αυθεντικότητα, εξουσιοδότηση, ακεραιότητα μηνυμάτων και εμπιστευτικότητα. Δυνατότητα διενέργειας : υπάρχουν αρκετές περιπτώσεις στις οποίες απαιτείται τέτοια συμπεριφορά καθώς και αναπαραγωγή περιεχομένου. Το αν μια υπηρεσία πρέπει να επιδεικνύει τέτοια συμπεριφορά καθορίζεται από την SLA (Service Level Agreement). Σ αυτό το σημείο θα αναφερθώ στην έννοια της Service Level Agreement (S.L.A.). πρόκειται για μια επίσημη συμφωνία μεταξύ ενός παροχέα και ενός πελάτη στην οποία επισημοποιούνται οι λεπτομέρειες της υπηρεσίας (περιεχόμενα, τιμή, κριτήρια ποιότητας κα) με τέτοιο τρόπο ώστε να επιτυγχάνεται αμοιβαία συνεννόηση και ικανοποίηση τόσο των παροχέων όσο και των πελατών. Μια SLA περιέχει τα εξής : 1. Στόχος : λόγος δημιουργίας της SLA, 2. Τμήματα : περιγράφει ποιοι συμμετέχουν στην SLA και ποιος είναι ο ρόλος τους, 3. Περίοδος εγκυρότητας : περιγράφει την χρονική περίοδο για την οποία η SLA είναι έγκυρη και ισχύει, 4. Πλαίσιο : ορίζονται ποιες υπηρεσίες θα συμμετέχουν στη συμφωνία, 5. Περιορισμοί : περιγράφει τα βήματα που πρέπει να ακολουθηθούν για να γίνει η παροχή της υπηρεσίας, 6. Επιδιώξεις : καθορίζονται τα επίπεδα στα οποία συμφωνούν οι παροχείς και οι πελάτες και περιλαμβάνει δείκτες όπως διαθεσιμότητα, εκτέλεση και αξιοπιστία. 7. Ποινές : αναφέρεται στις ποινές απέναντι στους παροχείς στην περίπτωση που αυτοί δεν μπορούν να ανταπεξέλθουν στους όρους της συμφωνίας. 8. Προαιρετικές υπηρεσίες : αναφέρονται οι όποιες υπηρεσίες δεν θα χρειαστούν στον χρήστη υπό φυσιολογικές συνθήκες αλλά σε περιπτώσεις εξαιρέσεων απαιτούνται, 9. Όροι εξαίρεσης : αναφέρεται σε ότι δεν περιλαμβάνεται στη συμφωνία ώστε να επιτυγχάνεται ακόμα πιο σωστός ορισμός της, -11-

15 10. Διαχείριση : περιγράφει τις διεργασίες και τους στόχους της συμφωνίας και καθορίζει την ιεραρχία. Τέλος μια SLA μπορεί να είναι είτε στατική είτε δυναμική. 2.5 Η τεχνολογική στοίβα των υπηρεσιών διαδικτύου Εικόνα 2.1 Ο σκοπός της τεχνολογίας των υπηρεσιών είναι να επιτρέπει σε εφαρμογές να συνεργάζονται σύμφωνα με τα πρωτόκολλα του διαδικτύου χωρίς άμεση ανθρώπινη παρέμβαση βελτιώνοντας έτσι την αποδοτικότητα. Οι υπηρεσίες διαδικτύου δεν εφαρμόζονται ενιαία αλλά αναπαριστώνται από μια συλλογή από τεχνολογίες που συσχετίζονται. Στο σχήμα παρουσιάζονται τα σημαντικότερα πρότυπα τα οποία ακολουθεί η τεχνολογία των υπηρεσιών. Αυτά τα πρότυπα είναι τα εξής : Πρότυπα ενεργοποίησης της τεχνολογίας (enable technologies). Αν και δεν είναι υποχρεωτική η χρήση συγκεκριμένων πρωτοκόλλων επικοινωνίας οι υπηρεσίες υλοποιούνται με βάση την καθολική παροχή διαδικτύου και έχοντας ως στόχο να διασφαλίζεται η παγκόσμια πρόσβαση και υποστήριξη. Για παράδειγμα όσον αφορά τα πρω- -12-

16 τόκολλα μεταφοράς οι υπηρεσίες χρησιμοποιούν το πρωτόκολλο HTTP που είναι το ίδιο που χρησιμοποιείται από τους severs και browsers στο internet. Μια ακόμα τεχνολογία που χρησιμοποιείται είναι η XML για την ανταλλαγή δεδομένων και της σημασιολογίας τους. Πρότυπα πυρήνα υπηρεσιών(core service). Τα πρότυπα αυτά είναι : 1. Simple Object Access Protocol (SOAP). Αποτελεί ένα πρωτόκολλο μηνυμάτων βασισμένο στην XML μέσω του οποίου οι υπηρεσίες ανταλλάσουν πληροφορία. Χρησιμοποιεί το HTTP για τη μεταφορά δεδομένων και περιγράφει ένα μοντέλο request/response για την επικοινωνία μεταξύ υπηρεσιών που συνεργάζονται. 2. Web Service Description Language (WSDL). Μέσω της WSDL περιγράφουμε με σταθερούς τρόπους τις διεργασίες και τα δεδομένα μέσα σε μια υπηρεσία έτσι ώστε να αντιλαμβανόμαστε καλύτερα τις δυνατότητες που παρέχει μια υπηρεσία. 3. Service Publication (UDDI). Η κοινοποίηση των υπηρεσιών γίνεται μέσω UDDI, που αποτελεί ένα κοινόχρηστο κατάλογο στον οποί μπορούν εταιρίες να δημοσιεύουν προδιαγραφές για τις υπηρεσίες που παρέχουν ενώ άλλες επιχειρήσεις μπορούν να έχουν πρόσβαση σ αυτές. Πρότυπα σύνθεσης και συνεργασίας υπηρεσιών. Πρόκειται για τα εξής πρότυπα : 1. Σύνθεση υπηρεσίας. Εδώ περιγράφεται η λογική της εκτέλεσης των εφαρμογών μέσα σε μια υπηρεσία προσδιορίζοντας τα διαγράμματα ελέγχου ( υπό συνθήκες, ακολουθιακό, παράλληλο, με εξαιρέσεις εκτέλεση ) και επιτάσσονται οι κανόνες για συνεπή διαχείριση των μη παρακολουθήσιμων δεδομένων. Αυτό επιτυγχάνεται με τη χρήση της Business Process Execution Language (BPEL). 2. Συνεργασία υπηρεσιών. Αυτό το πρότυπο περιγράφει την δια επιχειρησιακή συνεργασία όσων συμμετέχουν στην υπηρεσία προσδιορίζοντας την συμπεριφορά που παρατηρείται, όπου συγχρονισμένες ανταλλαγές δεδομένων πραγματοποιούνται μέσα από τους κοινούς διαύλους επικοινωνίας. Η συνεργασία των υπηρεσιών υλοποιείται μέσω της Web Service Choreography Description Language (WS-CDL). -13-

17 3. Πρότυπα συντονισμού/διενέργειας. Η επίλυση προβλημάτων σχετικών με την εύρεση και ανάκτηση της περιγραφής των υπηρεσιών έχει καταλυτική σημασία στην επιτυχία μιας υπηρεσίας. Τα πρότυπα συντονισμού και διενέργειας σε συνεργασία με την BPEL παρέχουν μηχανισμούς για τον προσδιορισμό πρωτοκόλλων προς χρήση μέσω συστημάτων επεξεργασίας συναλλαγών και εφαρμογών που έχουν ως στόχο τον συντονισμό πολλαπλών υπηρεσιών. 4. Επιπρόσθετα πρότυπα. Επιπρόσθετα στοιχεία τα οποία υποστηρίζουν συνθέτες επιχειρησιακές συναλλαγές πρέπει να χρησιμοποιηθούν πριν οι υπηρεσίες εκτελέσουν διεργασίες επιχειρήσεων. Τα επιπρόσθετα πρότυπα περιλαμβάνουν μηχανισμούς ασφάλειας, αυθεντικότητας, εξουσιοδότησης, εμπιστευτικότητας, συμβολαίων κα 2.6 Το πρωτόκολλο S.O.A.P. Το πρωτόκολλο SOAP αποτελεί ένα XML-based πρωτόκολλο το οποίο χρησιμεύει στην ανταλλαγή μηνυμάτων μεταξύ υπολογιστών ανεξαρτήτως λειτουργικού συστήματος, προγραμματιστικού περιβάλλοντος, πλατφόρμας κ.λπ. Έτσι οι υπηρεσίες διαδικτύου ξεπερνούν τα προβλήματα που παρουσιάζονται σε συστήματα τα οποία τρέχουν σε ετερογενείς υποδομές. Κύριος στόχος του SOAP είναι η επικοινωνία μεταξύ των λειτουργιών της υπηρεσίας κάτι το οποίο επιτυγχάνεται με τη χρήση του πρωτοκόλλου HTTP. Συγκεκριμένα μια μέθοδος του SOAP είναι μια αίτηση ή απόκριση HTTP η οποία ακολουθεί πιστά τους κανόνες κωδικοποίησης του SOAP. Η παραπάνω ιδιότητα σε συνδυασμό με το γεγονός ότι το SOAP μπορεί και επεξεργάζεται XML μηνύματα, το χαρακτηρίζει ως ελαφρύ wire protocol. To πρωτόκολλο SOAP ως wire protocol πρέπει να τηρεί κριτήρια όπως: Πυκνότητα ( Compactness) : αναφέρεται στο πόσο συμπαγές γίνεται ένα πακέτο δεδομένων μεταφέροντας την ίδια πληροφορία. Επάρκεια πρωτοκόλλου : η οποία μετράται εξετάζοντας το κόστος αποστολής του πακέτου δεδομένων. -14-

18 Coupling: αποτελεί το βαθμό στον οποίο η εφαρμογή χρειάζεται να προσαρμόζεται σε αλλαγές. Scalability: αναφέρεται στην ικανότητα του πρωτοκόλλου να χρησιμοποιείται από μεγάλο αριθμό πιθανών πελατών. Interoperability: αναφέρεται στην ικανότητα του πρωτοκόλλου να συνεργάζεται με ποικιλία από πλατφόρμες υπολογιστών. Σ αυτό το σημείο πρέπει να αναφερθεί ότι κανένα πρωτόκολλο δεν μπορεί να πληροί όλα τα κριτήρια. Το SOAP υποστηρίζει του Loose Coupling και συνεργάζεται με διάφορες πλατφόρμες (interoperability) γεγονός που μειώνει την πυκνότητα και επάρκεια του πρωτοκόλλου To S.O.A.P. ως πρωτόκολλο μηνυμάτων Ένα στιγμιότυπο ενός SOAP XML αρχείου ονομάζεται μήνυμα SOAP. Τα μηνύματα αυτά ανταλλάσσονται μέσω του πρωτοκόλλου HTTP γιατί αποτελεί τον ποιο απλό και βολικό τρόπο. Σε γενικές γραμμές το SOAP αποτελεί ένα network application πρωτόκολλο που χρησιμοποιείται για την ανταλλαγή μηνυμάτων μεταξύ στιγμιότυπων υπηρεσιών που περιγράφονται από WSDL πρότυπα. Επίσης περιγράφει το πώς μορφοποιείται ένα μήνυμα αλλά όχι πως παραδίδεται. Για να πραγματοποιηθεί αυτό πρέπει το μήνυμα να ενσωματωθεί σε ένα πρωτόκολλο μεταφοράς όπως το HTTP,FTP,SMTP κ.α. Έπειτα το HTTP μήνυμα μετατρέπεται σε δεδομένα και στην TCP ροή και μεταδίδεται μέσω μιας σύνδεσης. Ο παραλήπτης τέλος μέσω ενός επεξεργαστή SOAP αποκωδικοποιεί το μήνυμα και το επεξεργάζεται. Από τα παραπάνω προκύπτει ότι το SOAP μπορεί να χρησιμοποιηθεί από πλήθος συστημάτων όπως συστήματα ανταλλαγής μηνυμάτων έως και RPC συστήματα. Επίσης στο SOAP πρωτόκολλο δεν ασχολούμαστε με ζητήματα όπως δρομολόγηση μηνυμάτων, αξιοπιστία μεταφοράς δεδομένων, firewalls κ.α. Βασική προϋπόθεση ώστε ένας κόμβος δικτύου να εκτελεί request και response είναι να μπορεί να συνθέσει και να ερμηνεύσει ένα μήνυμα SOAP και να έχει πρόσβαση στο Internet. Το SOAP παίζει το ρόλο του μηχανισμού διασύνδεσης μεταξύ των δυο endpoints όπου κάθε endpoint αποτελεί ένα URL. Η διασύνδεση είναι «χαλαρή» και το -15-

19 είδος της δεν επηρεάζει τη μορφή των μηνυμάτων SΟΑP, τα οποία μπορούν να είναι απλά ή σύνθετα. Στην τελευταία έκδοση της, το SOAP υποστηρίζει νέα πρωτόκολλα επικοινωνίας όπως SMTP και FTP, μετατρέποντας το σε παγκόσμιας εμβέλειας πρωτόκολλο ανταλλαγής δεδομένων. Ακόμα εισάγει την έννοια των ενδιάμεσων κόμβων οι οποίοι δεν αλλάζουν το περιεχόμενο των μηνυμάτων αλλά χρησιμοποιούνται για δρομολόγηση. Η πληροφορία που αφορά τους ενδιάμεσους κόμβους υπάρχει στην κεφαλίδα του μηνύματος ενώ η πληροφορία που αφορά τον παραλήπτη υπάρχει στο σώμα του μηνύματος. Μέσω του SOAP μπορούμε να έχουμε πρόσβαση σε διανεμημένες εφαρμογές. Αυτό μπορεί να επιτευχθεί ως εξής : Ένας service requestor δημιουργεί ένα SOAP μήνυμα ώστε να επικαλεστεί μια υπηρεσία η οποία παρέχεται από κάποιον provider που βρίσκεται σε απομακρυσμένη τοποθεσία και το αποστέλλει μαζί με το URI του παροχέα στο δίκτυο. Το μήνυμα μέσω του δικτύου παραδίδεται στον provider (συγκεκριμένα στο run time σύστημα SOAP ή αλλιώς SOAP server). O SOAP server είναι το λογισμικό που διανέμει, μεταφράζει τα μηνύματα και τα δρομολογεί στον κώδικα υλοποίησης της υπηρεσίας του παροχέα. Ο SOAP server διαβεβαιώνει ότι τα αρχεία που παραδίδονται μέσω HTTP SOAP σύνδεσης έχουν μετατραπεί από XML σε προγραμματιστικά αντικείμενα τα οποία απαιτούνται από την εφαρμογή και υλοποιούν την υπηρεσία. Ακόμα ελέγχει αν έχουν περαστεί σωστά οι παράμετροι στις διάφορες μεθόδους που είναι υλοποιημένες στην υπηρεσία. Η υπηρεσία είναι υπεύθυνη για την επεξεργασία της αίτησης και τη σύνταξη του μηνύματος response. Στην κεφαλίδα του response μηνύματος συμπεριλαμβάνεται το URL αυτού που κάνει αίτηση στην υπηρεσία και ο παροχέας στέλνει το μήνυμα στον πελάτη μέσω δικτύου. Τέλος το μήνυμα φτάνει στον πελάτη και εκεί τα αρχεία XML μετατρέπονται σε αντικείμενα κατανοητά από τον κώδικα της εφαρμογής του. Τα μηνύματα που ανταλλάσσονται μπορεί να είναι είτε one-way είτε request response. -16-

20 2.6.2 Δομή ενός S.O.A.P. μηνύματος Ένα μήνυμα SOAP αποτελείται από ένα στοιχείο <Envelope> το οποίο περιέχει ένα προαιρετικά ένα <Header> και υποχρεωτικά ένα <Body>. Τα περιεχόμενα αυτών των στοιχείων δεν ορίζονται από το SOAP αλλά από την εφαρμογή. SOAP Envelope Σκοπός του στοιχείου αυτού είναι να περικλείει ότι XML αρχεία ανταλλάσσονται. Ακόμα παρέχει ένα μηχανισμό ώστε να ενσωματώνονται στα δεδομένα επιπρόσθετες πληροφορίες απαραίτητες για τη δρομολόγηση και παράδοση του μηνύματος στον τελικό προορισμό του. Το στοιχείο <Envelope> αποτελεί τη ρίζα κάθε μηνύματος και ορίζει ένα πλαίσιο για την περιγραφή του περιεχομένου του μηνύματος καθώς και του τρόπου επεξεργασίας του. Όλα τα στοιχεία του <envelope> καθορίζονται από το W3C XML Schema και γίνεται χρήση των namespaces, τα οποία ορίζονται με τη χρήση της λέξης xmlns. Μέσα στο στοιχείο <envelope> συμπεριλαμβάνεται το URI στο οποίο βρίσκεται το envelope schema. Αυτό το URI είναι το ίδιο για κάθε <envelope> έτσι ώστε να εξασφαλίζεται ότι όλα τα μηνύματα χρησιμοποιούν τα ίδια namespace και ΧΜL schema και κατ επέκταση τους ίδιους κανόνες επεξεργασίας. Μια σημαντική παράμετρος του στοιχείου <Envelope> είναι η παράμετρος encodingstyle. Αυτή η παράμετρος αναθέτει ένα συγκεκριμένο στυλ κωδικοποίησης στο στοιχείο. Εστί τόσο ο παροχέας όσο και ο πελάτης είναι σύμφωνοι ως προς τους κανόνες κωδικοποίησης. Το στυλ κωδικοποίησης είναι ένα σύνολο κανόνων που περιγράφουν πως μπορούν τα δεδομένα να εκφράζονται έτσι ώστε να επιτυγχάνεται διαλειτουργικότητα μεταξύ των συστημάτων. Μέσα στο στοιχείο <Envelope> μπορούν να υπάρχουν και επιπρόσθετες παράμετροι κάθε μια από τις οποίες πρέπει να έχει αντιστοιχηθεί σε κάποιο namespace. -17-

21 Η κεφαλίδα του SOAP (SOAP Header) Όπως αναφέρθηκε και πριν, μέσα στο <Envelope> μπορεί να περιέχεται το πολύ ένα <Header>. Το στοιχείο <Header> περιέχει υποδείξεις σχετικές με τα endpoints ή τους ενδιάμεσους κόμβους. Ακόμα μπορεί να περιέχει πληροφορίες σχετικά με το που θα σταλεί το αρχείο, από πού προήλθε κ.α. Σκοπός του <Header> είναι να ενσωματώσει επεκτάσεις της μορφής των μηνυμάτων χωρίς να χρειαστεί να μεταβάλλουμε τη βασική δομή του SOAP. Έτσι παρέχεται δυνατότητα προδιαγραφής επιπρόσθετων στοιχείων και λειτουργικότητα όπως, ασφάλεια, συναλλαγές, αναφορές αντικειμένων κ.α. Μια ακόμα δυνατότητα που παρέχει το στοιχείο <Header> σε πελάτες είναι να ενσωματώνουν επιπρόσθετες πληροφορίες έτσι ώστε κάθε κλήση στην υπηρεσία να μη χρειάζεται να δέχεται τα δεδομένα ως παράμετρο(π.χ. σε περιπτώσεις που απαιτείται username και password). Το στοιχείο <Header> παρέχει ένα μηχανισμό για την παροχή επιπρόσθετων πληροφοριών που αφορούν το φορτίο δεδομένων που μεταφέρεται από το <Body>. Το στοιχείο <Header> μπορεί να έχει απεριόριστο αριθμό από «παιδιά» τα οποία ονομάζονται Header Blocks και αναπαριστούν ομάδες δεδομένων που έχουν σκοπό να σταλούν σε ενδιάμεσους κόμβους οι οποίοι ανήκουν στο ευρύτερο μονοπάτι μεταξύ πελάτη και παροχέα. Το κάθε τέτοιο block πρέπει να περιέχει το δικό του namespace ώστε να είναι εύκολη η ταυτοποίηση και επεξεργασία τους. Το SOAP δίνει τη δυνατότητα να χρησιμοποιούμε διαφορετικό κώδικα για την επεξεργασία του <Envelope> και διαφορετικό για την επεξεργασία του <Header>(ομοίως και για το <Body>). Τέλος το στοιχείο <Header> παρέχει τη δυνατότητα επεκτασιμότητας. Η επεκτασιμότητα αναφέρεται σε επιπρόσθετες πληροφορίες απαραίτητες για μια υπηρεσία (π.χ. Authentication από τον πελάτη), οι οποίες μπορούν να ενσωματωθούν στο SOAP χωρίς να μεταβάλλουν τη δομή και το περιεχόμενο του στοιχείου <Body>. -18-

22 Το σώμα του SOAP (SOAP Body) Πρόκειται για το τμήμα του SOAP μηνύματος στο οποίο βρίσκονται τα XML δεδομένα της εφαρμογής τα οποία ανταλλάσσονται. Είναι υποχρεωτική η παρουσία του και πρέπει να είναι παιδί του στοιχείου <Envelope> και επίσης μπορεί να περιέχει και αυτό στοιχεία παιδιά τα οποία ονομάζονται Body entries. Το στοιχείο <Body> δεν ακολουθεί κάποιους κανόνες κωδικοποίησης στην default μορφή του και περιέχει : 1. δεδομένα σχετικά με την εφαρμογή, που αποτελούν την πληροφορία που ανταλλάσσεται με τη χρήση της υπηρεσίας. Αυτή η πληροφορία μπορεί να είναι είτε XML δεδομένα είτε παράμετροι για την κλήση μιας μεθόδου. Μέσα στο <Body> κωδικοποιείται λοιπόν η πληροφορία για την κλήση συναρτήσεων και για τις παραμέτρους που χρειάζονται και τοποθετείται το response για την κλήση μιας συνάρτησης. 2. Μηνύματα σφαλμάτων, τα οποία προφανώς χρησιμοποιούνται όταν προκύψει σφάλμα. Όταν ένας ενδιάμεσος κόμβος εντοπίσει σφάλμα, το στέλνει πίσω στον κόμβο από τον οποίο το έλαβε. Τέλος το στοιχείο <Body> δεν γίνεται να περιέχει πληροφορία και μήνυμα σφάλματος ταυτόχρονα Το SOAP μοντέλο επικοινωνίας Το μοντέλο επικοινωνίας των υπηρεσιών διαδικτύου περιγράφει πώς να επικαλούμαστε υπηρεσίες και βασίζεται στο SOAP. To SOAP μοντέλο επικοινωνίας καθορίζεται από το στυλ επικοινωνίας και το στυλ κωδικοποίησης (encoding style). Όσον αφορά το encoding style το SOAP ορίζει κανόνες κωδικοποίησης. Οι κανόνες κωδικοποίησης ασχολούνται με το πώς εφαρμογές από διαφορετικές πλατφόρμες μοιράζονται και ανταλλάσσουν δεδομένα παρά το γεγονός ότι δεν χρησιμοποιούν ίδιους τύπους δεδομένων ή ακόμα και ίδιες αναπαραστάσεις. Οι κανόνες αυτοί ταυτοποιούνται στο URI : το στυλ κωδικοποίησης ορίζεται με τη χρήση της παραμέτρου encodingstyle. -19-

23 Υπάρχουν δύο στυλ επικοινωνίας : RPC/Literal. Μια υπηρεσία RPC εμφανίζεται ως ένα απομακρυσμένο αντικείμενο σε μια εφαρμογή ενός πελάτη. Η διεπαφή μεταξύ του χρήστη και της RPC υπηρεσίας επικεντρώνεται γύρω από ένα βασισμένα στην υπηρεσία interface. Οι πελάτες εκφέρουν την αίτηση ως μια κλήση μεθόδου μαζί με ένα πλήθος από παραμέτρους, η οποία επιστρέφει μία τιμή ( response value). Λόγω αυτού του τύπου επικοινωνίας οι RPC υπηρεσίες απαιτούν ισχυρής «σύνδεσης»(tight coupling) μοντέλα επικοινωνίας μεταξύ του πελάτη και του παροχέα. Οι κανόνες για την ενσωμάτωση μιας RPC/Literal αίτησης είναι οι εξής: 1. Απαιτείται ένα URI για την ταυτοποίηση της διεύθυνσης μεταφοράς, 2. Ένα μήνυμα αίτησης RPC περιέχει το όνομα της μεθόδου, και τα δεδομένα εισόδου. 3. Ένα μήνυμα απόκρισης RPC περιέχει μια επιστρεφόμενη τιμή και ίσως κάποια δεδομένα εξόδου. Τόσο στα μηνύματα αίτησης όσο και στα απόκρισης η κλήση μιας μεθόδου αναπαρίσταται ως μια δομή όπου κάθε δεδομένο (εισόδου ή εξόδου) αποτελεί ένα πεδίο στην δομή. Τέλος ένα χρήσιμο στοιχείο του πρωτοκόλλου HTTP όταν μεταδίδονται μηνύματα μέσω RPC είναι ότι δίνει τη δυνατότητα αυτόματης αντιστοίχισης ενός request στο response που του αντιστοιχεί γεγονός που το καθιστά πολύ χρήσιμο όταν υπάρχει επικοινωνία με πολλούς providers. Document/Literal Το SOAP μπορεί επίσης να χρησιμοποιηθεί για ανταλλαγή αρχείων που περιέχουν κάθε είδος XML δεδομένων. Αυτό δίνει τη δυνατότητα επαναχρησιμοποίησης κώδικα από διαφορετικού τύπου συστήματα μέσα σε μια επιχείρηση προωθώντας την διεκπεραίωση της διαδικασίας σε ετερογενή συστήματα. Αντιθέτως με άλλα πρωτόκολλα μηνυμάτων το SOAP δεν παρέχει κάποια πηγή κωδικοποίησης ή πληροφορίες για τον παραλήπτη μέσα στο στοιχείο <Envelope>. Το πώς θα μεταδοθεί η πληροφορία είναι καθαρά απόφαση του πελάτη. Οι Document-style υπηρεσίες είναι οδηγούμενες από μηνύματα. Όταν λοιπόν ένας πελάτης επικαλεστεί τέτοια υπηρεσία ουσιαστικά στέλνει ένα ολόκληρο έγγραφο παρά -20-

24 ένα σετ παραμέτρων. Η υπηρεσία δέχεται αυτό το έγγραφο το οποίο και επεξεργάζεται (με πιθανότητα να μην στείλει απάντηση). Ακόμα και χωρίς μήνυμα απόκρισης ο πελάτης μπορεί να συνεχίσει τη διαδικασία που έχει απομείνει. Το μήνυμα απόκρισης μπορεί να φτάσει αργότερα. Τέλος οι Document υπηρεσίες δεν χρειάζεται να ελέγχουν την ορθότητα των δεδομένων (RPC υπηρεσίες) γιατί θεωρούν ότι τα περιεχόμενα ενός μηνύματος SOAP είναι ορθά συνταγμένα XML έγγραφα Διαχείριση σφαλμάτων στο SOAP Το πρωτόκολλο SOAP παρέχει ένα μοντέλο χειρισμού καταστάσεων όταν προκύπτουν σφάλματα κατά την επεξεργασία ενός μηνύματος. Το SOAP διακρίνει τις καταστάσεις που οδηγούν σε σφάλμα από την ικανότητα να σηματοδοτείται το σφάλμα σ αυτόν που δημιούργησε το εσφαλμένο μήνυμα. Το στοιχείο <Body> παίζει σημαντικό ρόλο διότι εκεί τοποθετείται η εσφαλμένη πληροφορία. Ο ορισμός ενός σφάλματος γίνεται με τη χρήση του όρου env:fault, o οποίος είναι ένας προκαθορισμένος όρος που παρέχει ένα μηχανισμό μεταφοράς πληροφορίας σχετικής με τυχόν προβλήματα που προέκυψαν κατά την επεξεργασία ενός μηνύματος Συνεργασία πρωτοκόλλου SOAP-HTTP To SOAP χρησιμοποιεί το HTTP ως πρωτόκολλο μεταφοράς για να έχει πρόσβαση σε οποιαδήποτε δικτυακή τοποθεσία χωρίς την χρήση επιπρόσθετης κωδικοποίησης. Αυτό γίνεται ως εξής : 1. Αρχικά ο πελάτης στέλνει ένα μήνυμα SOAP μέσω μιας HTTP POST (request) 2. Ο service listener δέχεται το request και το στέλνει στον server 3. O server αποκωδικοποιεί το μήνυμα-request και το στέλνει στην εφαρμογή 4.Η εφαρμογή δέχεται μια κλήση συνάρτησης, εκτελεί κάποιες διεργασίες και επιστρέφει μια τιμή στον server 5. O server κωδικοποιεί ξανά το μήνυμα και το στέλνει στον service listener -21-

25 6. O service listener στέλνει το μήνυμα (response πλέον) στον πελάτη Πλεονεκτήματα και μειονεκτήματα του SOAP Τα βασικά πλεονεκτήματα του SOAP είναι τα εξής : Απλότητα Μεταφερσιμότητα Φιλικό ως προς τα firewall Χρήση των Open Standards Διαλειτουργικότητα Παγκόσμια αποδοχή Ανθεκτικότητα σε μεταβολές Παρά τα πλεονεκτήματα του, κάποιες πτυχές του SOAP αποτελούν μειονεκτήματα του. Αυτές είναι : To SOAP είναι στενά δεμένο με το HTTP οπότε χρησιμοποιείται μια requestresponse αρχιτεκτονική η οποία δεν είναι κατάλληλη για κάθε περίπτωση. Το SOAP δεν έχει καταστάσεις. Στο SOAP η αποθήκευση και μετάδοση γίνεται με βάση τιμές και όχι μέσω αναφοράς που σημαίνει ότι το SOAP δεν μπορεί να αναφερθεί σε εξωτερικές πηγές δεδομένων. -22-

26 2.7 Αρχιτεκτονικές που στρέφονται γύρω απο τις υπηρεσίες (Service-Oriented Architectures) Μια αρχιτεκτονική που στρέφεται γύρω από υπηρεσίες ( για λόγους συντόμευσης θα αποκαλείται SOA) αποτελεί ένα λογικό τρόπο σχεδίασης ενός συστήματος λογισμικού που θα παρέχει υπηρεσίες είτε σε εφαρμογές που χρησιμοποιούνται από χρήστες, είτε από άλλες υπηρεσίες διαδικτύου. Για να επιτευχθεί αυτό η SOA δομεί μια συλλογή από εφαρμογές μέσα σε διασυνδεδεμένες υπηρεσίες κάθε μια από τις οποίες μπορεί να βρεθεί και να ανακτηθεί μέσω διεπαφών και πρωτοκόλλων μηνυμάτων. Έτσι είτε υπάρχουσες είτε μελλοντικές υπηρεσίες μπορούν να έχουν πρόσβαση στις υπηρεσίες που ακολουθούν τα πρότυπα της SOA. Αυτή η προσέγγιση είναι ιδιαίτερα εφαρμόσιμη όταν πολλαπλές εφαρμογές διαφορετικών τεχνολογιών και σε διαφορετικές πλατφόρμες πρέπει να επικοινωνήσουν μεταξύ τους. Τα βασικά χαρακτηριστικά των υπηρεσιών σε μια SOA είναι τα εξής : Όλες οι λειτουργίες σε μία SOA ορίζονται ως Υπηρεσίες. Όλες οι υπηρεσίες είναι ανεξάρτητες μεταξύ τους. Αυτό σημαίνει ότι εξωτερικές υπηρεσίες δεν γνωρίζουν τον τρόπο που λειτουργούν οι υπηρεσίες της SOA διότι ενδιαφέρονται μόνο για τον επιστρεφόμενο αποτέλεσμα. Τα interfaces των υπηρεσιών μπορούν να επικαλεστούν. Αυτό σημαίνει ότι σε επίπεδο αρχιτεκτονικής είναι άσχετο αν οι υπηρεσίες είναι τοπικές, απομακρυσμένες, τι σχήμα διεπαφής ή πρωτόκολλο χρησιμοποιείται για την κλήση τους, τι δομικά χαρακτηριστικά απαιτούνται για τη σύνδεση Ρόλοι αλληλεπίδρασης στην SOA Υπάρχουν 3 βασικοί ρόλοι στη SOA. Αυτοί είναι οι εξής : Παροχείς υπηρεσιών (Web Service Providers) : Οι παροχείς είναι λογισμικό που παρέχει την υπηρεσία. Είναι ακόμα υπεύθυνοι για την δημοσίευση της περιγραφής της υπηρεσίας που παρέχουν στην Service Registry. Από τη σκοπιά της αρχιτεκτονικής ο παροχέας είναι η πλατφόρμα η οποία παρέχει και ελέγχει την πρόσβαση στην υπηρεσία. -23-

27 Πελάτες υπηρεσιών (Web Service Requestors) : Οι πελάτες αποτελούν λογισμικό που ζητούν την εκτέλεση της υπηρεσίας. Οι πελάτες θα πρέπει να είναι σε θέση να βρίσκουν τις περιγραφές των υπηρεσιών που ζητούν στη Registry και να μπορούν να συνδεθούν με αυτές. Υπάρχουν 2 ειδών Requestors : οι χρήστες (με χρήση browser) και άλλες υπηρεσίες ως τμήμα εφαρμογών χωρίς την επίβλεψη χρήστη. Μητρώο Υπηρεσιών (Web Service Registry) : Η Registry αποτελεί ένα κατάλογο αναζήτησης όπου δημοσιεύονται περιγραφές υπηρεσιών Λειτουργίες σε μια SOA Υπάρχουν 3 βασικές λειτουργίες σε μία SOA οι οποίες είναι απαραίτητες ώστε να μια εφαρμογή να εκμεταλλευτεί την διεπαφή ανάμεσα στους 3 ρόλους που περιγράφτηκαν παραπάνω. Αυτές οι λειτουργίες είναι η δημοσίευση της περιγραφής της υπηρεσίας, η εύρεση της περιγραφής της και κλήση ή σύνδεση με την υπηρεσία αναλόγως με την πε ριγραφή της. Σχηματικά : Εικόνα 2.2 Τελεστής δημοσίευσης (publish operation) : η λειτουργία αυτή αποτελείται από 2 υπολειτουργίες, την περιγραφή της υπηρεσίας και την καταχώρηση της. Τελεστής Εύρεσης (Find Operation): η εύρεση μιας υπηρεσίας απαιτεί πρώτα την εύρεση της υπηρεσίας στη registry και έπειτα την επιλογή της υπηρεσίας από τη λίστα αποτελεσμάτων. Αρχικά η εύρεση της υπηρεσίας περιλαμβάνει την υποβολή ερωτήσεων στη registry για υπηρεσίες που καλύπτουν τις ανάγκες του πελάτη. Οι ερωτήσεις αυ- -24-

28 τές υποβάλλονται από τον παροχέα της υπηρεσίας στη registry και αφορούν τον τύπο της υπηρεσίας, το κόστος της, τεχνικά χαρακτηριστικά της κα. Έπειτα, η επιλογή της υπηρεσίας έχει να κάνει με ποια υπηρεσία θα χρησιμοποιηθεί από αυτές που βρέθηκαν στη διαδικασία αναζήτησης. Η επιλογή μπορεί να είναι είτε χειροκίνητη είτε αυτόματη. Στη χειροκίνητη επιλογή ο πελάτης διαλέγει ποια υπηρεσία θα χρησιμοποιήσει ενώ στην αυτόματη, μία εφαρμογή του πελάτη που του παρέχεται από την registry εκτελεί την επιλογή. Τελεστής Σύνδεσης (Bind operation) : o τελευταίος και ίσως πιο σημαντικός τελεστής. Μέσω αυτού ο πελάτης καλεί ή ξεκινάει μια διαδικασία με τη χρήση των επιμέρους λεπτομερειών της περιγραφής της υπηρεσίας με στόχο να την εντοπίσει και να επιβεβαιώσει ότι μπορεί να τη χρησιμοποιήσει. Εδώ επίσης χρησιμοποιούνται οι τεχνικές πληροφορίες που έχουν εισαχθεί από τον παροχέα στην registry. υπάρχουν δυο διαφορικά πιθανά σενάρια κατά την κλήση της υπηρεσίας πρώτο είναι άμεση κλήση της υπηρεσίας από τον πελάτη με τη χρήση των λεπτομερειών της περιγραφής της, των δεύτερο περιέχει και την διαμεσολάβηση ενός πράκτορα εύρεσης υπηρεσιών (Discovery Agency). Τέλος στη Registry αυτού του πράκτορα αποθηκεύεται κάθε είδους επικοινωνία μεταξύ παροχέα και πελάτη. 2.8 Ο δίαυλος Service Enterprise Bus Για να ξεπεράσουμε τα προβλήματα της ετερογένειας των συστημάτων και τα σφάλματα των μοντέλου των πληροφοριών, θα μπορούσε να χρησιμοποιηθεί ένα ενδιάμεσο επίπεδο μεταξύ των πελατών και του Server. Αυτό το επίπεδο (integration layer) πρέπει να υποστηρίζει διαλειτουργικότητα και να μπορεί να συνυπάρχει με τις ήδη ανεπτυγμένες εφαρμογές και υποδομές και όχι να προσπαθεί να τις αντικαταστήσει. Μια κατανεμημένη αρχιτεκτονική όπως η SOA χρειάζεται ένα σύνολο κόμβων. Οι απαιτήσεις ώστε να παρέχεται μια ικανή και διαχειρίσιμη υποδομή για υπηρεσίες και SOA συγκλίνουν στο σενάριο ενός επιχειρησιακού διαύλου για υπηρεσίες (Enterprise Service Bus η για λόγους συντομίας E.S.B.). Τα δύο βασικά στοιχεία αυτής της προσέγγισης είναι η χαλαρή σύνδεση (Loose Coupling) μεταξύ των συστημάτων που συμμετέχουν και η διάσπαση της όλης διαδικασίας σε διακριτά και εύκολα διαχειρίσιμα τμήματα. -25-

29 Ο E.S.B. αποτελεί μια βασισμένη σε standards «ραχοκοκαλιά» μηνυμάτων σχεδιασμένη ώστε να επιτρέπει υλοποίησης, ανάπτυξη και διαχείριση λύσεων βασισμένων σε SOA που επικεντρώνονται στην ανάπτυξη και τον χειρισμό των SOA. Ένας Ε.S.B. αποτελεί ένα σετ από ικανότητες της υποδομής υλοποιημένες από ενδιάμεση τεχνολογία, οι οποίες ενεργοποιούν τη SOA και μειώνουν τα προβλήματα διαφορετικότητας μεταξύ εφαρμογών που τρέχουν σε ετερογενείς πλατφόρμες και χρησιμοποιούν διαφορετικές αναπαραστάσεις δεδομένων. Ο ESB υποστηρίζει κλήση συναρτήσεων, μηνύματα και βασισμένη σε γεγονότα αλληλεπίδραση με κατάλληλα επίπεδα υπηρεσιών και είναι σχεδιασμένος με τέτοιο τρόπο ώστε να παρέχει διαλειτουργικότητα μεταξύ μεγάλων εφαρμογών και άλλων τμημάτων μέσω interfaces και προσαρμογαίων. Τέλος ο ESB λειτουργεί τόσο ως διαμεσολαβητής μεταφοράς όσο και μετασχηματισμού ώστε να επιτρέπει διανομή υπηρεσιών σε ανόμοια συστήματα και υπολογιστικά περιβάλλοντα. Σχηματικά : Εικόνα 2.3 Όπως αναφέραμε και παραπάνω ο ESB παρέχει την υλοποίηση μιας SOA αντιμετωπίζοντας τις εφαρμογές ως υπηρεσίες. Ο ESB ασχολείται περισσότερο με την διαμόρφωση εφαρμογών παρά με κωδικοποίηση και σύνδεση τους και είναι ολοκληρωτικά υπεύθυνο για τον έλεγχο, τη ροή και τις μεταφράσεις των μηνυμάτων μεταξύ των υπηρεσιών (χρησιμοποιώντας κάθε πιθανό πρωτόκολλο). Επίσης ο ESB συγκεντρώνει υπηρεσίες καθώς και άλλα διακριτά τμήματα λογισμικού ώστε να δημιουργήσει σύνθετες επιχειρησιακές εφαρμογές οι οποίες εκτελούν με τη σειρά τους λειτουργίες της επιχείρησης. Εγκαθιστά κατάλληλο έλεγχο μηνυμάτων και καλύπτει τις ανάγκες της ασφάλειας, πο-26-

30 λιτικής και αξιοπιστίας σε μια SOA. Το τελικό αποτέλεσμα είναι με ένα ESB είναι πιο εύκολη η δημιουργία σύνθετων υπηρεσιών παρά η χρήση τμημάτων εφαρμογών που υπάρχουν σε διαφορετικά συστήματα. -27-

31 3 Περιγραφή και σύνθεση υπηρεσιών διαδικτύου Η ενότητα αυτή ασχολείται με δύο θέματα. Το πρώτο είναι η γλώσσα περιγραφής υπηρεσιών διαδικτύου (Web Servise Discription Language ή WSDL) και το δεύτερο η σύνθεση υπηρεσιών διαδικτύου και συγκεκριμένα οι μέθοδοι με τις οποίες αυτό επιτυγχάνεται. 3.1 Η γλώσσα περιγραφής των υπηρεσιών διαδικτύου (W.S.D.L.) Σχετικά με τη γλώσσα. Η χρήση του πρωτοκόλλου SOAP σε μια υπηρεσία θα απαιτούσε κάποια τεκμηρίωση σχετικά με τη δομή των SOAP μηνυμάτων, τα πρωτόκολλα που θα χρησιμοποιηθούν, διάφορες λειτουργίες καθώς και τις παραμέτρους που χρησιμοποιούν και τη διεύθυνση της υπηρεσίας στο διαδίκτυο. Η γλώσσα WSDL διευκολύνει την εκμετάλλευση των πλεονεκτημάτων του πρωτοκόλλου SOAP παρέχοντας ένα τρόπο συνεργασίας αυτών που παρέχουν μια υπηρεσία και αυτών που θέλουν να την επικαλεστούν. Η WSDL αποτελεί την γλώσσα αναπαράστασης των υπηρεσιών η οποία περιγράφει την όλα τα interfaces που εκθέτει η ίδια η υπηρεσία και κατ' επέκταση είναι ο τρόπος πρόσβασης στην υπηρεσία. Έτσι ο παροχέας μιας υπηρεσίας έχει όλες τις προδιαγραφές που απαιτούνται έτσι ώστε ο πελάτης να μπορέσει να επικαλεστεί την υπηρεσία χωρίς να εκτίθενται στοιχεία όπως προγραμματιστικές γλώσσες, τεχνικές λεπτομέρειες κ.α. Η WSDL αποτελεί ένα σχήμα βασισμένο σε XML το οποίο περιγράφει το interface μιας υπηρεσίας. Το interface αυτό συμπεριλαμβάνει λειτουργικές πληροφορίες σχετικές με την υπηρεσία όπως, διαθέσιμες λειτουργίες, πρωτόκολλα, διευθύνσεις κ.α. Ουσια- -28-

32 στικά η WSDL αναπαριστά ένα συμβόλαιο μεταξύ παροχέα και χρήστη με ανάλογο τρόπο που σε μια αντικειμενοστραφή γλώσσα προγραμματισμού ένα interface αναπαριστά ένα συμβόλαιο μεταξύ του κώδικα των πελατών και των πραγματικών αντικειμένων. Η βασική διαφορά είναι ότι η WSDL χαρακτηρίζεται από διαπλατφορμικότητα και χρησιμοποιείται για την περιγραφή υπηρεσιών που υποστηρίζουν το πρωτόκολλο SOAP. Κατ' ουσίαν η WSDL χρησιμοποιείται για να περιγράψει το τι κάνει μια υπηρεσία, που διανέμεται και πως μπορεί κάποιος να την επικαλεστεί. Η παραπάνω κατάσταση απεικονίζεται στην εικόνα 3.1 παρακάτω. Εικόνα 3.1 Η WSDL διαθέτει μοναδικές ικανότητες που την καθιστούν χρήσιμη και ευέλικτη γλώσσα. Επειδή βασίζεται πάνω σε XML, τα αρχεία μπορούν να επικυρωθούν με βάση κάποιο σχήμα. Τα αρχεία WSDL μπορούν να διαχωριστούν σε διακριτά τμήματα τα οποία απομονώνουν τους τύπους δεδομένων, το interface των λειτουργιών, την κωδικοποίηση των μηνυμάτων, τη μορφή της μεταφοράς και τη διεύθυνση των υπηρεσιών. Ουσιαστικά η προδιαγραφή μιας υπηρεσίας μπορεί να διαχωριστεί σε δύο τμήματα: τον ορισμό του interface της υπηρεσίας (abstract interface) και την υλοποίηση της υπηρεσίας (concrete endpoint). Πιο συγκεκριμένα -29-

33 ο ορισμός του interface της υπηρεσίας περιγράφει τη γενική δομή της υπηρεσί- ας. Αυτή συμπεριλαμβάνει τις εφαρμογές που υποστηρίζει η υπηρεσία, τις παραμέτρους τους και τους τύπους των δεδομένων που χρησιμοποιούνται. Το τμήμα της υλοποίησης της υπηρεσίας αντιστοιχεί το interface της υπηρεσί- ας σε μια συγκεκριμένη διεύθυνση στο διαδίκτυο, σε ένα συγκεκριμένο πρωτόκολλο και σε συγκεκριμένους τύπους δεδομένων. Τα δύο παραπάνω τμήματα προδιαγράφουν πλήρως μια υπηρεσία. Αυτό σημαίνει ότι παρέχουν επαρκή πληροφορία έτσι ώστε να περιγραφεί στον πελάτη πως να επικαλεστεί και πως να συνεργαστεί με την υπηρεσία στην τοποθεσία του παροχέα. Με χρήση της WSDL ο πελάτης μπορεί να εντοπίσει και να χρησιμοποιήσει οποιαδήποτε από τις εφαρμογές μιας υπηρεσίας. Ακόμα με τη χρήση εργαλείων που είναι εξοικειωμένα με την γλώσσα η διαδικασία αυτή μπορεί να αυτοματοποιηθεί, δίνοντας τη δυνατότητα σε εφαρμογές να συνθέσουν νέες υπηρεσίες με ελάχιστο ή ακόμα και καθόλου επιπρόσθετο κώδικα. Υπάρχουν αρκετές αποφάσεις σχεδιασμού που κρύβονται πίσω από την ανάπτυξη της WSDL όπως η διαπλατφορμικότητα, ανεξαρτησία από γλώσσες προγραμματισμού, υποστήριξη πολλαπλών πρωτοκόλλων, επεκτασιμότητα, ομοιόμορφη υποστήριξη μηνυμάτων κ.α Ορισμός του περιβάλλοντος διεπαφής της γλώσσας W.S.D.L. Οι πελάτες μιας υπηρεσίας αλληλεπιδρούν με αυτήν επικαλλώντας τις λειτουργίες της. Οι πελάτες θα πρέπει να γνωρίζουν όχι μόνο το interface της υπηρεσίας και τις λειτουργίες που συμπεριλαμβάνει αλλά και τι πρωτόκολλο επικοινωνίας πρέπει να χρησιμοποιήσουν έτσι ώστε να στείλουν μηνύματα στην υπηρεσία μαζί με τις λεπτομέρειες που απαιτούνται ώστε το πρωτόκολλο να χρησιμοποιηθεί (εντολές, κώδικες λαθών κ.τ.λ.). Η διασύνδεση ορίζει το τι μεταδίδεται στα μηνύματα μέσω της χαρτογράφησης των μηνυμάτων στο πρωτόκολλο επικοινωνίας του δικτύου. Ακόμη η διασύνδεση επηρεάζει τον τρόπο που τα μηνύματα κωδικοποιούνται ορίζοντας τον τύπο της υπηρεσίας και το μηχανισμό κωδικοποίησης. Μια υπηρεσία μπορεί να υποστηρίζει πολλαπλές διασυν- -30-

34 δέσεις δεδομένου μόνο ενός interface, κάθε διασύνδεση όμως πρέπει να είναι προσβάσιμη σε μία μόνο διεύθυνση η οποία ταυτοποιείται από ένα URI το οποίο συνήθως αναφέρεται ως endpoint της υπηρεσίας. Η γλώσσα WSDL προσδιορίζει μια γραμματική και ένα σύνολο κανόνων σύνταξης μέσω των οποίων περιγράφεται μια υπηρεσία ως ένα σύνολο από endpoints. Ακόμα η WSDL παρέχει τα μέσα ώστε να συγκροτούνται μηνύματα μέσα σε λειτουργίες και λειτουργίες μέσα σε interface. Τα δεδομένα που ανταλλάσσονται μεταξύ των endpoints ορίζονται ως τμήματα των μηνυμάτων και κάθε ενέργεια επεξεργασίας μεταξύ δύο endpoints ονομάζεται λειτουργία. Συλλογές από λειτουργίες σε ένα endpoint ομαδοποιούνται και συγκροτούν τα Port Types. Τέλος η WSDL παρέχει ένα τρόπο να ορίσουμε διασυνδέσεις για κάθε interface και πρωτόκολλο μαζί με τη διεύθυνση του endpoint για κάθε ένα από αυτά. Η κατάσταση που περιγράφεται παραπάνω απεικονίζεται στην εικόνα 3.2. Εικόνα 3.2 Ένα μεγάλο πλεονέκτημα της WSDL βασίζεται στο γεγονός ότι ο προσδιορισμός του interface περιγράφει μηνύματα, λειτουργίες και Port Types με διαπλατφορμικό και ανεξάρτητο γλώσσας προγραμματισμού τρόπο. Ο ορισμός του interface μιας υπηρεσίας αποτελεί ένα αφηρημένο ορισμό της υπηρεσίας στον οποίο δεν υπάρχουν λεπτομέρειες σχετικές με την ανάπτυξη της υπηρεσίας. Περιγράφει αντιθέτως τους ακριβείς τύπους των μηνυμάτων που χρειάζεται να αποσταλούν και τον τρόπο που μπορούν να χρησιμο-31-

35 ποιηθούν τα πρωτόκολλα διαδικτύου ώστε να μορφοποιηθούν μηνύματα συμβατά με τις προδιαγραφές του παροχέα. Σε ένα έγγραφο WSDL τα στοιχεία <types>,<message>,<part>,<porttype> και <operation> περιγράφουν το αφηρημένο interface της υπηρεσίας. Το στοιχείo <porttype> αποτελεί ένα αφηρημένο interface που συνδυάζει ορισμούς <operation> και <message>. Κάθε ορισμός ενός <message> περιγράφει το φορτίο των εισερχόμενων και εξερχόμενων μηνυμάτων. Τα μηνύματα αποτελούνται από στοιχεία <part> καθένα από τα οποία αποτελεί το στιγμιότυπο ενός τύπου. Κάθε στοιχείο <operation> δηλώνεται από ένα στοιχείο <porttype> και περιέχει ένα πλήθος από στοιχεία <message> που περιγράφουν τις παραμέτρους εισόδου και εξόδου καθώς και τα οποιαδήποτε σφάλματα. Έστω λοιπόν η παρακάτω απλή περιγραφή ενός WSDL interface. Εικόνα

36 Το στοιχείο-ρίζα είναι το στοιχείο <definitions> στο οποίο ενσωματώνεται όλο το WSDL έγγραφο και παρέχεται έτσι το όνομα του. Η πρώτη παράμετρος του στοιχείου <definitions> είναι η παράμετρος name η οποία χρησιμοποιείται για να ονομάσει το WSDL αρχείο. Μια ακόμη παράμετρος είναι η παράμετρος targetnamespace η οποία ταυτοποιεί τα ονόματα των στοιχείων και χαρακτηρίζει την υπηρεσία. Αυτό το στοιχείο είναι μοναδικό για κάθε υπηρεσία γεγονός που βοηθάει τον πελάτη να διαφοροποιούνται μεταξύ των υπηρεσιών και αποτρέπει τις συγκρούσεις ονομάτων όταν εισάγουμε παραπάνω από ένα WSDL αρχεία. Ο ορισμός wsdl:types ομαδοποιεί τους ορισμός σχημάτων κάθε είδους τύπου με τη χρήση XML XSD. H γλώσσα WSDL χρησιμοποιεί ως σύστημα τύπων τους τύπους δεδομένων του W3C XML σχήματος. Το στοιχείο <types> χρησιμοποιείται για να αποθηκεύονται όλοι οι αφηρημένοι τύποι δεδομένων που ορίζουν το interface μιας υπηρεσίας. Οι τύποι δεδομένων μπορεί είτε να είναι πρωταρχικοί όπως int, float,long,short,string Boolean είτε σύνθετοι δηλ να αποτελούνται από τους πρωταρχικούς και να διαμορφώνονται από τον χρήστη ανάλογα με τις ανάγκες του. Αυτός είναι και ο λόγος που οι προγραμματιστές ορίζουν την παράμετρο namespace όταν αναφέρονται σε σύνθετους τύπους δεδομένων. Στην παραπάνω περιγραφή υπάρχουν δύο σύνθετοι τύποι δεδομένων οι POType και InvoiceType. Αυτοί οι δύο τύποι έχουν ανατεθεί στο xmlns:tns namespace από την παράμετρο targetnamespace. Το στοιχείο <sequence> αναφέρεται στο γεγονός ότι το μοντέλο των περιεχομένων πρέπει να συμμορφώνεται με την ακολουθία στοιχείων που έχει οριστεί. Επιπροσθέτως μπορεί να χρησιμοποιείται το στοιχείο <all> το οποίο ορίζει ότι όλα τα στοιχεία που ορίζονται στο <complextype> πρέπει να εμφανίζονται σε κάθε στιγμιότυπο του εγγράφου. Το αρχείο WSDL πρέπει να έχει επίγνωση όλων των στοιχείων namespace που αναφέρονται σ' αυτό. Τα μηνύματα στην WSDL αποτελούν αφηρημένες συλλογές τύπων που εκφράζουν πληροφορία και χρησιμοποιούνται με σκοπό την επικοινωνία μεταξύ των συστημάτων. Ένα στοιχείο <message> περιγράφει το φορτίο των εισερχόμενων και εξερχόμενων μηνυμάτων και αποτελεί την πληροφορία που ανταλλάσσεται μεταξύ αυτού που επικαλείται την υπηρεσία και της ίδιας της υπηρεσίας. -33-

37 Ενώ τα μηνύματα αναπαριστούν τη γενική συγκρότηση των τύπων μιας λειτουργίας τα στοιχεία <part> δομούν ακόμα περισσότερο αυτή τη συγκρότηση. Έτσι ένα μήνυμα μπορεί να αποτελείται από ένα ή περισσότερα <part> καθένα από τα οποία αναπαριστά το στιγμιότυπο ενός συγκεκριμένου τύπου. Τα στοιχεία <part> ενός μηνύματος χρησιμοποιούν είτε πρωταρχικούς είτε σύνθετους τύπους είτε στοιχεία που ορίζονται στο τμήμα WSD <types> ή σε κάποιο άλλο WSDL έγγραφο και εισάγονται με την εντολή <import>. Επιπροσθέτως τα στοιχεία <message> μπορούν να περιγράφουν περιεχόμενα των block κεφαλίδων του πρωτοκόλλου SOAP ή στοιχεία με λεπτομέρειες σφαλμάτων. Εικόνα 3.4 Tο παραπάνω τμήμα κώδικα απεικονίζει ότι το μήνυμα με όνομα POMessage περιγράφει την παράμετρο εισόδου στην υπηρεσία ενώ το μήνυμα με όνομα InvMessage την παράμετρο εξόδου. Το μήνυμα εισόδου POMessage περιέχει δύο στοιχεί <part>, τα PurchaseOrder και CustomerInfo, τα οποία αναφέρονται στους σύνθετους τύπους POType και CustomerInfoType. Όταν χρησιμοποιείται το RPC στυλ μηνυμάτων τα στοιχεία <message> περιγράφουν το φορτίο των αιτήσεων και αποκρίσεων SOAP. Επίσης σ' αυτή την περίπτωση το κάθε στοιχείο <message> χρησιμοποιεί περισσότερα από ένα <part>. Εικόνα

38 Στον κώδικα της εικόνας 3.5, το στυλ μηνυμάτων είναι βασισμένο σε έγγραφα (document style) γεγονός που φαίνεται από τη δήλωση στοιχείου <element> αντί για <type> μέσα σε στοιχείο <message>. Επίσης σ' αυτή την περίπτωση τα στοιχεία <message> αποτελούν μηνύματα μονόδρομης κατεύθυνσης(δεν υπάρχει μήνυμα απόκρισης). Το βασικό στοιχείο που εξωτερικεύουν την WSDL περιγραφή του interface μιας υπηρεσίας είναι το <porttype>. Ένα στοιχείο <porttype> ορίζει ένα αφηρημένο τύπο και κάποια λειτουργία πάνω σ' αυτόν χωρίς όμως να ορίζεται και η εφαρμογή. Ουσιαστικά το στοιχείο <porttype> αποτελεί μια ομαδοποίηση των στοιχείων <operation> που περιγράφουν το interface της υπηρεσίας και καθορίζει τις μεθόδους της. Επίσης το στοιχείο αυτό χρησιμοποιείται για να συνδέει τις λειτουργίες της υπηρεσίας με ένα πρωτόκολλο μεταφοράς όπως το SOAP. Τέλος το <porttype> χρησιμοποιείται από το στοιχεία <binding> και <service> τα οποία υπαγορεύουν τα πρωτόκολλα Internet, τα σχήματα κωδικοποίησης καθώς και μια διεύθυνση όπου υπάρχει η εφαρμογή της υπηρεσίας. Ένα στοιχείο <porttype> μπορεί να περιέχει ένα ή περισσότερα στοιχεία <operation> καθένα από τα οποία ορίζει μια RPC ή document-style λειτουργία της υπηρεσίας. Κάθε στοιχείο <operation> αποτελείται από το πολύ ένα στοιχείο <input> ή από ένα στοιχείο <output> και από οποιοδήποτε αριθμό στοιχείων <fault> και αναπαριστά κάποια λειτουργία που εκτελεί η υπηρεσία. Στην περιγραφή της εικόνας 3.3 η υπηρεσία περιέχει ένα στοιχείο <potrtype> που ονομάζεται PurchaseOrderPortType και υποστηρίζει μια λειτουργία με όνομα SendPurchase. Επειδή χρησιμοποιείται RPC στυλ στην περιγραφή το μήνυμα POMessage ορίζεται ως στοιχείο <input> και αντιπροσωπεύει την πληροφορία που αποστέλλεται στην υπηρεσία, ενώ το μήνυμα InvMessage ορίζεται ως στοιχείο <output> και αντιπροσωπεύει την πληροφορία που αποστέλλεται στον πελάτη. Η λειτουργία SendPurchase αποτελεί μια κλασική λειτουργία αίτησης/απόκρισης (request/response). -35-

39 3.1.3 Η υλοποίηση της γλώσσας W.S.D.L. Στην προηγούμενη υποενότητα οι λειτουργίες και τα μηνύματα που περιγράφονται σε WSDL ορίστηκαν με αφηρημένο τρόπο χωρίς να ληφθούν υπόψη λεπτομέρειες σχετικές με την υλοποίηση. Ουσιαστικά ο σκοπός της γλώσσας αυτής είναι να προσδιορίσει μια υπηρεσία με τρόπο αφηρημένο και έπειτα να ορίσει τον τρόπο με τον οποίο ο προγραμματιστής θα την υλοποιήσει. Το τμήμα της υλοποίησης περιλαμβάνει τα στοιχεία <binding>, <port> και <service> και περιγράφει πως υλοποιείται το interface μιας υπηρεσίας διαδικτύου. Η υλοποίηση περιγράφει την τοποθεσία της υπηρεσίας ή πιο συγκεκριμένα σε ποια διεύθυνση πρέπει να σταλεί μήνυμα ώστε να γίνει κλήση της. Στην εικόνα 3.6 απεικονίζεται η περιγραφή της υλοποίησης για το interface της υπηρεσίας που περιγράφεται στην εικόνα

40 Εικόνα 3.6 Το βασικό στοιχείο της περιγραφής της υλοποίησης είναι το στοιχείο <binding> το οποίο ορίζει τον τρόπο με τον που ο πελάτης και η υπηρεσία πρέπει να ανταλλάσουν μηνύματα. Ο πελάτης χρησιμοποιεί αυτή την πληροφορία για να αποκτήσει πρόσβαση στην υπηρεσία. Αυτό το στοιχείο συνδέει το <porttype> με μια υπάρχουσα υλοποίηση της υπηρεσίας και παρέχει πληροφορίες σχετικές με το πρωτόκολλο και την μορφοποίηση των δεδομένων που περιμένει η υπηρεσία. Το στοιχείο <binding> περιέχει πληροφορίες σχετικά με το πως στοιχεία του interface της υπηρεσίας -37-

41 (<porttype>,<operation>) χαρτογραφούνται σε μια αναπαράσταση ως συνδυασμός από πρωτόκολλα (HTTP, SOAP), στυλ μηνυμάτων (RPC, document style) και στυλ κωδικοποίησης (literal, SOAP). Η δομή του στοιχείου <wsdl:binding> είναι παρόμοια με αυτήν του <porttype>. Αυτό δεν είναι βέβαια κάτι τυχαίο διότι η σύνδεση (binding) θα πρέπει να χαρτογραφήσει την περιγραφή ενός porttype σε μια υλοποίηση. Η παράμετρος <type> καθορίζει ποιο στοιχείο <porttype> περιγράφει αυτή η σύνδεση. Στην εικόνα 3.6 το στοιχείο <binding> αποτελείται από δύο διαφορετικά namespaces. Αφενός υπάρχουν στοιχεία τα οποία που είναι μέλη του WSDL 1.1 namespace το οποίο δηλώνεται στη photo 1 και είναι το default namespace του WSDL εγγράφου. Από την άλλη τα στοιχεία soapbind:binding, soapbind:operation και soapbind:body είναι μέλη της WSDL-SOAP σύνδεσης η οποία επίσης ορίζεται στην εικόνα 3.3. Τα στοιχεία soapbind:binding και soapbind:body εκφράζουν τις λεπτομέρειες σχετικές με το πρωτόκολλο SOAP μιας υπηρεσίας. Πιο συγκεκριμένα στην εικόνα 3.6, ο σκοπός του <soapbind:binding> είναι να προσδιορίσει το στυλ μηνυμάτων ως RPC, το κατώτερο πρωτόκολλο μεταφοράς ως HTTP και το πρωτόκολλο SOAP ως υπηρεσία σύνδεσης και μεταφοράς. Αυτή η δήλωση σημαίνει ότι όλες οι λειτουργίες του PurchaseOrderPortType ορίζονται ως SOAP μηνύματα. Από αυτό το σημείο και μετά είναι δουλειά του SOAP να μεταφέρει τον πελάτη από την περιγραφή σε WSDL στην υλοποίηση σε WSDL. Από τη στιγμή που χρησιμοποιείται το SOAP για αυτή τη δουλειά πρέπει να χρησιμοποιούνται και τα namespaces του. Το στοιχείο <soapbind:body> επιτρέπει σε εφαρμογές να ορίζουν τις λεπτομέρειες των μηνυμάτων εισόδου και εξόδου και να καθιστούν εφικτή την χαρτογράφηση της αφηρημένες περιγραφής της υπηρεσίας σε σταθερή (concrete protocol description). Πιο συγκεκριμένα το στοιχείο <soapbind:body> ορίζει το SOAP στυλ κωδικοποίησης και τα namespaces που συνδέονται με την υπηρεσία. Στη εικόνα 3.6 η δομή <soapbind:body> ορίζει ότι τόσο τα μηνύματα εισόδου όσο και εξόδου είναι κωδικοποιημένα με τρόπο literal. Τα υποστοιχεία του <binding> (<operation>,<input>,<output>) χαρτογραφούνται κατευθείαν ως κόμβος-παιδί του <porttype>. Αρκετές συνδέσεις (bindings) μπορούν να αναπαριστούν ποικίλες υλοποιήσεις του ίδιου στοιχείου <porttype>. Εάν μια υπηρεσία υποστηρίζει περισσότερα από ένα πρωτόκολλα το στοιχείο <porttype> πρέπει να συμπεριλαμβάνει μια σύνδεση για κάθε -38-

42 πρωτόκολλο που υποστηρίζει. Για ένα δοθέν <porttype> ένα στοιχείο <binding> περιγράφει πως γίνεται κλήση των εφαρμογών με τη χρήση απλού πρωτοκόλλου μηνυμάτων/μεταφοράς όπως π.χ. SOAP πάνω σε HTTP (που είναι και η πιο δημοφιλής τεχνική σύνδεσης). Εδώ πρέπει να σημειωθεί ότι μια σύνδεση δεν περιλαμβάνει καμία γλώσσα προγραμματισμού ή λεπτομέρειες σχετικές με υλοποίηση. Όπως αναφέρθηκε και πιο πριν η σύνδεση που απεικονίζεται στην εικόνα 3.6 περιέχει μια μόνο λειτουργία, την SendPurchase, η οποία χαρτογραφεί τα στοιχεία εισόδου, εξόδου και σφαλμάτων της λειτουργίας αυτής στην SOAP μορφοποίηση της. Με αυτό τον τρόπο δίνεται πρόσβαση στην υπηρεσία PurchaseOrderService. Ακόμα το στοιχείο soapbind:operation καθορίζει τον στυλ μηνυμάτων(rpc ή document) και την τιμή του πεδίου SOAPAction. Στην περιγραφή WSDL η παράμετρος style είναι προαιρετική. Χρησιμοποιείται για να μεταβάλλει το στυλ μηνυμάτων το οποίο καθορίζεται από <soapbind:binding>. Η παράμετρος SOAPAction χρησιμοποιείται από τους SOAP Servers ως ένδειξη της λειτουργίας που καλείται και ουσιαστικά είναι ένα URI που υποδεικνύει την πρόθεση και κλήση της λειτουργίας. Μπορεί να περιέχει μια παράμετρος διευθυνσιοδότητσης μηνυμάτων ή μια τιμή που βοηθά το σύστημα SOAP να στέλνει μηνύματα στην υπηρεσία που επιθυμεί ο πελάτης. Ο σκοπός είναι να επιτυγχάνεται διαλειτουργικότητα μεταξύ πελάτη και παροχέα. Το στυλ μηνυμάτων έχει μεγάλο αντίκτυπο στον τρόπο με τον οποίο το σώμα των SOAP μηνυμάτων κατασκευάζεται. Παίζει λοιπόν πολύ σημαντικό ρόλο να επιλεγεί το σωστό στυλ, είτε RPC είτε document. Όταν χρησιμοποιείται το RPC το τμήμα <Body> του μηνύματος SOAP θα περιλαμβάνει ένα στοιχείο που θα αναπαριστά την λειτουργία που πρέπει να εκτελεστεί. Αυτό το στοιχείο ονομάζεται όπως και η λειτουργία (στην περίπτωση μας SendPurchase). Στη Φώτο 3.7 απεικονίζεται πως μια λειτουργία μου ορίζεται στο στοιχείο <PortType> καθώς και όλα τα τμήματα της χαρτογραφούνται σε ένα SOAP μήνυμα που χρησιμοποιεί στυλ RPC. -39-

43 Εικόνα 3.7 Στο παρακάνω τμήμα κώδικα που προέρχεται από την εικόνα 3.6, φαίνεται πως τα μηνύματα εισόδου και εξόδου της λειτουργίας SendPurchase απεικονίζονται στα τμήματα του μηνύματος SOAP. Τόσο η είσοδος όσο και η έξοδος περιέχουν ένα στοιχείο <soapbind:body> μαζί με την τιμή του namespace που αντιστοιχεί στο όνομα της υπηρεσίας που αναπτύσσεται στον SOAP Server. Στο RPC στυλ μηνυμάτων η παράμετρος namespace πρέπει να καθοριστεί βάση ενός έγκυρου URI. Αυτό το URI μπορεί να είναι ίδιο με αυτό της παραμέτρου targetnamespace στο WSDL έγγραφο. Σε αντίθεση με το παραπάνω, τα μηνύματα document-style δεν μπορούν να προσδιορίζουν την παράμετρο targetnamespace στο στοιχείο <soapbind:body>. -40-

44 Εικόνα 3.8 Σ' αυτό το σημείο ας θεωρήσουμε το στοιχείο εισόδου για τη λειτουργία SendPurchase. Όλο το μήνυμα POMessage στη δήλωση του <PortType> για τη λειτουργία SendPurchase είναι δηλωμένο ως αφηρημένο. Αυτό φαίνεται από τη δήλωση της παραμέτρου use=literal. Ο σκοπός της παραμέτρου use είναι να δίνει τη δυνατότητα στις εφαρμογές να καθορίζουν πως τα τμήματα του μηνύματος θα ορίζονται. Η κωδικοποίηση literal υποδεικνύει ότι τα μηνύματα SOAP περιέχουν δεδομένα μορφοποιημένα ακριβώς όπως καθορίζεται στην αφηρημένη WSDL περιγραφή. Κατά συνέπεια οι τύποι δεδομένων στους οποίους αναφέρεται ένα τμήμα μηνύματος, θα αντιστοιχηθούν με βάση την ακριβή αναπαράσταση τους στο τμήμα καθορισμό των τύπων και με βάση το σχήμα XML. Αυτό σημαίνει ότι το σχήμα θα χρησιμοποιηθεί για να επικυρώσει το κάθε τμήμα ενός μηνύματος. Αν είχε χρησιμοποιηθεί encoded αντί για literal στυλ κωδικοποίησης, θα έπρεπε να χρησιμοποιηθεί η παράμετρος encodingstyle και το μήνυμα θα έπρεπε να εμφανιστεί ως τμήμα του στοιχείου <soapbind:body>. Τέλος το στοιχείο <service> συνδέει την υπηρεσία με μια τοποθεσία-διεύθυνση δικτύου. Ουσιαστικά χρησιμοποιεί τις συνδέσεις που αναφέρθηκαν παραπάνω και τις ομαδοποιεί σε ένα ή περισσότερα στοιχεία <port>, καθένα από τα οποία αναπαριστά μια υπηρεσία ιστού. Ένα στοιχείο <service> ορίζεται ως μια συλλογή από σχετικά στοιχεία <port>, όπου κάθε <port> αποτελεί ένα καταληκτικό σημείο (endpoint) ορισμένο ως συνδυασμός μιας σύνδεσης και μιας διεύθυνσης δικτύου, όπου μια υπηρεσία είναι προσβάσιμη. Κάθε στοιχείο <service> ονομάζεται και κάθε όνομα πρέπει να είναι μοναδικό μεταξύ των υπηρεσιών που αναφέρονται σε ένα WSDL έγγραφο. Ο συνδυασμός όλων των <port>s μιας υπηρεσίας αποτελούν ένα πλήθος από λειτουργίες που προσφέρονται στους πελάτες. -41-

45 Στην γλώσσα WSDL ένα στοιχείο <port> καθορίζει την τοποθεσία στην οποία οι λειτουργίες ενός <porttype> χρησιμοποιώντας ένα συγκεκριμένα πρωτόκολλα μεταφοράς μπορούν να επικαλεστούν. Ένα <port> συνδέει ένα καταληκτικό σημείο όπως π.χ. μια διεύθυνση, ή URL, με ένα στοιχείο <binding> ώστε να υποδηλώσει το φυσικό καταληκτικό σημείο το οποίο οι πελάτες υπηρεσιών πρέπει να χρησιμοποιήσουν με σκοπό να συνδεθούν με την υπηρεσία. Από τη στιγμή που το <binding> προσδιορίζει ένα <porttype> το στοιχείο <port> αντιστοιχεί το <porttype> σε μια διεύθυνση. Εικόνα 3.9 Στην εικόνα 3.9 απεικονίζεται το γεγονός ότι μια απλή υπηρεσία περιέχει πολλά ports το οποία χρησιμοποιούν όλα το ίδιο <porttype>. Αυτό σημαίνει ότι μπορούν να υπάρχουν πολλές υλοποιήσεις για το Interface μιας υπηρεσίας, οι οποίες παρέχονται από διαφορετικούς παροχείς και έχουν διαφορετικές συνδέσεις και διευθύνσεις. Εναλλακτικά μια υπηρεσία που υλοποιείται από κάποιον παροχέα μπορεί να περιέχει αρκετά <port>s για το ίδιο <porttype> καθένα από τα οποία παρέχεται από διαφορετική σύνδεση (binding). Αυτό επιτρέπει στον πελάτη να διαλέξει τον πιο βολικό τρόπο να επικοινωνήσει με τον παροχέα που υλοποιεί την υπηρεσία. Στην εικόνα 3.6 το στοιχείο <binding> που ονομάζεται POMessageSOAPBinding ενώνει το στοιχείο <porttype> που ονομάζεται PurchaseOrderPortType στο στοιχείο <port> που ονομάζεται PurchaseOrderPort. Αυτό επιτυγχάνεται μέσω του <binding> με όνομα POMessageSOAPBinding. Εδώ απεικονίζεται μόνο μία υπηρεσία με όνομα PurchaseOrderService και κατ' επέκταση μόνο ένα στοιχείο <port> που ονομάζεται PurchaseOrderPort χρησιμοποιείται για να αποκαλύψει την τοποθεσία της υπηρεσίας. Όπως όμως αναφέρθηκε παραπάνω η υπηρεσία θα μπορούσε να περιέχει παραπάνω -42-

46 <port>s στο ίδιο <porttype> μέσω των οποίων ο πελάτης θα μπορούσε να επιλέξει πoιό πρωτόκολλο θα χρησιμοποιήσει για να επικοινωνήσει με την υπηρεσία (HTTP, HTTP GET/POST,SMTP) ή ποιά διεύθυνση είναι κοντινότερη. Με τη χρήση περισσοτέρων από μίας σύνδεσης η υπηρεσία καθίσταται πιο προσβάσιμη από μεγαλύτερο πλήθος πλατφορμών. Τέλος η παράμετρος <soapbind:address> χρησιμοποιείται για να σηματοδοτήσει το URI της υπηρεσίας ή του καταληκτικού σημείου στο δίκτυο Τα πρότυπα ανταλλαγής μηνυμάτων της W.S.D.L. Το interface της γλώσσας WSDL υποστηρίζει διάφορους τύπους λειτουργιών. Μια λειτουργία αναπαριστά την πιο κοινή μορφή αλληλεπίδρασης για τις υπηρεσίες διαδικτύου. Από τη στιγμή που κάθε λειτουργία μπορεί να έχει εισόδους και/ή εξόδους τα τέσσερα πρότυπα αλληλεπίδρασης λειτουργιών αναπαριστούν πιθανούς συνδυασμούς μηνυμάτων εισόδου και εξόδου. Οι λειτουργίες της WSDL αντιστοιχούν σε δυο βασικούς τύπους λειτουργιών. Ο πρώτος τύπος αποτελείται από ένα απλό εισερχόμενο μήνυμα μαζί με το πανομοιότυπο εξερχόμενο του (one way και notification λειτουργίες) ενώ ο δεύτερος από εισερχόμενες και εξερχόμενες εκδοχές μιας συγχρονισμένης αμφίδρομης ανταλλαγής μηνυμάτων (request/response και solicit/response λειτουργίες). Οι τέσσερεις τύποι λειτουργιών απεικονίζονται στην εικόνα

47 Εικόνα 3.10 Πιο συγκεκριμένα για τους τύπους των τεσσάρων λειτουργιών ισχύει : One Way λειτουργίες. Σε αυτές τις λειτουργίες το καταληκτικό σημείο λαμ- βάνει ένα μήνυμα, αλλά δε στέλνει κάποια ανταπόκριση. Επίσης η λειτουργία ορίζει μόνο μήνυμα εισόδου και όχι εξόδου ή σφάλματος. Στο παρακάτω τμήμα κώδικα φαίνεται ο ορισμός μιας one way λειτουργίας. Όπως και φαίνεται, η λειτουργία ορίζει μόνο στοιχείο <input>. -44-

48 Request/Response λειτουργίες. Πρόκειται για λειτουργίες που το καταληκτικό σημείο μιας υπηρεσίας λαμβάνει ένα μήνυμα και στέλνει ένα ως ανταπόκριση. Σε αυτό τον τύπο ο πελάτης περιμένει κάποιες ενέργειες από τον παροχέα της υπηρεσίας. Στο παρακάτω τμήμα κώδικα περιγράφεται μια λειτουργία που χρησιμοποιεί το πρότυπο request/response. Όπως φαίνεται υπάρχει τόσο στοιχείο <input> όσο και <output>. Notification λειτουργίες. Σ' αυτόν τον τύπο το καταληκτικό σημείο μιας υπηρε- σίας στέλνει ένα μήνυμα σε κάποιον πελάτη αλλά δεν περιμένει ανταπόκριση. Συνήθως τέτοιες λειτουργίες χρησιμοποιούνται για να ενημερώνονται οι πελάτες για διάφορα γεγονότα από την υπηρεσία. Στην περιγραφή μιας τέτοιας λειτουργίες υπάρχει πάντα μόνο στοιχείο <output>. Solicit/Response λειτουργίες. Εδώ το καταληκτικό σημείο μιας υπηρεσίας στέλνει ένα μήνυμα σε κάποιον πελάτη και περιμένει από αυτόν ανταπόκριση. Πρόκειται για την ακριβώς αντίθετη λειτουργία της request/response από τη στιγμή που την διαδικασία ξεκινά η ίδια η υπηρεσία. Για να οριστεί μια τέτοια λειτουργία, αρχικά απαιτείται ένα tag στοιχείου <output> και έπειτα ο ορισμός ενός μηνύματος <input>. Ας σημειώσουμε σ' αυτό το σημείο ότι το interface μιας υπηρεσίας μπορεί να περιέχει οποιοδήποτε συνδυασμό των παραπάνω τύπων λειτουργιών. -45-

49 3.2 Μέθοδοι σύνθεσης υπηρεσιών διαδικτύου Υπάρχουν τρία βασικά είδη μεθόδων σύνθεσης υπηρεσιών. Αυτά είναι οι μη αυτοματοποιημένες, οι ημι-αυτοματοποιημένες και οι αυτοματοποιημένες μέθοδοι και γλώσσες σύνθεσης υπηρεσιών Μη αυτοματοποιημένες μέθοδοι και γλώσσες σύνθεσης υπηρεσιών Όπως αναφέρθηκε και παραπάνω, με τη χρήση της γλώσσας WSDL ορίζουμε αφενός μηνύματα που παρέχουν μια αφηρημένη περιγραφή των δεδομένων που ανταλλάσσονται με εξωγενείς παράγοντες και αφετέρου λειτουργίες που παρέχονται από την υπηρεσία. Για μια απλή διεργασία θα μπορούσε να υλοποιηθεί ένα πρόγραμμα το οποίο θα εκμεταλλεύεται την διεπαφή που προσφέρει η υπηρεσία. Όσον αφορά όμως επιχειρησιακές εφαρμογές οι οποίες χρησιμοποιούν πολλές υπηρεσίες δεν αρκεί μια απλή περιγραφή αλλά απαιτούνται πληροφορίες σχετικά με τη σειρά εκτέλεσης των λειτουργιών και ανταλλαγή μηνυμάτων μεταξύ τους. Σε αυτή την περίπτωση η διαδικασία σύνθεσης ονομάζεται μη αυτοματοποιημένη διότι οι απλές υπηρεσίες καθώς και δομή των αλληλεπιδράσεων περιγράφονται στατικά. Οι σημαντικότερες μέθοδοι και γλώσσες αυτής της οικογένειας είναι οι εξής : BPEL4WS. Αυτή η γλώσσα επεκτείνει το μοντέλο αλληλεπίδρασης μεταξύ των διαδικτυακών υπηρεσιών επιτρέποντας του την περιγραφή σύνθετων διαδικτυακών υπηρεσιών που αντιστοιχούν σε πολύπλοκες επιχειρησιακές διεργασίες στις οποίες λαμβάνουν μέρος πολλοί διαφορετικοί οργανισμοί. Βάση του μοντέλου και της γραμματικής που προσφέρει η γλώσσα μπορούν να οριστούν οι αλληλεπιδράσεις μεταξύ πολλαπλών υπηρεσιών, η προσφερόμενη λειτουργικότητα από την παραγόμενη σύνθετη υπηρεσία και οι απαραίτητοι κανόνες συντονισμού ώστε να επιτευχθεί η υλοποίηση των επιχειρηματικών στόχων. Ακόμα προσφέρεται η δυνατότητα περιγραφής των καταστάσεων και της λογικής των αλληλεπιδράσεων καθώς και ένας συστηματικός τρόπος χειρισμού των εξαιρέσεων. Τέλος η BPEL4WS υποστηρίζει τον ορισμό τόσο εκτελέσιμων όσο και αφηρημένων επιχειρησιακών διεργασιών όπου οι εκτελέσιμες διεργασίες περιγράφουν την συμπεριφορά των όσων συμμετέχουν σε μια αλληλεπίδραση ενώ -46-

50 οι αφηρημένες ορίζουν τις δημόσιες-ορατές ανταλλαγές μηνυμάτων μεταξύ αυτών που συμμετέχουν χωρίς παρόλα αυτά να αποκαλύπτουν λεπτομέρειες σχετικά με την εσωτερική δομή και υλοποίηση των υπηρεσιών. WSCI(Web Service Choregraphy Interface). Μέσω αυτής της γλώσσας παρέχεται μια γενική περιγραφή των αλληλεπιδράσεων μεταξύ των παροχέων και των χρηστών-πελατών διαδικτυακών υπηρεσιών δίνοντας βάση στις ανταλλαγές μηνυμάτων. Αυτή η μέθοδος (πρότυπο) ορίζει τη ροή των μηνυμάτων που ανταλλάσει μια διαδικτυακή υπηρεσία, περιγράφοντας έτσι την ορατή συμπεριφορά της. Ωστόσο δεν περιγράφεται η εσωτερική συμπεριφορά (όπως και στην BPEL4WS) καθώς και οι λειτουργίες της υπηρεσίας. Έτσι το πρότυπο αυτό δρα συμπληρωματικά με τις περιγραφές των λειτουργιών που παρέχει η WSDL περιγράφοντας τον τρόπο αλληλεπίδρασης μεταξύ τους. Αυτό συμβαίνει σε δύο επίπεδα. Στο πρώτο, το WSCI περιγράφει τα μηνύματα που λαμβάνει ή αποστέλλει μια υπηρεσία. Αυτή η περιγραφή αφορά μόνο την ίδια τη υπηρεσία. Στο δεύτερο επίπεδο, περιγράφεται η εξωτερικά παρατηρούμενη συμπεριφορά την οποία η υπηρεσία επιδεικνύει με αποτέλεσμα να διευκολύνεται η έκφραση των λογικών και χρονικών εξαρτήσεων που αφορούν τις ανταλλαγές μηνυμάτων. Έτσι μια υπηρεσία μπορεί να επικοινωνήσει με μια άλλη χρησιμοποιώντας τα επιθυμητά πρωτόκολλα συνεργασίας. Μια βασική διαφορά από την προηγούμενη μέθοδο (BPEL4WS) είναι η κατανεμημένη εκτέλεση της σύνθετης επιχειρησιακής διεργασίας σε αντίθεση με την κεντρικοποιημένη εκτέλεση. Αυτό σημαίνει ότι αυτοί που συμμετέχουν σε μια χορογραφία αλληλεπιδρούν μεταξύ τους με βάση κάποιο καθολικό σενάριο χωρίς να υπάρχει ένα κοινό σημείο ελέγχου για όλους τους συμμετέχοντες σε μια αλληλεπίδραση. WS-CDL (Web Service Choreography Description Language)Αυτή η γλώσσα είναι επίσης βασισμένη πάνω στα πρότυπα της XML και έχει ως στόχο τον ορισμό της σύνθεσης συνεργασιών μακράς διάρκειας μεταξύ παροχέα και πελάτη διαδικτυακών υπηρεσιών. Μέσω αυτής της γλώσσας παρέχεται μια γενική και καθολική περιγραφή της εξωτερικής συμπεριφοράς που η υπηρεσία επιδεικνύει όπου η σειρά των ανταλλασσόμενων μηνυμάτων μεταξύ αυτών που συμμετέχουν σε μια συνεργασία έχει ως αποτέλεσμα την επίτευξη ενός κοινού επιχει-47-

51 ρησιακού στόχου. Η γλώσσα αυτή περιγράφει μόνο αφηρημένες διεργασίες και προτάθηκε λόγω της ανάγκης συνεργασίας πολλών διαφορετικών εταίρων ώστε να επιτευχθεί ένας κοινός στόχος. Σ αυτή τη συνεργασία οι κανόνες περιγράφονται σε φυσική γλώσσα και λείπει ένας προτυποποιημένος τρόπος ορισμού των αλληλεπιδράσεων και των κανόνων που διέπουν αυτή τη συνεργασία. Έτσι με τη χρήση της WS-CDL ορίζονται καθολικά η σειρά των μηνυμάτων και άλλων περιορισμών που αφορούν την ανταλλαγή τους. WSCL. Η γλώσσα WSCL(Web service Conversation Language) επιτρέπει τον ορισμό της εξωτερικής (καθολικής) συμπεριφοράς των υπηρεσιών καθορίζοντας τις αλληλεπιδράσεις τους στο επιχειρησιακό επίπεδο(όπως και η WS-CDL) καθώς και τις δημόσιες διεργασίες που υποστηρίζουν. Οι αλληλεπιδράσεις καθορίζουν τόσο τα XML έγγραφα που ανταλλάσσονται όσο και την επιτρεπόμενη σειρά με την οποία αυτά ανταλλάσσονται. Μέσω της WSCL επιτυγχάνεται ο διαχωρισμός της λογικής των αλληλεπιδράσεων από την επιχειρησιακή λογική και τα θέματα υλοποίησης μιας υπηρεσίας και μπορεί με αυτό τον τρόπο να χρησιμοποιηθεί συμπληρωματικά με την WSDL. BPML. Η BPML(Business Process Management Language) αποτελεί μια γλώσσα που μοντελοποιεί τόσο αφηρημένες όσο και εκτελέσιμων επιχειρησιακών διεργασιών. Παρέχει μεγαλύτερο εύρος επιλογών από τις προηγούμενες γλώσσες διότι εφαρμόζεται όχι μόνο σε περιπτώσεις σύνθεσης υπηρεσιών διαδικτύου αλλά και σε περιπτώσεις ολοκλήρωσης επιχειρησιακών εφαρμογών και ορισμού συνεργασίας στην οποία λαμβάνουν μέρος πολλοί συμμετέχοντες. Μια διεργασία στην γλώσσα BPML είναι μια σύνθεση δραστηριοτήτων και παρέχεται ευελιξία στον ορισμό της ροής ελέγχου, των δεδομένων και των γεγονότων με δομές ελέγχου όπως επιλογή υπό συνθήκη, σειριακή, επανάληψη και παράλληλη εκτέλεση. BPMN/XPDL. H BPMN(Business Process Modeling Notation) από μία παράσταση για τον ορισμό επιχειρησιακών διεργασιών σε μια ροή εργασίας. Το βασικότερο στοιχείο της είναι ένα διάγραμμα επιχειρησιακής διεργασίας (Business Process Diagram) και ο ορισμός της παρέχει αντιστοίχιση μεταξύ της γραφικής σημειογραφίας και των υποκείμενων δομών σε γλώσσες εκτέλεσης -48-

52 όπως π.χ. BPEL. Επιπροσθέτως η BPMN μπορεί να μοντελοποιεί τόσο εσωτερικές επιχειρησιακές διεργασίες όσο και αφηρημένες δημόσιες. Τέλος υποστηρίζει την υλοποίηση συνεργατικών διεργασιών οι οποίες εμπεριέχουν αλληλεπιδράσεις μεταξύ δύο ή περισσοτέρων εταίρων οι οποίες ενδέχεται να υλοποιούνται μέσω διαδικτυακών υπηρεσιών. Η XPDL (XML Process Definition Language) αποτελεί ένα XML πρότυπο και χρησιμοποιείται για την ανταλλαγή ορισμών επιχειρησιακών διεργασιών μεταξύ διαφορετικών εργαλείων και συστημάτων μοντελοποίησης. Τέλος χρησιμοποιείται ως πρότυπο ως πρότυπο ανταλλαγής διαγραμμάτων BPMN και αποθηκεύει πληροφορίες που είναι απαραίτητες για την εκτέλεση μιας διεργασίας αλλά και γραφικές πληροφορίες Ημιαυτοματοποιημένες μέθοδοι σύνθεσης υπηρεσιών διαδικτύου Σ αυτό το είδος μεθόδων επιχειρείται να αυτοματοποιηθεί ανά μόνο μέρος της διαδικασίας σύνθεσης διαδικτυακών υπηρεσιών. Ο ορισμός των αλληλεπιδράσεων γίνεται από τον χρήστη και ο ίδιος δεν αποδεσμεύεται από την αναζήτηση ανάμεσα σε μεγάλο πλήθος διαδικτυακών υπηρεσιών για υπηρεσίες που πληρούν τις προδιαγραφές και τα κριτήρια σύνθεσης. Αντ' αυτού ο ορισμός των διαδυκτιακών υπηρεσιών δεν είναι ορισμένος εκ των προτέρων αλλά γίνεται με δυναμικό τρόπο. Έτσι επιτυγχάνεται η ανεξαρτησία από την υλοποίηση στην περιγραφή των επιχειρησιακών διεργασιών. Ακόμη, από τη στιγμή που οι περιγραφές των διεργασιών είναι στατικές, η δομή της αλληλεπίδρασης μπορεί να περιγραφεί στατικά ενώ ο εντοπισμός και η επιλογή ατομικών υπηρεσιών γίνονται δυναμικά. Τέτοιου είδους προσεγγίσεις αποσκοπούν στη σύνθεση ροών εργασίας αντιστοιχώντας μια ροή εργασίας με μια συνθετική διαδικτυακή υπηρεσία. Έτσι αντιμετωπίζοντας το πρόβλημα της σύνθεσης ως ένα πρόβλημα ορισμού μιας ροής εργασίας τα επιτεύγματα της έρευνας στο πεδίο της αυτοματοποίησης ροών εργασίας μπορούν να εφαρμοστούν και να επωφελήσουν τη διαδικασία σύνθεσης υπηρεσιών ιστού. Η αυτοματοποίηση που επιτυγχάνεται έγκειται στην αναζήτηση και επιλογή για την κάθε επιμέρους εργασία μιας υπηρεσίας η οποία είναι σε θέση να την εκπληρώσει, ικανοποιώντας τους πιθανούς -49-

53 υπάρχοντες περιορισμούς. Τέλος το μοντέλο αφηρημένων διεργασιών πρέπει να είναι προκαθορισμένο από το χρήστη πριν από τη έναρξη της διαδικασίας σύνθεσης Αυτοματοποιημένες μέθοδοι σύνθεσης Οι μη αυτοματοποιημένες και οι ημι-αυτοματοποιημένες μέθοδοι που περιγράφθηκαν παραπάνω αποτελούν προσεγγίσεις οι οποίες αντιμετωπίζουν το πρόβλημα της σύνθεσης των υπηρεσιών θεωρώντας ότι ο κόσμος είναι στατικός και γνωστός. Αυτό ωστόσο απέχει από την πραγματικότητα από τη στιγμή που το διαδίκτυο αποτελεί ανοιχτό μέσο και ο κάθε παροχέας έχει τη δυνατότητα να προσφέρει συνεχώς νέες υπηρεσίες ή να τροποποιεί τις ήδη υπάρχουσες. Στη διαχείριση αυτού του μεγάλου και συνεχώς μεταβαλλόμενου όγκου υπηρεσιών διαδικτύου συμβάλλει ο σημασιολογικός ιστός και η αυτοματοποίηση της ανακάλυψης και σύνθεσης υπηρεσιών. Ωστόσο η διαδικασία της επεξεργασίας και σύνθεσης παρουσιάζει μεγάλη πολυπλοκότητα που οφείλεται στους εξής λόγους : μεγάλος αριθμός διαθέσιμων υπηρεσιών διαδικτύου. Ο αριθμός των υπηρε- σιών αυξάνεται συνεχώς λόγω της γρήγορης δημιουργίας νέων και εύκολης έκθεσης της λειτουργικότητας ήδη υπαρχόντων συστημάτων ως υπηρεσίες. Αυτό προϋποθέτει ότι θα πρέπει να πραγματοποιείται αναζήτηση σε αποθήκες στις οποίες υπάρχουν υπηρεσίες, οι οποίες συνεχώς αυξάνονται. Οι διαδικτυακές υπηρεσίες πολλές φορές τροποποιούνται με πιθανό αποτέλε- σμα να επηρεαστεί η εξωτερική τους διεπαφή καθώς και η επικοινωνία με αυτές. Για αυτό το λόγο η διαδικασία σύνθεσης θα πρέπει να είναι σε θέση να εντοπίσει τέτοιου είδους αλλαγές, ενώ αρκετές φορές προτείνεται η εκτέλεση της διαδικασίας από την αρχή. Διαφορετικότητα όσον αφορά τα μοντέλα εννοιών και τις φυσικές γλώσσες για την περιγραφή των υπηρεσιών. Με βάση τα υπάρχοντα πρότυπα η επικοινωνία ορίζεται με το πέρασμα παραμέτρων και υποστηρίζεται συντακτικός έλεγχος. Η σημασιολογία των παραμέτρων αυτών παίζει καθοριστικό ρόλο στη σύνθεση και η ταυτοποίηση και αντιστοίχιση αυτών των εννοιών στις παραμέτρους είναι μια χρονοβόρα και δύσκολη διαδικασία. -50-

54 Με βάση τα παραπάνω προκύπτει ότι η αυξανόμενη πολυπλοκότητα καθιστά το χρόνο που απαιτείται για τη μη αυτοματοποιημένη διαδικασία σύνθεσης ιδιαίτερα μεγάλο επομένως, η διαδικασία σύνθεσης κρίνεται σκόπιμο να στραφεί σε τεχνικές που ευνοούν την αυτοματοποίηση της. Οι τεχνικές αυτές διευκολύνουν τη διαδικασία της αυτοματοποίησης της διαδικασίας σύνθεσης υπηρεσιών από την ανακάλυψη των κατάλληλων ατομικών υπηρεσιών μέχρι και την παραγωγή της ροής εργασίας έως ένα τελικό πλάνο σύνθεσης. Παρακάτω παρατίθενται οι τεχνικές που έχουν προταθεί. Σχεδιασμός σε Ιεραρχικά Δίκτυα Διεργασιών(Hierarchical Task Network) Αυτές οι τεχνικές προσεγγίζουν το πρόβλημα της σύνθεσης σε διάφορα επίπεδα αφαίρεσης και βασίζονται στην ιεραρχική αποσύνθεση με βάση τα δίκτυα διεργασιών. Η είσοδος στο σύστημα σχεδιασμού αποτελείται από ένα αρχικό δίκτυο διεργασιών το οποίο αντιπροσωπεύει το πρόβλημα προς επίλυση(ουσιαστικά τις απαιτήσεις της σύνθετης υπηρεσίας). Ένα δίκτυο διεργασιών αποτελείται από αφηρημένες διεργασίες που ορίζονται με βάση άλλες διεργασίες. Υπάρχουν 3 είδη διεργασιών : οι πρωταρχικές (primitive tasks) οι οποίες αντιστοιχούν σε απλούς τελεστές STRIPS και μπορούν να εκτελεστούν κατευθείαν οι σύνθετες (compound tasks) οι οποίες αποτελούνται από ένα σύνολο απλού- στερων διεργασιών οι διεργασίες-στόχοι (goal tasks) οι οποίες αποτελούν τις επιθυμητές ιδιότητες μιας τελικής κατάστασης, δηλ μια σύνθετη διαδικτυακή υπηρεσία. Ακόμα παρέχεται ένα σύνολο τελεστών που περιγράφουν τα αποτελέσματα κάθε πρωταρχικής διεργασίας και ένα σύνολο μεθόδων που καθορίζουν πως οι σύνθετες διεργασίες μπορούν να διασπαστούν σε απλούστερες. Με βάση τη διαδικασία σχεδιασμού, αφού αρχικά αποσυντεθούν όλες οι σύνθετες διεργασίες σε πρωταρχικές γίνεται εύρεση ενός πλάνου που ικανοποιεί όλους τους περιορισμούς. Αυτό το πλάνο αποτελεί περιγραφή της σύνθετης διαδικτυακής υπηρεσίας και αποτελείται μόνο από πρωταρχικές. -51-

55 Σχεδιασμός Ενεργειών με Εκτίμηση Αναγωγής (Estimated Regression Planners) Σε αυτά τα συστήματα οι έξοδοι της επιθυμητής σύνθετης διαδικτυακής υπηρεσίας αναπαρίστανται ως μια κατάσταση-στόχος (goal state), οι είσοδοί της ως αρχική κατάσταση (initial state) ενώ οι διαθέσιμες ατομικές υπηρεσίες αναπαρίστανται ως τελεστές που μετατρέπουν μια κατάσταση σε άλλη. Τα Σ.Ε.Ε.Α. Χρησιμοποιούν ανάστροφη ανάλυση της δυσκολίας του στόχου ώστε να καθοδηγήσουν μια ορθή αναζήτηση της λύσης στο χώρο των καταστάσεων. Η αναζήτηση καθοδηγείται από έναν ευριστικό εκτιμητή που καθορίζεται με χρήση ανάστροφης συλλογιστικής σε ένα χώρο προβλήματος που προκύπτει από χαλάρωση, η οποία αγνοεί τις αλληλεπιδράσεις μεταξύ των τελεστών που επιτυγχάνουν στόχους και αγνοεί πλήρως τις διαγραφές. Για τη χρήση τους στο πεδίο της σύνθεσης υπηρεσιών διαδικτύου έχει προταθεί η επέκταση των κλασικών συμβολισμών όπως πχ η PDDL. Η εκτέλεση μιας υπηρεσίας μπορεί να έχει ως αποτέλεσμα την παραγωγή πληροφορίας ωστόσο κάτι τέτοιο σε ορισμένες περιπτώσεις δεν αναπαρίσταται κατάλληλα με τη δομή : effect της PDDL. Αυτή η πληροφορία θεωρείται ως τιμή ενός τελεστή η οποία μπορεί να δράσει ως είσοδος σε μεταγενέστερα βήματα του πλάνου. Ακόμα η PDDL για τον ορισμό της επεκτείνεται συμπεριλαμβάνοντας τη δομή :value στον ορισμό των τελεστών, η οποία εκτός από την πραγματική τιμή των δεδομένων που επιστρέφονται από μία υπηρεσία έχει τη δυνατότητα να εκφράσει και τους τύπους αυτών των δεδομένων. Σχεδιασμός με Έλεγχο μοντέλων (Planning as Model Checking) Ο σχεδιασμός μοντέλων βασίζεται στην ιδέα της μοντελο θεωρητικής επίλυσης προβλημάτων σχεδιασμού ενεργειών. Τα πεδία ορισμού τυποποιούνται σε σημασιολογικά μοντέλα, οι ιδιότητες τους ως χρονικοί τύποι ενώ ο σχεδιασμός πραγματοποιείται εξερευνώντας το χώρο καταστάσεων του σημασιολογικού μοντέλου και επαληθεύοντας σε κάθε βήμα την αλήθεια των χρονικών τύπων. Μερικά πλεονεκτήματα αυτής της προσέγγισης είναι η καλή θεμελίωση, η ξεκάθαρη τυποποίηση των προβλημάτων και το γεγονός ότι μπορεί να καλύψει ένα μεγάλο εύρος προβλημάτων σχεδιασμού. -52-

56 Λογισμός καταστάσεων Με βάση αυτή την προσέγγιση, το πρόβλημα της σύνθεσης αντιμετωπίζεται μέσω του ορισμού γενικών αφηρημένων προτύπων διεργασιών τα οποία τροποποιούνται μέσω προσαρμοζόμενων διεργασιών. Η γενική ιδέα πίσω από την προσέγγιση βασίζεται σε ευφυείς πράκτορες οι οποίοι έχουν τη δυνατότητα να πραγματοποιούν συλλογισμούς πάνω στις υπηρεσίες με σκοπό την αυτόματη ανακάλυψη, εκτέλεση και σύνθεση τους. Οι απαιτήσεις του χρήστη και οι περιορισμοί αναπαρίστανται με τη βοήθεια του λογισμού καταστάσεων και κάθε υπηρεσία αντιστοιχεί σε ένα τελεστή, είτε πρωταρχικό (μπορεί να αλλάξει την κατάσταση του κόσμου ή να παράγει κάποια πληροφορία) είτε σύνθετο ( αποτελείται από πολλούς πρωταρχικούς). Η βάση γνώσης των πρακτόρων παρέχει μια λογική κωδικοποίηση των προϋποθέσεων και των αποτελεσμάτων των διαδικτυακών υπηρεσιών με όρους λογισμού καταστάσεων. Τέλος οι πράκτορες χρησιμοποιούν δομές διαδικαστικών γλωσσών προγραμματισμού για να συνδέσουν ατομικές υπηρεσίες με στόχο τη δημιουργία μιας σύνθετης. Η προσέγγιση αυτή διαφέρει από τις άλλες τεχνικές σχεδιασμού ενεργειών όσον αφορά τον τρόπο με τον οποίο περιγράφεται η κατάσταση του κόσμου. Αυτό επιτυγχάνεται μέσω συναρτήσεων f που περιέχουν σχεσιακές μεταβλητές, οι οποίες περιέχουν όρους τ που περιγράφουν μια κατάσταση s : f(τ, s). Τα κύρια στοιχεία του λογισμού είναι οι τελεστές (actions) που μπορούν να εφαρμοστούν στον κόσμο, οι μεταβλητές (fluents) που περιγράφουν την κατάσταση του κόσμου και οι καταστάσεις (situations). Ένα πεδίο ορισμού περιγράφεται από ένα σύνολο τύπων που περιλαμβάνουν για κάθε τελεστή τα αξιώματα προϋποθέσεων του, για κάθε μεταβλητή τα αξιώματα της διαδοχικής κατάστασης, τα αξιώματα που περιγράφουν τον κόσμο στις διάφορες καταστάσεις και τα θεμελιώδη αξιώματα του λογισμού καταστάσεων. -53-

57 Σχεδιασμός με Χρήση Κανόνων Με βάση αυτή την προσέγγιση για κάθε υπηρεσία διαδικτύου δημιουργείται ένας κανόνας Horn που υποδεικνύει τα αποτελέσματα που θα επιτευχθούν εάν αληθεύουν οι προϋποθέσεις του. Η διαδικασία της σύνθεσης απαιτεί τον ορισμό των αρχικών και τελικών καταστάσεων και το πλάνο λαμβάνεται με χρήση ενός έμπειρου συστήματος βασισμένου σε κανόνες. Αν το πλάνο αυτό είναι ικανοποιητικό, ο χρήστης ζητά την αναπαράσταση του ως υπηρεσία διαδικτύου και την εκτέλεση του. Σε αντίθετη περίπτωση (μη προβλεπόμενες συμπεριφορές) απαιτείται η παρέμβαση του χρήστη πριν τη συνέχιση της εκτέλεσης. Απόδειξη Θεωρημάτων Η Αυτόματη Απόδειξη Θεωρημάτων(Automated Theorem Proving) αποτελεί άλλη μια μέθοδο σύνθεσης υπηρεσιών. Με βάση αυτή οι διαθέσιμες υπηρεσίες και οι απαιτήσεις των χρηστών περιγράφονται σε μια γλώσσα πρώτης τάξης που σχετίζεται με την κλασική λογική και στη συνέχεια δημιουργούνται αποδείξεις. Τέλος οι περιγραφές των σύνθετων υπηρεσιών εξάγονται από συγκεκριμένες αποδείξεις. Μετασχηματισμός προβλήματος και Σύνθεση μέσω Κλασικού Σχεδιασμού Ενεργειών Πρόκειται για την τεχνική στην οποία βασίστηκε η συγκεκριμένη πτυχιακή εργασία. Η γενική ιδέα πίσω από την εφαρμογή αυτής της μεθόδου είναι ότι κάθε υπηρεσία διαδικτύου μπορεί να μετασχηματιστεί και να αναπαρασταθεί με όρους σχεδιασμού ενεργειών αντιστοιχίζοντας απευθείας τμήματα της WSDL περιγραφής σε στοιχεία ενός πεδίου ορισμού και ενός αντίστοιχου προβλήματος σχεδιασμού ενεργειών ή σε στοιχεία PDDL γενικότερα. Ένα τυπικό πρόβλημα σχεδιασμού ενεργειών περιγράφεται από μια αρχική και μια τελική κατάσταση και από τους διαθέσιμους τελεστές, οι οποίοι επιτρέπουν μεταβάσεις μεταξύ των καταστάσεων. Για κάθε ένα από τους τελεστές πρέπει να καθοριστούν οι προϋποθέσεις του, δηλ το σύνολο των γεγονότων που πρέπει να ισχύουν στην τρέχουσα -54-

58 κατάσταση για να είναι δυνατή η εφαρμογή του τελεστή, και τα αποτελέσματα του, από τα οποία προκύπτει η κατάσταση του κόσμου μετά την εφαρμογή του τελεστή. Όπως και ένας τελεστής έτσι και μια υπηρεσία διαδικτύου λαμβάνει κάποιες εισόδους και παράγει κάποιες εξόδους οι οποίες μπορούν αντίστοιχα να παρασταθούν ως προϋποθέσεις και αποτελέσματα τελεστών αντίστοιχα. Μια ατομική υπηρεσία μεταβάλλει την κατάσταση του κόσμου. Εάν οι είσοδοι της υπηρεσίας (δεδομένα τα οποία μπορεί να παρέχει ο χρήστης) περιγραφούν ως αρχική κατάσταση και οι έξοδοι της (τα αποτελέσματα που επιζητά ο χρήστης) σαν τελική κατάσταση, τότε αλγόριθμοι σχεδιασμού ενεργειών είναι σε θέση να σχηματίσουν πλάνα σύνθεσης αυτόματα χωρίς την ανάγκη ύπαρξης προηγούμενης γνώσης ή προκαθορισμένης ροής εργασιών. Ένα μεγάλο πλεονέκτημα αυτής της προσέγγισης είναι ότι ανεξαρτητοποιείται η περιγραφή του προβλήματος από την επίλυση του και δεν απαιτείται καμία τροποποίηση στα συστήματα σχεδιασμού ενεργειών αντίθετα με προσεγγίσεις που αναφέρθηκαν πιο πριν, οι οποίες επέκτειναν το όποιο σύστημα σχεδιασμού ώστε να μπορεί να αντιμετωπίσει υπηρεσίες διαδικτύου. Έτσι δίνεται η δυνατότητα χρήσης οποιουδήποτε αλγορίθμου ή τεχνικής σχεδιασμού ενεργειών. -55-

59 4 Το εργαλείο Web Planner 4.1 Εισαγωγικά Το κεφάλαιο ασχολείται με το εργαλείο που υλοποιήθηκε και ονομάζεται Web Planner. Το εργαλείο Web Planner αποτελεί μια JAVA εφαρμογή η οποία επιτυγχάνει σύνθεση υπηρεσιών ιστου. Η εφαρμογή αυτή δοκιμάστηκε σε υπηρεσίες απο το Internet καθώς και σε δύο υπηρεσίες που υλοποιήθηκαν με σκοπό να δοκιμαστεί σε πολύπλοκα δεδομένα. Οι φάσεις υλοποίησης της εφαρμογής περιλαμβάνουν : Λεξική ανάλυση της υπηρεσίας(φάση Parsing). Όπως έχει αναφερθέι στο κεφάλαιο 3, μια υπηρεσία μπορεί να περιγραφεί με τη χρήση της γλώσσας περιγραφής των υπηρεσιών διαδικτύου (ή αλλιώς W.S.D.L.). Στην φάση της λεξικής ανάλυσης του αρχείου αυτής της περιγραφής αντλήθηκαν όλες οι πληροφορίες και λεπτομέριες που απαιτούνταν για τη διαδικασία της σύνθεσης όπως οι λειτουργίες που εκτελεί η υπηρεσία,οι παράμετροι που δέχονται, τα πρωτόκολλα επικοινωνίας, ο τρόπος ανταλλαγής μηνυμάτων, η τοποθεσία της υπηρεσίας στο δίκτυο κ.α. Δημιουργία του αρχείου των τελεστών(domain.pddl). Εδώ με βάση την πληροφορία που προέκυψε κατα το Parsing συντάχθηκε ένα αρχείο σε μορφή pddl με σκοπό να περιγραφούν και να αναπαρασταθούν οι λειτουργίες της. Δημιουργία του αρχείου με το πρόβλημα(problem.pddl). Το αρχείο αυτό ουσιαστικά περιγράφει τον στόχο του κάθε χρήστη της υπηρεσίας. Η φάση του πλάνου. Σε αυτό το σημείο η εφαρμογή έχει συγκεντρώσει όλες τις απαραίτητες πληροφορίες που απαιτεί και εκτελεί το πλάνο, δηλ ψάχνει να βρεί σενάρια σύνθεσης. Έτσι το πρόβλημα της συνθεσης υπηρεσιών ανάγεται σε πρόβλημα σχεδιασμού. -56-

60 Για την αποτελεσματικότερη συνεργασία χρήστη- εφαρμογής υλοποιήθηκε το γραφικό περιβάλλον της το οποίο αναλύεται παρακάτω. 4.2 Ανάλυση κλάσεων και τεχνικές λεπτομέριες του εργαλείου WebPlanner Η εφαρμογή Web Planner υλοποιήθηκε σε JAVA και συγκεκριμένα στο περιβάλλον NetBeans. Βασικό στοιχείο της είναι η βιβλιοθήκη WSDL4j μέσω της οποίας έγινε η λεξική ανάλυση του αρχείου της περιγραφής της υπηρεσίας. Η εφαρμογή αποτελείται απο τρείς κλάσεις. Πιο συγκεκριμένα : Κλάση WSDLParse : αποτελεί τη βασικότερη κλάση και τον πυρήνα της εφαρμογής. Η κλάση περιλαμβάνει τις εξής μεθόδους : 1. WSDLtoPDDL() : γίνεται λεξική ανάλυση της περιγραφής της υπηρεσίας. Η μέθοδος έχει ως αποτέλεσμα την παραγωγή του αρχείου domain.pddl. Το αρχείο αυτό αποτελεί μια περιγραφή της υπηρεσίας σε PDDL. 2. UserParameters() : εδώ ο χρήστης επιλέγει την πληροφορία που έχει καθώς και την πληροφορία που θέλει να αποκτήσει. Η μέθοδος παράγει το αρχείο problem.pddl που είναι μια περιγραφή του προβλήματος σε PDDL. Με τον όρο πρόβλημα αναφερόμαστε περισσότερο στον στόχο του πελάτη κατα το πλάνο του σχεδιασμού. 3. Plan() : είναι η μέθοδος που καλεί τον Planner. Στην συγκεκριμένη εφαρμογή χρησημοποιήθηκε ο LPG Planner. 4. RemovePunct() : μέθοδος για την αφαίρεση σημείων στίξης. Αυτό συμβαίνει διότι ο Planner δεν αναγνωρίζει σημεία στίξης. 5. GetallPredicates() : η μέθοδος επιστρέφει όλα τα δεδομένα της υπηρεσίας. 6. InitialstatePar() και goalstatepar() : πρόκειται για δυο μεθόδους που χρησημοποιούνται απο το GUI για τη μεταφορα πληροφορίας. -57-

61 Κλάση Main : στην κλάση αυτή καλέιται μόνο μια συνάρτηση του GUI. Κλάση GUI : η κλάση υλοποιεί το γραφικό περιβάλλον της εφαρμογής με τη χρήση της JAVA Swing. Η εφαρμογή για την εκτέλεσή της απαιτούσε τη συμμετοχή ενός Planner για το σκοπό της σύνθεσης των υπηρεσιών. Απο τη στιγμή που χρησιμοποιήθηκαν αρχεία σε μορφή PDDL, η εφαρμογή επιστράτευσε τον LPG-TD Planner, ο οποίος μπορεί να χειριστεί τις περισσότερες απο τις γλώσσες σχεδιασμού πλάνων. Στη φάση του πλάνου θα αναλυθεί πιο συγκεκριμένα στο εργαλείο LPG-TD. 4.3 Φάσεις υλοποίησης και Ανάλυση κώδικα Όπως αναφέρθηκε και πιο πάνω η υλοποίηση της εφαρμογής επιτεύχθηκε σε τέσσερις φάσεις. Κατα τη διάρκεια τους έγινε λεξική ανάλυση της περιγραφής της υπηρεσίας, αναγωγή του προβλήματος σύνθεσης σε πρόβλημα σχεδιασμού και εύρεση μονοπατιών δηλ, σενάρια σύνθεσης που ικανοποιούν τις ανάγκες του χρήστη. Παρακάτω παρατίθεται η ανάλυση των φάσεων με στιγμιότυπα απο τον κώδικα του εργαλείου καθώς και απαραίτητες πληροφορίες για την κατανόηση της φιλοσοφίας που διέπει την λειτουργία του Λεξική ανάλυση της υπηρεσίας (φάση Parsing) Όπως αναφέρθηκε στο κεφάλαιο 3 οι υπηρεσίες διαδικτύου περιγράφονται μεσω της γλώσσας περιγραφής υπηρεσιών διαδικτύου(web Service Description Language, W.S.D.L). Η γλώσσα αυτή χρησημοποιεί αυστηρούς κανόνες σύνταξης και για την ανάλυση των αρχείων WSDL χρησημοποιήθηκε η βιβλιοθήκη WSDL4j. -58-

62 Εικόνα 4.1 Στο παραπάνω τμήμα κώδικα φαίνονται δηλώσεις πακέτων που αφορούν το Parsing και βρίσκονται στη βιβλιοθήκη WSDL4j.Η βιβλιοθήκη WSDL4j παρέχει μεθόδους για την εξόρυξη απαραίτητων πληροφοριών που αφορούν την υπηρεσία. Πριν προχωρήσει η ανάλυση, θα ήταν χρήσιμο να παρατεθεί μια βασική δομή των μερών μιας υπηρεσίας. Εικόνα 4.2 Στην εικόνα παραπάνω φαίνεται η ιεραρχιά των μερών που συνθέτουν τη δομή μιας υπηρεσίας. Όπως φαίνεται μια υπηρεσία αποτελείται απο ένα ή περισσότερα στοιχει Port. Καθένα απο αυτά αποτελεί ένα στιγμιότυπο ενός endpoint. Ένα ή και περισσότερα -59-

63 απο αυτά τα Ports περιέχουν ένα στοιχείο Binding. Μέσα σε κάθε Binding υπάρχουν στοιχεία PortType, τα οποία αποτελούν συλλογές απο στοιχεία Operation. Ένα στοιχείο Operation αναπαριστά μια λειτουργία που εκτελεί η υπηρεσία και περιλαμβάνει στοιχεία message. Ένα στοιχείο message ανάλογα με τον τύπο της λειτουργίας (request, request response κ.α.) περιλαμβάνει ανάλογο αριθμό από στοιχεία message τα οποία αντιστοιχούν στην είσοδο και έξοδο της λειτουργίας της υπηρεσίας. Τέλος κάθε στοιχείο message αποτελείται απο ένα ή περισσότερα στοιχεία Part, τα οποία κρατούν την πληροφορία της υπηρεσίας. Κατα τη φάση του Parsing το εργαλείο χρειάζεται να βρεί μέσα στην περιγραφή της υπηρεσίας δύο βασικά πράγματα : Τις λειτουργίες (operation) που εκτελεί μια υπηρεσία, οι οποίες βρίσκονται μέσα στις συλλογές PortType, την είσοδο και έξοδο που δέχεται κάθε μια λειτουργία. Η είσοδος μιας λειτουργίας μπορεί να αναπαρίσταται ως στοιχείο input, message ή part. Το ίδιο ισχύει και για την έξοδο της. Στο παρακάτω τμήμα κώδικα φαίνεται ο τρόπος με τον οποίο η εφαρμογή βρίσκει τις λειτουργίες μιας υπηρεσίας δοθέντος μόνο ενός endpoint. Το Endpoint αποτελεί τη διελυθυνση στην οποία υπάρχει η περιγραφή της υπηρεσίας σε WSDL. -60-

64 Εικόνα 4.3 Όπως φαίνεται κατά τη διαδικασία του Parsing ακολουθείται αυστηρά η ιεραρχία που ορίζεται στην εικόνα 4.2. Έτσι αφού ανακτηθεί το endpoint της υπηρεσίας μέσω των μεθόδων getservice(), getports(), getbinding(), getporttype() και getoperations() παράγεται μια λίστα με τα ονόματα όλων των λειτουργιών που εκτελεί η υπηρεσία (όπως αυτά ονομάζονται στην περιγραφή της). Σ' αυτή τη φάση η εφαρμογή έχει συγκεντρώσει όλες τις λειτουργίες της υπηρεσίας που αναλύει και ψάχνει την είσοδο και την έξοδο για κάθε μια απο αυτές. Έτσι δημιουργούνται για την κάθε λειτουργία δύο λίστες, μια λίστα με τα δεδομένα που δέχεται ώς είσοδο και μια με τα δεδομένα που δέχεται ως έξοδο. Όπως αναφερθήκαμε και παραπάνω τόσο η είσοδος όσο και η έξοδος είναι input, message ή part στοιχείο. Για λόγους απόδοσης και ευκολίας προς το χρήστη, το Parsing γίνεται στα στοιχεία Part, διότι αποτελούν την καλύτερη και πιο κατανοητή μορφή αναπαράστασης των δεδομένων που χειρίζεται η υπηρεσία. Ουσιαστικά τα στοιχεία part περιλαμβάνουν παραμέτρους δεδομένα που αντιστοιχούν σε πεδία όπως ένα username, μια ηλικία κ.α. -61-

65 Εικόνα 4.4 Στο παραπάνω τμήμα κώδικα περιγράφεται ο τρόπος που γεμίζει η λίστα με τις εισόδους που δέχεται κάποια λειτουργία. Για τη λίστα με τα δεδομένα εξόδου μιας λειτουργίας ισχύει η ίδια φιλοσοφία με τη μόνη διαφορά οτι αλλάζει η εντολή getinput() σε getoutput(). Κάποιες λειτουργίες μπορούν να χρησημοποιούν ως είσοδο ή έξοδο κοινές παραμέτρους. Γι' αυτό το λόγο γίνεται έλεγχος για διπλοεγγραφές Δημιουργία του αρχείου των τελεστών(domain.pddl) Σ' αυτή τη φάση η εφαρμογή έχει τις απαραίτητες πληροφορίες για κάθε λειτουργία(όνομα, δεδομένα εισόδου και δεδομένα εξόδου). Το επόμενο βήμα είναι η δημιουργία του αρχείου των τελεστών (domain.pddl). Αυτό είναι ένα σημαντικό σημείο της διαδικασίας γιατί το πρόβλημα της σύνθεσης ξεκινά να μετατρέπεται σε πρόβλημα σχεδιασμού. Ένα πρόβλημα σχεδιασμού ενεργειών περιγράφεται από μια αρχική και μια τελική κατάσταση(initial state, goal state) και από τους διαθέσιμους τελεστές (actions), οι οποίοι επιτρέπουν μεταβάσεις μεταξύ των καταστάσεων. Για κάθε ένα από τους τελεστές πρέπει να καθοριστούν οι προϋποθέσεις του(precondition list), δηλ το σύνολο των γεγονότων που πρέπει να ισχύουν στην τρέχουσα κατάσταση για να είναι δυνατή η εφαρμογή του τελεστή, και τα αποτελέσματα του(add list), από τα οποία προκύπτει η κατάσταση του κόσμου μετά την εφαρμογή του τελεστή. Όπως και ένας τελεστής έτσι και μια υπηρεσία διαδικτύου λαμβάνει κάποιες εισόδους και παράγει κάποιες εξόδους οι οποίες μπορούν αντίστοιχα να παρασταθούν ως προϋποθέσεις και αποτελέσματα τελεστών -62-

66 αντίστοιχα. Μια ατομική υπηρεσία μεταβάλλει την κατάσταση του κόσμου. Εάν οι είσοδοι της υπηρεσίας (δεδομένα τα οποία μπορεί να παρέχει ο χρήστης) περιγραφούν ως αρχική κατάσταση και οι έξοδοι της (τα αποτελέσματα που επιζητά ο χρήστης) σαν τελική κατάσταση, τότε αλγόριθμοι σχεδιασμού ενεργειών είναι σε θέση να σχηματίσουν πλάνα σύνθεσης αυτόματα χωρίς την ανάγκη ύπαρξης προηγούμενης γνώσης ή προκαθορισμένης ροής εργασιών. Με βάση τα παραπάνω, η εφαρμογή αντιστοιχεί κάθε λειτουργία σε ένα τελεστή (με όνομα το όνομα της λειτουργίας). Οι είσοδοι της λειτουργίας γίνονται προυποθέσεις του τελεστή και οι έξοδοι της υπηρεσίας αποτελέσματα του. Η περιγραφή του προβλήματος της σύνθεσης πλέον γίνεται σε γλώσσα PDDL. Η γλώσσα αυτή ακολουθεί αυστηρούς κανόνες σύνταξης και δεν δέχεται σημεία στίξης γεγονός που φαίνεται απο το παρακάτω τμήμα κώδικα. Ο κώδικας που παρατίθεται παραπάνω δημιουργεί ένα τελεστή με όνομα Opname, που αντιστοιχεί στο όνομα κάποιας λειτουργίας, η οποία έχει μόνο μία προυπόθεση (αρα ένα στοιχείο input) και παραπάνω απο ένα αποτέλεσμα(άρα περισσότερα του ενός στοιχεία output). Μ' αυτόν τον τρόπο ολοκληρώνεται η φάση της δημιουργίας των τελεστών. -63-

67 4.3.3 Δημιουργία του αρχείου με το πρόβλημα(problem.pddl) Από τη στιγμή που ολοκληρωθεί το αρχείο των τελεστών το μόνο που απομένει για την εκτέλεση του πλάνου είναι ο ορισμός του αρχείου με το πρόβλημα. Με τον όρο πρόβλημα ανφερόμαστε στον στόχο του πελάτη δηλ, στην πληροφορία που αποσκοπεί. Όπως αναφέρθηκε και παραπάνω η PDDL ακολουθεί αυστηρούς κανόνες σύνταξης γεγονός που τηρείται και κατά τη διάρκεια της δημιουργείας του αρχείου problem.pddl. Το αρχείο με το πρόβλημα δημιουργείται κατα τη διάρκεια εκτέλεσης της μεθόδου UserParameters(). Μέσα στο αρχείο καθορίζονται η αρχική και η κατάσταση στόχος. Στην παρακάτω εικόνα απεικονίζεται ένα αρχείο που εκφράζει ένα πρόβλημα σε pddl. Εικόνα 4.5 Η αρχική κατάσταση περιλαμβάνει τις παραμέτρους Password και ID ενώ η κατάσταση στόχος περιλαμβάνει τις παραμέτρους Address και TaxOffice Η φάση του πλάνου Σ' αυτό το σημείο έχουν παραχθεί τόσο το αρχείο με τους τελεστές όσο και το αρχείο με την διατύπωση του προβλήματος. Το εργαλείο WebPlanner μέσω της συνάρτησης Plan() καλεί τον Planner. Στην εφαρμογή χρησιμοποιήθηκε ο LPG-TD Planner. -64-

68 Εικόνα 4.6 Στο παραπάνω τμήμα κώδικα φαίνεται η παράμετρος που δέχεται ο Planner(cmd). Μεταξύ των παραμέτρων ο Planner χρειάζεται το όνομα του αρχείου με τους τελεστές και το όνομα του αρχείου με το πρόβλημα. Τέλος ο Planner εκτελείται μέσω του Command Line. Στο παραπάνω τμήμα του κεφαλαίου περιγράφηκε η φάση της υλοποίησης. Ο κώδικας ανήκε στην κλάση WSDLtoPDDL η οποία υλοποιεί το Parsing και τη δημιουργία των δύο αρχείων(τελεστών και προβλήματος). Παρακάτω αναλύεται το τμήμα του γραφικού περιβάλλοντος. 4.4 Γραφικό περιβάλλον (Graphic-User Interface) Το γραφικό περιβάλλον υλοποιήθηκε μέσα στην κλάση GUI με τη χρήση Java Swing. Το γραφικό περιβάλλον απο τρία βασικά παράθυρα. Παρακάτω παρατίθενται στιγμοιότυπα απο το εργαλείο WebPlanner. -65-

69 Εικόνα 4.7 Κατά την έναρξη της εφαρμογής ο χρήστης πρέπει να δώσει τρείς βασικές πληροφορίες στο σύστημα. Πρώτον το URL στο οποίο υπάρχει η περιγραφή της υπηρεσίας, δεύτερον το όνομα της υπηρεσίας και τέλος το PortType της υπηρεσίας. Όπως έχει αναφερθεί στο κεφάλαιο 2 το πρωτόκολλο που χρησημοποιούν οι υπηρεσίες είναι το SOAP. Το κουμπί Parse καλεί την συνάρτηση WSDLtoPDDL() και πραγματοποιείται η λεξική ανάλυση του αρχέιου.παρακάτω παρατίθεται ένα στιγμιότυπο απο το παράθυρο που αναδύεται μετα το Parse. -66-

70 Εικόνα 4.8 Όπως φαίνεται παραπάνω ο χρήστης καλείται να επιλέξει τις παραμέτρους που ανήκουν στην αρχική και τελική κατάσταση του προβλήματος. Έπειτα με το κουμπί Create Problem καλείται η συνάρτηση UserParameters() και δημιουργείται το αρχείο του προβλήματος. Σ' αυτό το σημείο η εφαρμογή έχει στη διάθεση της τα δύο αρχεία και με το κουμπί Plan Solution καλείται ο Planner με το αποτέλεσμα της αναζήτησης μονοπατιών. -67-

71 Εικόνα 4.9 Στην παραπάνω εικόνα παρατίθεται το παράθυρο με το αποτέλεσμα του Planner. Όπως φαίνεται έχει βρεθεί ένα πλάνο (Plan Computed). Με βάση αυτό το πλάνο μέσω των τελεστών LOGIN, BROWSE ADDRESS KAI BROWSE REPORT OFFICE ο χρήστης μπορεί να οδηγηθεί απο την αρχική κατάσταση στην κατάσταση που επέλεξε ως στόχο. Μ' αυτό τον τρόπο η σύνθεση των υπηρεσιών ανάγεται σε πρόβλημα σχεδιασμού και υπολογίζονται τα πιθανά μονοπάτια που αντιστοιχούν στις σύνθετες υπηρεσίες. -68-