ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ & ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΤΗΣ ΠΛΗΡΟΦΟΡΙΑΣ

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ & ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΤΗΣ ΠΛΗΡΟΦΟΡΙΑΣ ΔΙΑΔΙΚΤΥΑΚΕΣ ΥΠΗΡΕΣΙΕΣ ΚΑΙ ΕΦΑΡΜΟΓΕΣ ΓΙΑ ΕΠΕΞΕΡΓΑΣΙΑ ΚΑΙ ΑΠΕΙΚΟΝΙΣΗ ΙΑΤΡΙΚΩΝ ΔΕΔΟΜΕΝΩΝ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ ΣΑΡΑΝΤΟΠΟΥΛΟΣ ΧΑΡΑΛΑΜΠΟΣ του ΓΕΩΡΓΙΟΥ Α.Μ : 5759 ΕΠΙΒΛΕΠΩΝ : ΕΠΙΚΟΥΡΟΣ ΚΑΘΗΓΗΤΗΣ Μ.ΚΟΥΚΙΑΣ ΑΡΙΘΜΟΣ ΔΙΠΛΩΜΑΤΙΚΗΣ ΕΡΓΑΣΙΑΣ : ΦΕΒΡΟΥΑΡΙΟΣ 2011

2 1

3 ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η διπλωματική εργασία με θέμα: ΔΙΑΔΙΚΤΥΑΚΕΣ ΥΠΗΡΕΣΙΕΣ ΚΑΙ ΕΦΑΡΜΟΓΕΣ ΓΙΑ ΕΠΕΞΕΡΓΑΣΙΑ ΚΑΙ ΑΠΕΙΚΟΝΙΣΗ ΙΑΤΡΙΚΩΝ ΔΕΔΟΜΕΝΩΝ Του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών ΣΑΡΑΝΤΟΠΟΥΛΟΥ ΧΑΡΑΛΑΜΠΟΥ ΤΟΥ ΓΕΩΡΓΙΟΥ (Α.Μ 5759) Παρουσιάστηκε δημόσια και εξετάσθηκε στο Τμήμα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις 10/02/2011. Ο Επιβλέπων Ο Διευθυντής του Τομέα Μ.ΚΟΥΚΙΑΣ Επικουρ. Καθηγητής Ν. ΦΑΚΩΤΑΚΗΣ Καθηγητής 2

4 ΠΡΟΛΟΓΟΣ Η παρούσα εργασία με θέμα : ΔΙΑΔΙΚΤΥΑΚΕΣ ΥΠΗΡΕΣΙΕΣ ΚΑΙ ΕΦΑΡΜΟΓΕΣ ΓΙΑ ΕΠΕΞΕΡΓΑΣΙΑ ΚΑΙ ΑΠΕΙΚΟΝΙΣΗ ΙΑΤΡΙΚΩΝ ΔΕΔΟΜΕΝΩΝ πραγματεύεται την τεχνολογία στην οποία στηρίζονται και υλοποιούνται τα web services, καθώς και την εφαρμογή τους σε ιατρικά θέματα. Πριν ξεκινήσω την αναλυτική παρουσίαση της εργασίας θα ήθελα να ευχαριστήσω τον καθηγητή μου κ. Μ. Κουκιά, τόσο για την εμπιστοσύνη που μου έδειξε αναθέτοντας μου την εργασία, όσο και για τις πολύτιμες συμβουλές του κατά την διάρκεια της εκπόνησης της, όπως και τον μεταπτυχιακό φοιτητή του τμήματος ηλεκτρολόγων μηχανικών και τεχνολογίας υπολογιστών κ. Θοδωρή Παναγιωτακόπουλο για τις χρήσιμες πληροφορίες του και την καθοδήγησή του. Τέλος, ευχαριστώ τους γονείς μου για την αμέριστη συμπαράσταση και υποστήριξη που μου προσέφεραν όλα αυτά τα χρόνια. ΣΑΡΑΝΤΟΠΟΥΛΟΣ ΧΑΡΑΛΑΜΠΟΣ ΦΕΒΡΟΥΑΡΙΟΣ

5 ΠΕΡΙΕΧΟΜΕΝΑ Εισαγωγή 11 Κεφάλαιο Εισαγωγή στα web services Τι είναι τα web services Ποιότητα παρεχόμενων υπηρεσιών (quality of service QoS) Πλεονεκτήματα σε σχέση με παλαιότερες κατανεμημένες τεχνολογίες Ευκολότερος χειρισµός δεδομένων Απλότητα πρωτοκόλλου επικοινωνίας Απλότητα υποδοµής Ευκολία στην επικοινωνία Διαλειτουργικότητα και ευκολία ανάπτυξης νέων εφαρμογών Τα.web services από την επιχειρηματική σκοπιά Τα web services από την τεχνική σκοπιά Εφαρμογές των web services 21 Κεφάλαιο Αρχιτεκτονική και δομικά στοιχεία των web services Μία αναλογία των web services Το μοντέλο των web services Διαφορές από προηγούμενες τεχνολογίες Βασικά βήματα για την ανάπτυξη εφαρμογών με web services 29 Κεφάλαιο ΧΜL Παράδειγμα αναπαράστασης δεδομένων µε ΧΜL Elements ή Στοιχεία Attributes ή Ιδιότητες 32 4

6 3.4 Κανόνες ονοµασίας Καλά διαμορφωμένα έγγραφα (well formed documents) DTD ΧΜL Schema Σύγκριση του ΧΜL Schema µε το DTD 36 Κεφάλαιο WSDL και UDDI Ορισµός και σκοπός της WSDL Τεχνική περιγραφή της WSDL Ορισμός και σκοπός του UDDI Υπηρεσίες του UDDI Η δομή δεδομένων tmodel Προγραμματιστική διεπαφή του UDDI Γενική περιγραφή 41 Κεφάλαιο SOAP Ορισμός και σκοπός του SOAP SOAP και άλλα πρωτόκολλα ανταλλαγής µηνυµάτων EDI Επικοινωνούντα αντικείμενα CORBA COM και DCOM Απόδοση του SOAP (CORBA DCOM) RMI XML RPC Τι προσφέρει το SOAP Δοµή ενός µηνύµατος SOAP 51 5

7 5.5 SOAP Envelope SOAP - «ειδικές» ιδιότητες ΧΜL (ΧΜL attributes) SOAP Header SOAP header block SOAP Body SOAP Body child Element SOAP Fault Στοιχείο SOAP Code Στοιχείο SOAP Value (με πατέρα το στοιχείο Code) Στοιχείο SOAP Subcode (µε πατέρα το στοιχείο Code) Στοιχείο SOAP Value (με πατέρα το στοιχείο Subcode) Στοιχείο SOAP Reason Στοιχείο SOAP Text Στοιχείο SOAP Node Στοιχείο SOAP Role Στοιχείο SOAP Detail SOAP Detail Entry Μοντέλα ανταλλαγής μηνυμάτων Απομακρυσμένες κλήσεις διαδικασιών (RPC) Συνομιλητικές ανταλλαγές µηνυµάτων Πλαίσιο Συνδέσεων Binding Framework ΗΤΤΡ Binding Σύνοψη για το SOAP 63 Κεφάλαιο Δημιουργία και υλοποίηση των Web Services Apache Axis 65 6

8 6.1.2 IBM web services Toolkit Microsoft SOAP Toolkit Οι Web Services στο περιβάλλον.νετ 66 Κεφάλαιο Αναπτυσσόμενες τεχνολογίες Web services και ασφάλεια Web services κοι μηνυμοτοδότηση (messaging) Web services και συναλλαγές (transactions) 71 Κεφάλαιο Συμπεράσματα-αποτίμηση των web services 73 Κεφάλαιο Παραδείγματα web services 74 Κεφάλαιο Ηλεκτρονική υγεία E-patients (ηλεκτρονικοί ασθενής) Τι χρησιμοποιείται σήμερα στην ιατρική Artemis-Ανάπτυξη σημασιολογικά εμπλουτισμένων web services την διαχείριση της υγείας Πρότυπες πληροφορίες υγείας και web services Λειτουργική οντολογία των web services Oντολογία μηνυμάτων των web services Χαρτογράφηση οντολογίας Αξιοποίηση σημασιολογικά σχολιασμένων web services Σημασιολογικός συνυπολογισμός των web services σε ιατρικές υπηρεσίες Semantic Aggregation Operators (SOA) Συσχετισμός οντολογιών web services με μητρώα web services 101 7

9 Αρχιτεκτονική Artemis Artemis - διαμεσολαβητής στην P2P αρχιτεκτονική Αrtemis στοιχεία διαμεσολαβητή Αποτίμηση Artemis - συμπεράσματα Πειραματική πιλοτική μελέτη σχετικά με την AC (Adaptive Collaboration ) και τις δυνατότητες στην Υγεία 107 Παράρτημα (Hospital) 113 Βιβλιογραφία 117 8

10 9

11 ΤΙΤΛΟΣ:ΔΙΑΔΙΚΤΥΑΚΕΣ ΥΠΗΡΕΣΙΕΣ ΚΑΙ ΕΦΑΡΜΟΓΕΣ ΓΙΑ ΕΠΕΞΕΡΓΑΣΙΑ ΚΑΙ ΑΠΕΙΚΟΝΙΣΗ ΙΑΤΡΙΚΩΝ ΔΕΔΟΜΕΝΩΝ Φοιτητής: Σαραντόπουλος Χαράλαμπος Επιβλέπων:κ. Κουκιάς Μιχαήλ ΠΕΡΙΛΗΨΗ Σκοπός αυτής της εργασίας είναι η αναφορά και ανάλυση των υπαρχουσών τεχνολογιών με τις οποίες είναι δυνατή η κατασκευή ενός web service. Η γλώσσα XML καθώς και οι WSDL, UDDI και SOAP είναι οι βασικές τεχνολογίες που χρησιμοποιούνται για την κατασκευή των web services και αναλύονται λεπτομερώς με παραδείγματα, για την πλήρη κατανόησή τους. Η εργασία αυτή πραγματεύεται επίσης την εφαρμογή των web services στον τομέα της υγείας. Πιο συγκεκριμένα, με μια ματιά παρουσιάζεται ο κλάδος της υγείας και πως δύναται να αλλάξει με την χρησιμοποίηση των web services. Τα δύο σημεία που επικεντρωνόμαστε είναι το σύστημα Artemis (σημασιολογικά εμπλουτισμένα web services στην διαχείρηση της υγείας) που παρουσιάζει με ρεαλιστικό τρόπο την σχέση των απαιτούμενων τεχνολογιών με την πρακτική αντιμετώπιση των προβλημάτων στο χώρο της υγείας. Το δεύτερο είναι μια πειραματική πιλοτική μελέτη με βάση την adaptive collaborative work και τις δυνατότητες στην διαχείρηση της υγείας. 10

12 ΕΙΣΑΓΩΓΗ Σήμερα το Internet αποτελεί για τις επιχειρήσεις στην Ελλάδα ένα μέσο προβολής και δημοσιοποίησης των δραστηριοτήτων τους. Τα τελευταία χρόνια όμως πολλές επιχειρήσεις παγκοσμίως άρχισαν να χρησιμοποιούν το Internet ως μέσο παροχής υπηρεσιών προς τους πελάτες τους αλλά και προς άλλες επιχειρήσεις. Με την εξέλιξη αυτή δημιουργήθηκε ένα σύνολο από θέματα που είχαν να κάνουν με την ευχρηστία, τη λειτουργικότητα και την απλότητα των παρεχόμενων υπηρεσιών. Και ενώ οι προσπάθειες που έγιναν για να δοθούν λύσεις ήταν πολλές, το αποτέλεσμα ήταν το ίδιο: υπήρχε ένα μεγάλο σύνολο από έτοιμες υπηρεσίες στο Internet αλλά η χρησιμοποίησή τους ήταν πάρα πολύ μικρή. Πρόσφατα όμως μία αρχιτεκτονική που ήδη έχει θεσπιστεί και από το world wide web consortium [ ], με το όνομα web service, ήρθε να δώσει λύση στα προβλήματα ευχρηστίας και λειτουργικότητας των ηλεκτρονικών υπηρεσιών. Μέσα από την αρχιτεκτονική των web services ορίζεται ένα σύνολο από προδιαγραφές και κανόνες με τους οποίους είναι δυνατή η δημιουργία και η παροχή ηλεκτρονικών υπηρεσιών μέσα στο Internet με αρκετά απλό τρόπο. Έτσι τα τελευταία χρόνια οι ηλεκτρονικές υπηρεσίες πήραν νέα διάσταση και πλέον κάθε επιχείρηση μπορεί σχετικά εύκολα να δημιουργεί και να παρέχει υπηρεσίες στο Internet αλλά μπορεί με ακόμα μεγαλύτερη ευκολία να χρησιμοποιεί έτοιμες υπηρεσίες. Η τεχνολογία των web services αφορά συνήθως στους προγραμματιστές εφαρμογών στο Internet και όχι στους απλούς χρήστες και χειριστές ηλεκτρονικών υπολογιστών. Όμως η γνώση της ύπαρξης της συγκεκριμένης τεχνολογίας και του γεγονότος ότι η ενσωμάτωσή της αποτελεί μία σχετικά εύκολη διαδικασία, θα πρέπει να περάσει σε κάθε δραστήριο επιχειρηματία στη χώρα μας. Με αυτό τον τρόπο οι επενδύσεις στην πληροφορική και στο Internet θα είναι πραγματικά αξιόλογες και ανταγωνιστικές τόσο για τα Ελληνικά όσο και για τα παγκόσμια δεδομένα. Η παρούσα διπλωματική εργασία, βοηθάει σε αυτό το σκοπό, δίνοντας βασικές πληροφορίες για την κατανόηση των web services (τι είναι τα web services και πως υλοποιούνται). Παραθέτονται αναλυτικά τα βήματα για την δημιουργία ενός web service, τα εργαλεία που χρησιμοποιούνται καθως και διάφορα παραδείγματα, έτσι ώστε κάποιος να μπορεί να σχηματίσει μια ολοκληρωμένη αποψη για την λειτουργεία και την χρησιμότητα των web services. Επίσης, το δεύτερο κομμάτι της διπλωματικής, αφορά σε εφαρμογές των web services πάνω στον κλάδο της υγείας. Δίνονται αναλυτικές πληροφορίες για τον τρόπο που επιδρούν τα web services στον 11

13 τομέα της υγείας και ουσιαστικά ανοίγει το δρόμο για μελλοντικές εκτενέστερες μελέτες πάνω σε αυτόν τον τομέα. Περιληπτική παρουσίαση των κεφαλαίων Η διπλωματική αυτή εργασία αποτελείται απο δέκα κεφάλαια και συνοπτικά μπορούμε να πούμε τα εξής : Κεφάλαιο 1: Στο κεφάλαιο αυτό δίνεται ο ορισμός του web service και παρουσιάζονται βασικές έννοιες σχετικών με το αντικείμενο. Κεφάλαιο 2 : Στο κεφάλαιο αυτό εισάγεται η αρχιτεκτονική των web services και αναφέρονται τα δομικά του στοιχεία. Κεφάλαιο 3 : Εδώ εξετάζεται και αναλύεται η γλώσσα XML. Κεφάλαιο 4 : Στο παρών κεφάλαιο δίνονται οι ορισμοί και αναλύονται οι τεχνολογίες WSDL και UDDI. Κεφάλαιο 5 : Στο κεφάλαιο αυτό ορίζεται το SOAP και γίνεται λεπτομερής καταγραφή των στοιχείων που το αποτελούν. Κεφάλαιο 6 : Στο κεφάλαιο αυτό φαίνεται ο τρόπος και η υλοποίηση των web services με την βοήθεια διαφόρων πλατφορμών που αναφέρονται. Κεφάλαιο 7 : Στο κεφάλαιο αυτό γίνεται λόγος για τις αναπτυσσόμενες τεχνολογίες αλλά θίγονται σημαντικά και ευαίσθητα θέματα όπως η ασφάλεια η μηνυματοδότηση και οι συνναλαγές. Κεφάλαιο 8 : Σε αυτό το κεφάλαιο φαίνεται μια συνολική αποτίμηση των web services και καταγράφονται χρήσιμα συμπεράσματα. Κεφάλαιο 9 : Στο κεφάλαιο αυτό δίνονται μερικά παραδείγματα για την καλύτερη κατανόηση των web services. Κεφάλαιο 10 : Στο κεφάλαιο αυτό δίνεται με μια ματιά η κατάσταση στο χώρο της υγείας και στην συνέχεια εξετάζεται το σύστημα Artemis καθώς και μια πειραματική πιλοτική μελέτη για τις επιδράσεις στον χώρο της υγείας. 12

14 1. Εισαγωγή στα web services 1.1 Τι είναι τα web services Υπάρχουν πολλοί ορισμοί για το τι είναι web services, περίπου όσοι και οι εταιρίες πληροφορικής που αναπτύσουν εργαλεία για τα web services. Ενας πολύ καλός ορισμός έρχεται απο τιν IBM : Τα web services είναι μία τεχνολογία που επιτρέπει στις εφαρμογές να επικοινωνούν μεταξύ τους ανεξαρτήτως πλατφόρμας και γλώσσας προγραμματισμού. Ενα web service είναι μία διεπαφή λογισμικού (software interface) που περιγράφει μια συλλογή από λειτουργίες οι οποίες μπορούν να προσεγγιστούν από το δίκτυο μέσω πρότυπων μηνυμάτων XML.Χρησιμοποιεί πρότυπα βασισμένα στη γλώσσα XML για να περιγράψει μία λειτουργία (operation) προς εκτέλεση και τα δεδομένα προς ανταλλαγή με κάποια άλλη εφαρμογή.μία ομάδα απο web services οι οποίες αλληλεπιδρούν μεταξύ τους καθορίζει μία εφαρμογή web services. Η Microsoft μέσα απο το ΜSDN της καταλήγει οτι όλα τα web services έχουν τρια κοινά χαρακτηριστικά : Τα web services εκθέτουν χρήσιμη λειτουργικότητα σε χρήστες του διαδικτύου μέσα από ένα πρότυπο δικτυκό πρωτοκολο. Στις περισσότερες περιπτώσεις αυτό το πρωτόκολλο είναι το SOAP (Simple Object Access Protocol). Τα web services παρέχουν ένα τρόπο να περιγράψουν τις διεπαφές τους με αρκετή λεπτομέρεια ώστε να επιτρέψουν στον χρήστη τους να χτίσει μία εφαρμογή πελάτη η οποία να επικοινωνεί μαζί τους.η περιγραφή συνήθως παρέχεται σε ένα έγγραφο XML το οποίο ονομάζεται έγγραφο WSDL (Web Services Description Language) Τα web services καταχωρούνται ώστε οι δυνητικοί χρήστες να μπορούν να τα βρουν εύκολα. Αυτο γίνεται με το UDDI (Universal Discovery Description and Integration) Τα web services λοιπόν αποτελούν μία αρχιτεκτονική κατανεμημένων συστημάτων κατασκευασμένη από πολλά διαφορετικά υπολογιστικά συστήματα τα οποία επικοινωνούν μέσω του δικτύου ώστε να δημιουργήσουν ένα σύστημα. Αποτελούνται από ένα σύνολο απο πρότυπα τα οποία επιτρέπουν στους υπεύθυνους για την ανάπτυξη (προγραμματιστές-developers) να υλοποιήσουν κατανεμημένες εφαρμογές χρησιμοποιώντας διαφορετικά εργαλεία από διαφορετικούς προμηθευτές ώστε να κατασκευάσουν εφαρμογές που χρησιμοποιούν ένα συνδυασμό από ενότητες 13

15 λογισμικού (software modules) οι οποίες καλούνται από συστήματα που ανήκουν σε διαφορετικά τμήματα ενός οργανισμού ή σε διαφορετικούς οργανισμούς. Σε αυτό το σημείο μπορούμε να δώσουμε έναν πλήρη ορισμό για το web service. Το web service είναι μία ανεξάρτητη πλατφόρμα, χαλαρά συνδεδεμένη, αυτοτελώς προγραμματίσιμη και ενεργοποιημένη στο δίκτυο εφαρμογή, που μπορεί να περιγραφεί, να εκδοθεί, να ανακαλυφθεί, να συντονιστεί και να ρυθμιστεί χρησιμοποιώντας XML-εργαλεια με σκοπό την ανάπτυξη διαδεδομένων διαλειτουργικών εφαρμογών. Τα web services κατέχουν την δυνατότητα να χρησιμοποιούν άλλες υπηρεσίες με σκοπό να: Ολοκληρώσουν ένα καθήκον Διεξάγουν επιχειρηματικές συναλλαγές Λύσουν ένα σύνθετο πρόβλημα Εκθέσουν τα προγραμματισμένα χαρακτηριστικά τους στο internet ή (intranet)χρησιμοποιώντας πρότυπες γλώσσες του internet και προτωκολλα οπως το XML Υλοποιηθεί μέσω μιας αυτοπεριγραφόμενης επιφάνειας που βασίζεται σε ανοιχτα πρότυπα στο internet. Υπάρχουν δυο βασικά χαρακτηριστικά των web services, που χρειάζονται περισσότερη ανάλυση. Αυτά είναι: χαλαρή συνδεσιμότητα και σημασιολογική ενθυλάκωση διακριτής λειτουργείας. Τα web services αλληλεπιδρουν δυναμικά μεταξύ τους και χρησιμοποιούν τις πρότυπες τεχνολογίες του internet, καθιστώντας το έτσι δυνατο να συνδεθούν συστήματα, που αλλιως θα χρειαζόταν εκτενής προσπάθειες ανάπτυξης. Παραδοσιακά σχεδιασμένη εφαρμογή βασίζεται σε μία στενή διασύνδεση όλων των θυγατρικών στοιχείων, που συχνα χρησιμοποιούνται στην ίδια διαδικασία. Η πολυπλοκότητα αυτών των συνδέσεων απαιτούν από τους προγραμματιστές να να έχουν πληρη γνώση και τον έλεγχο στις δυο πλευρές (άκρα) της σύνδεσης. Επιπέον εφόσον έχει διακπεραιωθεί η σύνδεση, είναι εξαιρετικά δύσκολο να αφαιρεθεί ένα στοιχείο και να αντικατασταθεί με άλλο. Σε αντίθεση με την αρχή της στενής συνδεσιμότητας που απαιτεί συμφωνία και κοινόχρηστο πλαίσιο μεταξύ των επικοινωνούντων συστημάτων, η χαλαρή συνδεσιμότητα απαιτεί χαμηλότερο επίπεδο συντονισμού και επιτρέπει ευέλικτη επαναδιαμόρφωση. Ενα web service είναι μία αυτοτελή ενότητα λογισμικού που διαικπεραιώνει ένα απλο καθήκον. Η ενότητα χαρακτηρίζει τα δικά του χαρακτηριστικά επιφάνειας (διαθέσιμες λειτουργείες, παράμετρους) με τρόπο τέτοιον, ώστε άλλες ενότητες λογισμικού να προσδιορίσουν το σκοπό της, πως να επικαλεστεί την λειτουργικότητά της και τι αποτέλεσμα να περιμένει. Με αυτή τη σκοπιά τα web services είναι συμβατικές ενότητες λογισμικού αφού παρέχουν δημοσίως περιγραφές των 14

16 χαρακτηριστικών των διεπιφανειών που χρησιμοποιούνται για να έχουν προσβαση στην υπηρεσία, ώστε πιθανοί πελάτες να εχουν προσβαση. Η εξυπηρέτηση πελατών χρησιμοποιεί την περιγραφη μιας επιφάνειας web service για να συνδεθεί με τον παροχέα της υπηρεσίας και να επικαλεστεί τις υπηρεσίες της. Οι υπηρεσίες περιγράφονται από την άποψη της περιγραφικής γλώσσας πχ WSDL που παρέχει λειτουργικά και μη-λειτουργικά χαρακτηριστικά. Λειτουργικά χαρακτηριστικά περιέχουν χρακτηριστικά επιχειρήσεων που καθορίζουν την συνολική συμπεριφορά των web services, ενώ τα μη-λέιτουργικά χαρακτηριστικά περιέχουν την διαθεσιμότητα των υπηρεσιών, την αξιοπιστία, την επεκτασιμότητα, την ασφάλεια, την εξουσιοδότηση, την γνησιότητα, την ακαιρεότητα, χαρακτηριστικά επίδοσης (ταχυτητα,ακρίβεια) και πληροφορίες επικαιρότητας. 1.2 Ποιότητα παρεχόμενων υπηρεσιών (quality of service QoS) Για να λειτουργεί ένα web service κανονικά πρέπει να περιέχει περιγραφή και των επιχειρησιακών χαρακτηριστικών, που καθορίζουν την συνολική του συμπεριφορά, και την περιγραφή των μη-λειτουργικών χαρακτηριστικών. Τα μη-λειτουργικά χαρακτηριστικά μιας υπηρεσίας επικεντρώνονται κατά κύριο λόγο στην περιγραφή του περιβάλοντος που φιλοξενεί το web service. Κάθε υπηρεσία φιλοξενίας περιβάλλοντος μπορεί να προσφέρει μια ποικιλία από ποιότητα παρεχόμενων υπηρεσιών βασισμένες σε τεχνικές προδιαγραφές όσον αφορά τις απαιτήσεις σε διάφορα επίπεδα επί εικοσατετραώρου βάσεως της διαθεσιμότητας της υπηρεσίας, επίδοσης και επεκτασιμότητας, ασφάλειας και πολιτικές προστασίας κλπ καθε μία απο τις οποίες πρέπει να περιγραφεί. Είναι πλέον φανερό οτι η ποιότητα των παρεχόμενων υπηρεσιών ενός web service γίνεται η υπαριθμόν ένα προτεραιότητα για τους παροχείς υπηρεσιών και τους πελάτες τους. Βελτίωση στις υποδομές δυκτύων και στήριξης σε συνδυασμό με τις αυξανόμενες προσδοκίες εσωτερικών επιδόσεων, έχουν οδηγήσει τις επιχειρήσεις να ισορροπήσουν το οικονομικό όφελος με το παρεχόμενο βαθμό ποιότητας της υπηρεσίας. Στο πλαίσιο των web services ο βαθμός εξυπηρέτησης μπορεί να θεωρηθεί ως παροχή διασφάλισης σε ένα σύνολο ποσοτικών χαρακτηριστικών. Αυτά μπορεί να θεωρηθούν στην βάση των σημαντικών λειτουργικών και μη-λειτουργικών ιδιοτήτων στην παρεχόμενη ποιότητα των υπηρεσιών που περιέχουν εφαρμογή και ανάπτυξη θεμάτων όπως και σημαντικά χαρακτηριστικά υπηρεσιών μέτρησης υπηρεσιών και κοστολογίου, μετρήσεις επίδοσης (χρόνος απόκρισης), απαιτήσεις ασφάλειας, ακεραιότητας, αξιοπιστίας, επεκτασιμότητας και διαθεσιμότητας. Αυτά τα χαρακτηριστικά είναι αναγκαίες προυποθέσεις για να καταλάβει κανείς την συνολική 15

17 συμπεριφορά μιας υπηρεσίας, ώστε αλλες εφαρμογές και υπηρεσίεςνα συνδεθουν σε αυτό και να το εκτελέσουν σαν μέρος επιχειρηματικής διαδικασίας. Υπάρχουν πολλές περιπτώσεις όπου τα web services απαιτούν αμοιβαίες συναλλαγές και πλαίσιο πολλαπλασιασμού. Το γεγονός οτι ένα συγκεκριμένο web service απαιτεί συναλλακτική συμπεριφορά περιγράφεται από το συνοδευτικό επίπεδο σύμβασης παροχής υπηρεσιών και οι παροχείς υπηρεσιών πρέπει να διατηρήσουν αυτή την ιδιότητα. Όσο οι οργανώσεις βασίζονται σε επιχειρηματικές μονάδες, συνεταίρους και εξωτερικούς παροχείς υπηρεσιών να τους προμηθεύουν με υπηρεσίες βασίζονται στη χρήση του επιπέδου σύμβασης παροχής υπηρεσιών για να διασφαλίσουν οτι ο επιλεγμένος παροχέας υπηρεσιών παραδίδει ένα εγγυημένο επίπεδο παροχής υπηρεσιών. Το επίπεδο σύμβασης παροχής υπηρεσιών είναι μία τυπική συμφωνία μεταξύ ενός προμηθευτή και ενός πελάτη επισημοποιώντας τις λεπτομέρειες ενός web service (περιεχόμενα,τιμή διαδικασία πράδοσης,κριτήρια ποιότητας και αποδοχής,ποινες κλπ) με τέτοιο τρόπο ώστε να πληρούνται οι αμοιβαίες συμφωνίες και προσδοκίες και του παροχέα υπηρεσιών και του δέκτη των υπηρεσιών. Τόσο οι παροχείς υπηρεσιών όσο και οι πελάτες χρειάζεται να χρησιμοποιούν SLAs για να συνεργάζονται καλά μεταξύ τους. Επιπλέον ένα SLA εάιναι σημαντικό και ευρέως χρησιμοποιούμενο όργανο για την διατήρηση των σχέσεων παροχής υπηρεσιών. Οι μετρήσεις που επιβάλλονται από τα SLAs πρέπει να συσχετίζονται με τους συνολικούς σκοπούς των υπηρεσιών που παρέχονται. Επιπλέον μία σημαντική που καταφέρνει ένα SLA είναι να αντιμετωπίζει την ποιότητα παροχλης υπηρεσιών στην πηγή. Για την αντιμετώπιση τέτοιων προβλημάτων η αναπτυσόμενη ακολουθία προτύπων των web services υποστηρίζει μια πρότυπη αρχή πλαισίου που καθιστά δυνατό στου προγραμματιστές να να εκφράσουν τις αρχές των υπηρεσιών και στα web services να καταλάβουν τις αρχές και να τις ενσωματώσουν σε τρέχοντα χρόνο. 1.3 Πλεονεκτήµατα σε σχέση με παλαιότερες κατανεµηµένες τεχνολογίες Μία εύλογη ερώτηση είναι τι διαφορετικό έχει να προσφέρει αυτή η τεχνολογία σε σχέση με προηγούμενες κατανεμημένες τεχνολογίες Ευκολότερος χειρισµός δεδομένων 16

18 Παραδοσιακά το κυριότερο πρόβλημα στις κατανεμημένες τεχνολογίες ήταν το λεγόμενο tight-couρling ή στα ελληνικά η ισχυρή συνδεδιμότητα. Μια εφαρμογή που καλούσε μια άλλη απομακρυσμένη ήταν αυστηρά δεμένη με αυτή από την κλήση λειτουργίας (function call) που εκτελούσε και τις παραμέτρους που περνούσε. Στα περισσότερα συστήματα πριν από την έλευση των web services ο τρόπος επικοινωνίας ήταν μία σταθερή διεπαφή με λίγη ως καθόλου ευελιξία ή προσαρμοστικότητα στα περιβάλλοντα ή τις ανάγκες που μεταβάλλονται συνεχώς. Τα web services χρησιμοποιούν τη γλώσσα ΧΜL η οποία μπορεί να περιγράψει οποιαδήποτε δεδομένα σε ένα πραγματικά ανεξάρτητο από πλατφόρμα τρόπο για ανταλλαγή αυτών των δεδομένων μεταξύ συστημάτων. Με αυτόν τον τρόπο οδηγούμαστε σε εφαρμογές με χαλαρή σuνδεσιμότψα (loosely- couρled). Επιπλέον τα web services μπορούν να λειτουργήσουν σε πιο αφηρημένο επίπεδο στο οποίο μπορούν να επαναξιολογήσουν, να τροποποιήσουν ή να χειριστούν τύπους δεδομένων δυναμικά κατά περίπτωση. Έτσι σε τεχνικό επίπεδο τα web services μπορούν να χειριστούν δεδομένα πολύ ευκολότερα και να επιτρέψουν στο λογισμικό να επικοινωνεί πιο ελεύθερα Απλότητα πρωτοκόλλου επικοινωνίας Τα web services χρησιμοποιούν ως πρωτόκολλο επικοινωνίας το SOAP. Το πρωτόκολλο αυτό είναι πολύ πιο απλό από πρωτόκολλα παλαιότερων τεχνολογιών όπως αυτά που χρησιμοποούνταν από τα κατανεμημένα περιβάλλοντα CORBA, DCOM, RPC. Έτσι το να δημιουργήσει κανείς μια υλοποίηση SOAP που υπόκειται στα πρότυπα (standards-comρliant) είναι πολύ πιο εύκολο. Σήμερα μπορεί να βρει κανείς υλοποιήσεις του SOAP από τις μεγαλύτερες εταιρίες πληροφορικής αλλά ακόμη και από μεμονομένους προγραμματιστές, πράγμα αδιανόητο για παλαιότερες κατανεμημένες τεxνoλoγίες Απλότητα υποδοµής Τα web services λειτουργούν με πρότυπες γλώσσες και πρωτόκολλα όπως η ΧΜL, το ΗTTΡ και το TCP/IP. Η πλειονότητα των εταιριών έχουν ήδη την δικτυακή υποδομή και τους ανθρώπους με γνώσεις και εμπειρία που τη συvτηρoύν. Έτσι το κόστος για την εφαρµογή των web serνices είναι σημαντικά µικρότερο από αυτό των προηγούµενων τεχνολογιών. 17

19 1.3.4 Ευκολία στην επικοινωνία Με τις προηγούµενες τεχνολογίες η συνεργασία µεταξύ εταιριών ήταν ένα θέµα διότι κατανεµηµένες τεχνολογίες όπως CORBA και DCOM χρησιµοποιούσαν µη πρότυπες πόρτες. Σαν αποτέλεσµα η συνεργασία σήµαινε άνοιγµα «οπών» στα τείχη προστασίας (fιrewalls) κάτι που πολλές φορές δεν ήταν αποδεκτό από τους ανθρώπους της πληροφορικής σε µια εταιρία αφού έθετε σε κίνδυνο στην ασφάλεια των συστηµάτων. Το γεγονός αυτό δεν επέτρεπε δυναµική συνεργασία λόγω του ότι απαιτούσε µια χειροκίνητη διαδικασία για τη συνεργασία µιας εταιρίας µε τους συνεργάτες της. Τα web services µπορούν να χρησιµοποιήσουν (µεταξύ άλλων) το ΗTTΡ ως πρωτόκολλο µεταφοράς και τα περισσότερα τείχη προστασίας επιτρέπουν την πρόσβαση µέσω της θύρας 80 (πρότυπη θύρα για το ΗTTΡ). Με αυτόν τον τρόπο οδηγούµαστε σε ευκολότερες και δυναµικές συνεργασίες µεταξύ των συστηµάτων των εταιριών Διαλειτουργικότητα και ευκολία ανάπτυξης νέων εφαρµογών Οι προηγούµενες κατανεµηµένες τεχνολογίες υπέφεραν από ζητήµατα διαλειτουργικότητας διότι κάθε προµηθευτής (vendor) υλοποιούσε το δικό του πρότυπο για distributed object messaging. Με την ΧΜL σαν το µόνο πρότυπο στα web serνices, συστήµατα φτιαγµένα από διαφορετικές τεχνολογίες όπως η Java και το.net µπορούν να επικοινωνήσουν µεταξύ τους. Επιπλέον λόγω της απλότητας της ΧΜL είναι πολύ πιο εύκολο να γραφτούν νέες εφαρµογές σε µικρό χρονικό διάστηµα. 1.4 Τα.web services από την επιχειρηµατική σκοπιά Σε ένα υψηλότερο εννοιολογικό επίπεδο, µπορούµε να δούµε τα web serνices σαν µονάδες εργασίας (units of work). Ένα βήµα παραπέρα, αυτές οι µονάδες µπορούν να συνδυαστούν σε εργασίες επιχειρησιακού προσανατολισµού για να χειριστούν συγκεκριµένες επιχειρησιακές λειτουργίες. Αυτό µε τη σειρά του επιτρέπει σε µη τεχνικούς ανθρώπους να σχεδιάσουν εφαρµογές οι οποίες µπορούν να χειριστούν τα επιχειρησιακά ζητήµατα συνδυόζοντας τα web serνices σε ροές εργασίας. Σε µία αναλογία από τον χώρο των αυτοκινήτων, ο αρχιτέκτονας των επιχειρησιακών 18

20 διαδικασιών µπορεί να συνδυάσει ολόκληρο τον κινητήρα µε το πλαίσιο, τη µετάδοση και τα υπόλοιπα υποσυστήµατα παρά να ασχοληθεί µε τα εσωτερικά κοµµάτια του κινητήρα. Επιπλέον η δυναµική πλατφόρµα σηµαίνει ότι ο κινητήρας µπορεί να συνεργαστεί µε τη µετάδοση ή άλλα υποσυστήµατα διαφορετικών κατασκευαστών. Αυτό που προκύπτει από αυτή την πτυχή είναι ότι τα web services βοηθούν στη γεφύρωση του κενού που υπάρχει ανάµεσα στους ανθρώπους του επιχειρείν και τους ανθρώπους της πληροφορικής σε ένα οργανισµό. Οι άνθρωποι του επιχειρείν µπορούν να περιγράψουν γεγονότα και δραστηριότητες και οι τεχνικοί µπορούν να τα συνδέσουν µε τις κατάλληλες υπηρεσίες. Με καθολικά καθορισµένες διεπαφές και καλά σχεδιασµένες λειτουργίες, γίνεται επίσης εύκολο να επαναχρησιµοποιηθούν αυτές οι λειτουργίες όρα και οι εφαρµογές που αντιπροσωπεύουν. Η επαναχρησιµοποιήση µιας εφαρµογής λογισµικού σηµαίνει καλύτερη απόδοση της επένδυσης (return οπ investment).διότι µπορεί να παράγει περισσότερα µε τους ίδιους πόρους. Επιτρέπει στους ανθρώπους να εξετάσουν το ενδεχόµενο χρησιµοποίησης µιας ήδη υπάρχουσας εφαρµογής µε ένα διαφορετικό τρόπο ή το ενδεχόµενο προσφοράς αυτής σε ένα συνεργάτη µε διαφορετικό τρόπο, αυξάνοντας ενδεχοµένως τις επιχειρησιακές συναλλαγές µεταξύ των συνεργατών. Εποµένως, τα κύρια ζητήµατα που τα web services προσπαθούν να λύσουν είναι τα ζητήµατα ολοκλήρωσης (integration) δεδοµένων και εφαρµογών και αυτό της µεταµόρφωσης των τεχνικών λειτουργιών σε υπολογιστικές λειτουργίες επιχειρησιακού προσανατολισμού. 1.5 Τα web services από την τεχνική σκοπιά Ενώ τα web services προσφέρουν όλα αυτά τα δυναµικά χαρακτηριστικά ώστε να συνδυάσουµε υπηρεσίες σε εφαρµογές, πρέπει πρώτα να χτίσουµε αυτές τις υπηρεσίες. Οι γλώσσες προγραµατισµού στην πληροφορική συνεχώς εξελίσονται. Ξεκινήσαµε δεκαετίες πριν µε την ιδέα της function στην οποία παρέχουµε µερικές παραµέτρους,εκτελεί µια λειτουργία µε αυτές τις παραµέτρους, και επιστρέφει µια τιµή βασισµένη στους υπολογισµούς που έγιναν. Τελικά, αυτή η πρώτη έννοια εξελίχθηκε σε αντικείµενο (object) όπου κάθε αντικείµενο είχε, όχι απλώς έναν αριθµό από λειτουργίες (functions) που µπορεί να εκτελέσει αλλά και τις δικές του ιδιωτικές µεταβλητές (private data variables), αντι να στηρίζεται σε εξωτερικές µεταβλητές του συστήµατος που προηγουµένως έκαναν πιο περίπλοκη την ανάπτυξη εφαρµογών. Δεδοµένου ότι οι εφαρµογές άρχισαν να επικοινωνούν µεταξύ τους, η έννοια του καθορισµού καθολικών διεπαφών (universal interfaces) για αντικείµενα έγινε σηµαντική, επιτρέποντας αντικείµενα σε διαφορετικές πλατφόρµες να 19

21 επικοινωνούν ακόµη και αν είχαν αναπτυχθεί σε διαφορετικές γλώσσες προγραµµατισµού και εκτελούνταν σε διαφορετικά λειτουργικά συστήµατα. Στο πιο πρόσφατο βήµα, τα web services προχώρησαν µπροστά µε την έννοια των διεπαφών και επικοινωνιών καθορισµένων µε ΧΜL, ενώνοντας τελικά κάθε είδους εφαρµογή µε οποιαδήποτε άλλη, όπως και παρέχοντας την ελευθερία στις εφαρµογές αν αλλάξουν και να εξελιχθούν µε το χρόνο, αρκεί να είναι σχεδιασµένες σύµφωνα µε την κατάλληλη διεπαφή. Η µεταβλητότητα της ΧΜL είναι αυτό που κάνει τα web services διαφορετικά από τεχνολογίες προηγούµενων γενεών. Επιτρέπει το διαχωρισµό της γραµµατικής δοµής (syntax) και της γραµµατικής έννοιας (semantics), και του πώς αυτά υποβάλλονται σε επεξεργασία και κατανοούνται από µία υπηρεσία και το περιβάλλον µέσα στο οποίο υπάρχει. Έτσι λοιπόν τώρα, τα αντικείµενα µπορούν να καθοριστούν σαν υπηρεσίες, οι οποίες επικοινωνούν µε άλλες υπηρεσίες σε γραµµατική καθορισµένη σε ΧΜL, µε την οποία κάθε υπηρεσία µεταφράζει και αναλύει το µήνυµα σύµφωνα µε µην τοπική της υλοποίησης και το περιβάλλον της. Κατά συνέπεια µια διακτυακή εφαρµογή µπορεί πραγµατικά να συντεθεί από πολλαπλές οντότητες διαφόρων υλοποιήσεων και σχεδιασµών εφόσον προσαρµόζονται στους κανόνες που καθορίζονται από την προσανατολισµένη στις υπηρεσίες αρχιτεκτονική τους. Κατά συνέπεια, µε αυτά στο μυαλό, τα web services μας επιτρέπουν: Την αλληλεπίδραση µεταξύ υπηρεσιών σε οποιαδήποτε πλατφόρµα, γραµµένες σε οποιαδήποτε γλωσσα προγραµµατισµού. Να αντιληφθούµε λειτουργίες εφαρµογών ως εργασίες, οδηγούµενοι σε ανάπτυξη και ροές εργασιών προσανατολισμένες σε εργασίες. Αυτό επιτρέπει µια υψηλότερη αφαίρεση του λογισµικού το οποίο µπορεί να υιοθετηθεί από λιγότερο τεχνικά καταρτισµένους χρήστες. Τη χαλαρή συνδεσιµότητα µεταξύ εφαρµογών, πράγµα που σηµαίνει ότι αλληλεπιδράσεις µεταξύ υπηρεσιών δε θα χαλάνε κάθε φορά που υπάρχει κάποια αλλαγή το πώς µία ή περισσότερες υπηρεσίες σχεδιάζονται ή υλοποιούνται. Την προσαρµογή ήδη υπαρχουσών εφαρµογών στις μεταβαλλόμενες επιχειρησιακές συνθήκες και ανάγκες των πελατών. Να παρέχουµε υπάρχουσες εφαρµογές λογισµικού µε διεπαφές υπηρεσιών χωρίς να αλλάξουµε τις αρχικές εφαρµογές, επιτρέποντάς τους να λειτουργούν πλήρως στο περιβάλλον των υπηρεσιών. Να εισάγουµε άλλες διοικητικές λειτουργίες ή λειτουργίες διαχείρισης διαδικασιών όπως η αξιοπιστία, υπευθυνότητα, ασφάλεια, κ.λ.π., ανεξάρτητες της αρχικής λειτουργίας µιας εφαροµογής, αυξάνοντας κατά συνέπεια τη µεταβλητότητα και τη χρησιµότητά της στο επιχειρησιακό περιβάλλον. 20

22 1.6 Εφαρμογές των web services Τα πρώτα web services σκόπευαν να είναι πηγές πληροφορίας τις οποίες µπορεί κανείς πολύ εύκολα να ενσωµατώσει στις εφαρµογές του όπως: τιµές µετοχών, προβλέψεις καιρού, αποτελέσµατα αθλητικών παινιδιών κ.λπ. Έιναι εύκολο να φανταστεί κανείς µια ολόκληρη κατηγορία εφαρµογών που µπορεί να κατασκευάσει ώστε να αναλύει και να συνδυάζει πληροφορία που τον ενδιαφέρει και να την παρουσιάζει µε ποικίλους τρόπους. Για παράδειγµα, θα µπορούσαµε να έχουµε ένα λογιστικό φύλλο (spreadsheet) το οποίο συνοψίζει όλη την οικονοµική µας εικόνα : µετοχές, τραπεζικούς λογαριασµούς, δάνεια κλπ. Αν αυτή η πληροφορία ήταν διαθέσιµη µέσω web services το λογιστικό φύλλο θα µπορούσε να ενηµερώνεται συνεχώς. Οι περισσότερες από αυτές τις πληροφορίες είναι ήδη διαθέσιµες στον παγκόσµιο ιστό αλλά τα web services θα κάνουν την προγραµµατιστική πρόσβαση σε αυτές πιο εύκολη και πιο αξιόπιστη. Εκθέτοντας ήδη υπάρχουσες εφαρµογές ως web services, θα επιτρέψει στους χρήστες να κατασκευάσουν νέες πιο ισχυρές εφαρµογές οι οποίες χρησιµοποιούν τα web services σαν δοµικά στοιχεία. Για παράδειγµα, ένας χρήστης θα µπορούσε να αναπτύξει µια εφαρµογή προµηθειών η οποία να παίρνει αυτόµατα τιµές από προµηθευτές, να επιτρέπει στο. χρήστη να επιλέξει προµηθευτή, να υποβάλει την παραγγελία και να παρακολουθεί την αποστολή έως ότου να γίνει η παραλαβή της. Η εφαρµογή του προµηθευτή, εκτός από το να εκθέτει τις υπηρεσίες της στον ιστό, θα µπορούσε να χρησιµοποιήσει άλλα web services για να ελέγξει την πιστοληπτική ικανότητα του πελάτη, να χρεώσει τον τραπεζικό λογαριασµό του πελάτη και να καθορίσει την αποστολή µε µια εταιρία µετοφορών. Στο άµεσο µέλλον, µερικά από τα πιο ενδιαφέροντα web services θα υποστηρίζουν εφαρµογές που χρησιµοποιούν τον ιστό για να κάνουν πράγµατα που δεν µπορούν να γίνουν σήµερα. Για παράδειγµα, µία από τις υπηρεσίες που τα web services θα κάνουν δυνατή είναι η υπηρεσία ηµερολογίου. Αν ο οδοντίατρος ή ο µηχανικός σας εξέθεταν τα ηµερολόγιά τους µέσω µιας τέτοιας web service, θα µπορούσατε να προγραµµατίσετε τα ραντεβού σας µε αυτούς ή θα µπορούσαν να προγραµµατίσουν αυτοί τα ραντεβού κατευθείαν στο δικό σας ηµερολόγιο άν θέλατε. Με λίγη φαντασία, µπορούµε να οραµατιστούµε εκατοντάδες εφαρµογές οι οποίες µπορούν να κατασκευαστούν µόλις έχουµε τη δυνατότητα να προγραµµατίσουµε τον ιστό. 21

23 2.Αρχιτεκτονική και δομικά στοιχεία των web services Για να καταλάβουμε τις τεχνολογίες που απαιτούνται για τα web. Services, πρέπει πρώτα να καταλάβουμε μία τυπική αλληλεπίδραση των web services. 2.1 Μία αναλογία των web services Ας εξετάσουμε ένα σενάριο στο οποίο χρειάζεται να εντοπίσουμε ένα συγκεκριμένο φαρμακείο στην περιοχή μας το οποίο έχει και ιστοσελίδα στο διαδίκτυο. Δεν θα βγαίναμε στο δρόμο και θα ρωτούσαμε κάθε άτομο που θα συναντούσαμε για την ταχυδρομική διεύθυνση του φαρμακείου. Αντί για αυτό θα μπορούσαμε να αναφερθούμε στην ιστοσελίδα του φαρμακείου στο διαδίκτυο. Αν γνωρίζαμε την ηλεκτρονική διεύθυνση της ιστοσελίδας θα πλοηγούμασταν κατευθείαν σε αυτή και θα βρίσκαμε την ταχυδρομική διεύθυνση για την οποία ενδιαφερόμαστε. Αν δεν γνωρίζαμε την ηλεκτρονική διεύθυνση του φαρμακείου θα πλοηγούμασταν σε μια μηχανή αναζήτησης και θα πληκτρολογούσαμε το όνομα του φαρμακείου στη γλώσσα την οποία η μηχανή αναζήτησης αναγνωρίζει. Αφού βρίσκαμε την ιστοσελίδα, θα πλοηγούμασταν σε αυτήν και στη συνέχεια θα βρίσκαμε την ταχυδρομική διεύθυνση. Η δομή των web services είναι παραπλήσια. Αν κοιτάξουμε προσεκτικά το προηγούμενο παράδειγμα θα δούμε ότι υπάρχει ένας αιτούντας ή καταναλωτής, εμείς.υπάρχει επίσης μία υπηρεσία: το φαρμακείο. Η κεντρική βάση δεδομένων είναι το διαδίκτυο, μέσω της οποίας θα βρούμε την τοποθεσία του φαρμακείου. Στο παράδειγμα, όταν εκτελούμε μία αναζήτηση στη μηχανή αναζήτησης, η αίτησή μας τυλίγεται σε μία δομή, της οποίας η γλώσσα είναι προκαθορισμένη και τοπική, και τότε περνιέται στον εξυπηρετητή της μηχανής αναζήτησης. Στα web services το SOAP, UDDI και WSDL αντιπροσωπεύουν τους ρόλους που αναφέρθηκαν στα παραπάνω βήματα. Το SOAP (Simple Object Access Protocol) είναι η μέθοδος με την οποία μπορούμε να στέλνουμε μηνύματα σε διαφορετικές ενότητες λογισμικού (software modules). Είναι παρόμοιο με το πώς επικοινωνούμε με τη μηχανή αναζήτησης. 22

24 Το UDDI (Universal Description, Discovery and Integration) είναι η καθολική βάση αναζήτησης για τον εντοπισμό των υπηρεσιών. Στο προηγούμενο παράδειγμα, είναι ανάλογη της υπηρεσίας ευρετηρίου της μηχανής αναζήτησης,στην οποία όλες οι ιστοσελίδες καταχωρούνται και σχετίζονται με λέξεις κλειδιά. Διατηρεί ένα κατάλογο με όλα τα φαρμακεία της χώρας. Η WSDL (Web Services Definition Language) είναι ο τρόπος με τον οποίο διαφορετικές υπηρεσίες περιγράφονται στο UDDI. Αυτή αντιστοιχεί στην πραγματική μηχανή αναζήτησης. 2.2 Το μοντέλο των web services Κλειδί για την χρησιμοποίηση των web services στην στήριξη και ανάπτυξη των γρήγορων,χαμηλού κόστους και ευκολοσύνθετων στη διανομή εφαρμογών είναι η αρχιτεκτονική προσανατολισμένη στις υπηρεσίες (SOA). H SOA είναι ένας λογικός τρόπος για τον σχεδιασμό ενός λογισμικού συστήματος για την παροχή υπηρεσιών και σε τελικούς χρήστες και σε άλλες εφαρμογές που διανέμονται σε ένα δίκτυο μέσω δημοσιευμένων διεπαφών (interfaces). Η SOA δημιουργεί στο διαδίκτυο 23

25 προδιαγραφές αναφοράς των SOAP, WSDL, και UDDI. Τα δομικά στοιχεία της αρχιτεκτονικής των web services καθορίζονται με βάση το ρόλο των πάροχων υπηρεσιών, των μητρώων υπηρεσιών και των πελατών των υπηρεσιών. Tο βασικό SOA ορίζει μια αλληλεπίδραση μεταξύ πρακτόρων λογισμικού ως μια ανταλλαγή μηνυμάτων μεταξύ παρόχων υπηρεσιών και αιτούντων υπηρεσιών (clients - πελάτες). Οι πελάτες ως συνήθως ζητούν την εκτέλεση μιας υπηρεσίας ενώ οι πάροχοι είναι οι πράκτορες λογισμικού που παρέχουν την υπηρεσία και είναι υπεύθυνοι για γτην δημοσίευση των υπηρεσιών που παρέχουν. Από αρχιτεκτονικής σκοπιάς, ο πάροχος είναι η πλατφόρμα που φιλοξενεί και ελέγχει την είσοδο στην υπηρεσία. Ο πάροχος των web services είναι υπεύθυνος για την δημοσίευση των web services που παρέχει σε ένα μητρώο υπηρεσίας που φιλοξενείται από έναν μεσίτη υπηρεσιών. Αυτό περιλαμβάνει την περιγραφή της επιχείρησης υπηρεσίας και τεχνικών πληροφοριών των web services και κατοχύρωση αυτής της πληροφορίας με το μητρώο των web services με τη μορφή που έχει ορισθεί από την υπηρεσία ιστού (discovery agency). Ο αιτών για web service ψάχνει το μητρώο υπηρεσιών για το επιθυμητό web service. Αυτό πρακτικά σημαίνει ανακάλυψη της περιγραφής των web services απο μητρώο που παρέχεται από έναν discovery agency και χρησιμοποίηση αυτής της υπηρεσίας για σύνδεση στην υπηρεσία. Οι πράκτορες μπορεί να είναι ταυτόχρονα και πάροχοι υπηρεσιών και πελάτες υπηρεσιών. Αυτή η προσέγγιση είναι ειδικά εφαρμόσιμη όταν πολλαπλές εφαρμογές που λειτουργούν σε διάφορες υπηρεσίες και πλατφόρμες χρειάζεται να επικοινωνούν μεταξύ τους. Με αυτόν τον τρόπο, οι επιχειρήσεις μπορούν να αναμιγνύουν και να ταιριάζουν υπηρεσίες για να ολοκλρηρώσουν επιχειρηματικές συναλλαγές με την μικρότερη προγραμματιστική προσπάθεια. 24

26 Σχ.2 Μοντέλο των web services Η ανακαλυψη των web services εμπεριέχει την επερώτηση αν το μητρώο του discovery agency για τα web services ταιριάζει με τις ανάγκες ενός αιτούντα για web services. H επερώτηση αποτελείται απο κριτήρια τύπου: τύπος της υπηρεσίας, αποδεχτό πεδίο τιμής, τι προιόντα ταιριάζουν με αυτήν την υπηρεσία, με ποιές κατηγορίες στην εταιρία και ταξινομήσεις προιόντων ταιριάζει το web service και άλλα τεχνικά χαρακτηριστικά. Η εύρεση της λειτουργίας μπορεί να περιέχει δύο περιπτώσεις από την πλευρά του αιτούντα: Στατικά, στον χρόνο σχεδιασμού για την ανάκτηση της περιγραφής μιας επιφάνειας υπηρεσίας για ανάπτυξη προγράμματος. Δυναμικά, σε χρόνο εκτέλεσης,για την ανάκτηση μιας σύνδεσης υπηρεσίας και περιγραφή της τοποθεσίας για επίκληση. Σε μία εφαρμογή για να εκμεταλευτούμε τις αλληλεπιδράσεις των web services μεταξύ των τριών ρόλων στο SOA, τρεις σημαντικές λειτουργείες πρέπει να λάβουν χώρα. Αυτές είναι έκδοση της περιγραφής της υπηρεσίας, εύρεση της περιγραφής της υπηρεσίας και σύνδεση των υπηρεσιών που βασίζονται στην περιγραφή της υπηρεσίας τους. Αυτές οι τρεις λειτουργείες μπορούν να συμβούν μεμονομένα ή επαναληπτικά και φαίνονται στο σχήμα επάνω που μας παραθέτει μία λογική αεπικόνιση της αρχιτεκτονικής προσανατολισμένη στις υπηρεσίες. Το σχήμα αυτό απεικονίζει την σχέση μεταξύ των τριών ρόλων και των τριων λειτουργειών. Καταρχήν, ο παροχέας του web service δημοσιεύει το web service του με τον πράκτορα ανακάλυψης (discovery agency). Στη συνέχεια ο αιτών για web service ψάχνει για επιθημητά web services χρησιμοποιώντας το αρχείο του πράκτορα ανακάλυψης. Τέλος ο αιτών για web service χρησιμοποιώντας τις πληροφορίες που έχει από τον discovery agency συνδέεται στο web service που του παρέχεται από τον παροχέα web service. Η τελευταία λειτουργεία στην αρχιτεκτονική των web service είναι η πραγματική σύνδεση του web service. Κατά τη διάρκεια της διαδικασίας σύνδεσης ο αιτών για υπηρεσία ξεκινά μια αλληλεπίδραση σε πραγματικό χρόνο (run time) χρησιμοποιώντας τις λεπτομέρειες σύνδεσης στην περιγραφή της υπηρεσίας για να εντοπίσει και να επικοινωνήσει με την εταιρία. Οι τεχνικές πληροφορίες που εισάγωνται στο μητρώο από τον παροχέα web services χρησιμοποιούνται εδώ. Το μοντέλο των web services ακολουθεί το παράδειγμα δημοσίευση (publίsh), εύρεση(find) και σύvδεση(bind). Στο πρώτο βήμα, ο προμηθευτής της υπηρεσίας δημοσιεύει την υπηρεσία σε ένα κατάλογο υπηρεσιών. Στο δεύτερο βήμα, ο πελάτης ο οποίος ψάχνει για μία υπηρεσία η οποία να καλύπτει τις απαιτήσεις του την αναζητεί στον κατάλογο. Αφού επιτυχημένα βρει πολλαπλές υπηρεσίες επιλέγει μία βάσει των προτιμήσεών του. Τότε μεταφορτώνει την περιγραφή της υπηρεσίας και συνδέεται (δεσμεύεται) με αυτήν ώστε να μπορέσει να καλέσει και να εκτελέσει την υπηρεσία. 25

27 Όταν µιλάµε λοιπόν για µία αρχιτεκτονική προσανατολισµένη στις υπηρεσίες προκύπτουν ορισµένα ζητήµατα. Η εφαρµογή που παρέχει την υπηρεσία και η εφαρµογή-πελάτης η οποία χρησιµοποιεί την υπηρεσία µιλάνε µεταξύ τους σε µια κοινή γλώσσα. Έπειτα οι δύο εφαρµογές χρειάζονται ένα τρόπο να εντοπίζουν η µία την άλλη πριν ξεκινήσουν να µιλούν µεταξύ τους. Αυτό αληθεύει ακόµη παραπάνω για τις κατανεµηµένες εφαρµογές όπου µία εφαρµογή δεν έχει καµία γνώση της θέσης της άλλης. Ως εκ τούτου, µπορούµε να πούµε ότι µια βασική αρχιτεκτονική για web services πρέπει να παρέχει: Έναν πρότυπο τρόπο για επικοινωνία. Έναν οµοιόµορφο µηχανισµό για περιγραφή και ανταλλαγή των δεδοµένων. Μια πρότυπη περιγραφική γλώσσα (meta language) για να περιγράψει τις υπηρεσίες που προσφέρονται. Ένα µηχανισµό για να καταχωρούνται και να εντοπίζονται οι εφαρµογές που βασίζονται σε web services. Καταχώρηση μιας υπηρεσίας Περιγραφή της υπηρεσίας χρησιμοποιώντας περιγραφική γλώσσα Κατάλογος υπηρεσιών Εντοπισμός μιας υπηρεσίας Πάροχος Web Service Ομοιόμορφη μορφή και ανταλλαγή δεδομένων Πελάτης Web Service Πρότυπο κανάλι επικοινωνίας Σχ.3 Aρχιτεκτονική των web services 26

28 2.3 Διαφορές από προηγούµενες τεχνολογίες Τίποτα από τα παραπάνω δεν είναι καινούριο. Στην πραγµατικότητα τα SUΝ/RPC, DCE/RPE, DCOM και EJB όλα παρέχουν παρόµοιες υπηρεσίες. Η διαφορά, εντούτοις,. είναι στο πώς παρέχονται αυτές οι υπηρεσίες. Οι παραδοσιακές RPC υπηρεσίες απαιτούν παρόµοια αρχιτεκτονική υποδοµής, µορφή δεδοµένων, κλπ. Για παράδειγµα, δύο διαφορετικές υλοποιήσεις RPC προκειµένου να επικοινωνήσουν, και οι δύο πρέπει να παράσχουν µηχανισµούς επικοινωνίας. Ιστορικά τέτοια επικοινωνία καθορίστηκε φτωχά και απαιτούσε µεγάλη φροντίδα για να µπορέσουν τα δύο συστήµατα να επικοινωνήσουν. Τα web services διαφέρουν από τους παραδοσιακούς RPC µηχανισµούς από πολλές όψεις: 27

29 Τα δεδοµένα είναι µορφοποιηµένα για µεταφορά χρησιµοποιώντας XML, βελτιώνοντας ή εξαλείφοντας τo marshalling (η διαδικασία της μετατροπής της αναπαράστασης μιας μνήμης ενός αντικειμένου σε μια μορφή δεδομένων που είναι κατάλληλη για αποθήκευση και εκμπομπή), το unmarshalling και άλλες σχετικά µε τη µετάφραση απαιτήσεις που συνήθως προγραµµατίζονταν από τον ίδιο τον προγραµµατιστή. Τα δεδοµένα ανταλλάσσονται χρησιµοποιώντας προτυποποιημένα πρωτόκολλα όπως το HTTP ή το SMTP, τα οποία έχουν δηµοσιευµένα καλά καθορισµένα πρότυπα. Η προς έκθεση υπηρεσία είναι καλά καθορισµένη χρησιµοποιώντας ένα γνωστό και αποδεκτό µηχανισµό, την WSDL. Οι υπηρεσίες ανευρίσκονται χρησιµοποιώντας ένα καλά καθορισµένο πρότυπο, το UDDI, και το πιο εξελιγμένο ebxml. 28

30 2.4 Βασικά βήματα για την ανάπτυξη εφαρμογών με web services Τα βασικά βήματα για την ανάπτυξη μιας εφαρμογής web services είναι: Καθορισμός υπηρεσιων που θα παρέχονται Προσδιορισμός των υπηρεσιών που θα απαιτηθούν Υλοποίηση της λειτουργίας πίσω από την υπηρεσία Εγκατάσταση της εφαργμογής - παρόχου των υπηρεσιών Εντοπισμος του web service ρωτώνταςμία υπηρεσία καταλόγου Δημοσίευση των web services με μία υπηρεσία καταλόγου Αποστολή της αίτησης στην υπηρεσία Αναμονή για επεξεργασία αιτήσεων πελατών Λήψη της απάντησης απο την υπηρεσία Πάροχος υπηρεσίας Χρήστης υπηρεσίας Αυτά τα βήματα θα είναι τα ίδια ανεξαρτήτως της τεχνολογίας και της γλώσσας προγραμματισμού που θα χρησιμοποιηθεί για την υλοποίηση των web services. 29

31 3 ΧΜL Η extensible Markup Language (XML) είναι µια γλώσσα ανεξάρτητη από σύστηµα και υλικό για την αναπαράσταση δεδοµένων και της µορφής τους σε ένα έγγραφο XML (XML document). Ένα έγγραφο XML στην πιο απλή του µορφή είναι ένα αρχείο κειµένου το οποίο περιέχει δεδοµένα µαζί µε σήµανση η οποία καθορίζει τη δοµή των δεδοµένων. Η XML είναι µια παγκοσµίως συµφωνηµένη µεταγλώσσα σήµανσης που χρησιµοποιείται πρώτιστα για την ανταλλαγή πληροφοριών. Η οµορφιά της XML βρίσκεται στο γεγονός ότι είναι επεκτάσιµη. Απλά, η XML είναι ένα σύνολο προκαθορισµένων κανόνων (συντακτικό πλαίσιο) που πρέπει να ακολουθήσουµε κατά τη δόµηση των δεδοµένων µας. Για ένα µεγάλο χρονικό διάστηµα, οι προγραµµατιστές και οι προµηθετές εφαρµογών κατασκεύαζαν εφαρµογές και συστήµατα εγκατεστηµένα σε µια επιχείρηση τα οποία επεξεργάζονταν, δεδοµένα τα οποία µπορούσαν να µε το δικό τους ιδιωτικό τρόπο. Αλλά. καθώς η ανταλλαγή πληροφορίας µεταξύ εφαρµογών και συστηµάτων στις επιχειρήσεις επικρατούσε, έγινε πολύ δύσκολο να αναταλλάσεις δεδοµένα διότι τα συστήµατα δε σχεδιάστηκαν ώστε να δέχονται δεδοµένα από εξωτερικά, άγνωστα συστήματα. Η XML παρέχει µία πρότυπη και κοινή δοµή για τη διανοµή δεδοµένων µεταξύ ανόµοιων συστηµάτων. Επιπλέον, η XML έχει ενσωµατωµένο ένα µηχανισµό επικύρωσης δεδοµένων, ο οποίος εγγυάται ότι η δοµή των δεδοµένων που λαµβάνεται είναι έγκυρη. 3.1 Παράδειγµα αναπαράστασης δεδοµένων µε ΧΜL Αναπαράσταση δεδομένων με τη βοήθεια της XML: <employee> <shift id= "counter" time="8-12"> <phone id = ''1''>All phone information <number> </number> </phone> </shift > <shift id="help_desk" time=''1-5"> <phone id = "2"> Αll phone information <number>332333</number> </phone> </shift > 30

32 < home-address> <street>3434 Norwalk street</street> <city>new York</city> <state>ny </state> </home-address> </employee> Στο παραπάνω παράδειγμα, αναπαριστούμε τις προσωπικές πληροφορίες και τις πληροφορίες σχετικά με τις βάρδιες ενός υπαλλήλου σε ένα οργανισμό. Βλέπουμε πώς η ΧΜL χρησιμοποιεί τις διοκριτικές ετικέτες "<>" και "</>" παρόμοια με τις ετικέτες που χρησιμοποιούνται στην HTML. Αυτό συμβαίνει γιατί η ΧΜL είναι μια γλώσσα σήμανσης σαν την HTML. Η κύρια διαφορά της ΧΜL με την ΗΤΜL είναι ως προς τον σκοπό της κάθε μίας: Η ΧΜL σχεδιάστηκε για να περιγράφει δεδομένα και να εστιάσει στο τί είναι αυτά τα δεδομένα. Η ΗΤΜL σχεδιάστηκε για να προβάλει δεδομένα και να εστιάσει στο πώς φαίνονται αυτά τα δεδομένα. Στο παραπάνω παράδειγμα βλέπουμε ότι έχουμε να κάνουμε με καθαρά δεδομένα: ότι ένας υπάλληλος (employee) έχει παραπάνω από μία βάρδιες (shίft), για παράδειγμα το πρωί εργάζεται στο ταμείο (counter) και το μεσημέρι στο γραφείο βοήθειας (help desk) και διευθύνσεις. Οι δύο αρχικές δομικές μονάδες ΧΜL που χρησιμοποιούνται στο προηγούμενο παράδειγμα είναι τα elements (στοιχεία) και τα attributes (ιδιότητες). 3.2 Elements ή Στοιχεία Τα στοιχεία (elements) είναι ετικέτες όπως και στην ΗΤΜL,και παρέχουν τιμές. Επιπλέον τα elements είναι δομημένα σαν δένδρο. 'Ως εκ τούτου έχουμε τα στοιχεία οργανωμένα σε ένα ιεραρχικό τρόπο με ένα στοιχείο-πατέρα και στοιχεία-παιδιά. Τα στοιχεία-παιδιά μπορούν να περιέχουν και αυτά άλλα στοιχεία-παιδιά και ούτω καθεξής. Στο προηγούμενο παράδειγμα, το στοιχείο <employee> είναι το γονικό στοιχείο και έχει το στοιχείο <shift> σαν στοιχείο-παιδί. παρακάτω το στοιχείο <phone> είναι στοιχείο-παιδί του γονικού στοιχείου <shift>. Τα στοιχεία έχουν συγκεκριμένα χαρακτηριστικά. Ορισμένα από αυτά είναι: Τα στοιχεία μπορεί να περιέχουν δεδομένο, οπως το στοιχείο <number> στο παράδειγμα. 31

33 Αντίστροφα τα στοιχεία μπορεί να μην περιέχουν δεδομένα αλλά μόνο ιδιότητες όπως το στοιχείο <shift>. Εναλλακτικά, τα στοιχεία μπορεί να περιέχουν ταυτόχρονα και ιδιότητες αλλά και δεδομένα, αλλά επίσης και στοιχείο-παιδιά, όπως το στοιχείο <phone>. Τα στοιχεία έχουν κάποιους κανόνες: Όλα τα στοιχεία πρέπει να έχουν ετικέτα κλεισίµατος αντίθετα µε την ΗΤΜL όπου υπάρχουν και ετικέτες που δε χρειάζονται κλείσιµο όπως για παράδειγµα η <br>. Οι ετικέτες των στοιχείων είναι case sensitive δηλαδή υπάρχει διαχωρισµός µεταξύ κεφαλαίων και πεζών και τα ονόµατά τους υπακούουν σε κανόνες ονοµατολογίας. Τα στοιχεία πρέπει να είναι τοποθετηµένα σωστά αντίθετα µε την HTML. ΗΤΜL: <b><i>this text is bold and italic</b> </ί> ΧΜL : <b><i>this text is bold and italic</i></b> Τα έγγραφα της ΧΜL πρέπει να έχουν ακριβώς ένα αρχικό στοιχείο (root element). 3.3 Attributes ή Ιδιότητες Οι ιδιότητες (attributes) µας βοηθούν να δώσουµε περισσότερο νόηµα και να περιγράψουµε τα στοιχεία µας πιο αποτελεσµατικά και µε σαφήνεια. Στο προηγούµενο παράδειγµα, το στοιχείο <shift> έχει µία ιδιότητα "id" µε τιµές "counter" και "help_desk". Με τη χρήση τέτοιων ιδιοτήτων, µπορούµε να ξέρουµε άν ένας υπάλληλος εργάζεται στο ταµείο ή στο γραφείο βοήθειας. Αυτό βοηθάει στο να κάνουµε τα δεδοµένά σε ένα έγγραφο ΧΜL αυτοπεριγραφικά. Πρέπει πάντα να θυµόµαστε ότι ο κύριος σκοπός των ιδιοτήτων είναι να παρέχουν περισσότερη πληροφορία σχετική µε ένα στοιχείο και δεν πρέπει να χρησιµοποιούνται για να περιέχουν τα ίδια τα δεδομένα. Όπως και τα στοιχεία έτσι και οι ιδιότητες έχουν κάποιους κανόνες : Οι τιµές των ιδιοτήτων πρέπει να εσωκλείωνται σε " " ή σε Τα ονόµατα των ιδιοτήτων ακολουθούν τους ίδιους κανόνες µε αυτά των ετικετών. 32

34 3.4 Κανόνες ονοµασίας Τα στοιχεία και οι ιδιότητες στην ΧΜL πρέπει να ακολουθούν στους Παρακάτω κανόνες : Τα ονόµατα µπορούν να περιέχουν γράµµατα, αριθµούς και άλλους χαρακτήρες. Τα ονόµατα δεν πρέπει να ξεκινούν µε αριθµό ή χαρακτήρα στίξης. Τα ονόµατα δεν πρέπει να ξεκινούν µε τα γράµµατα xml (ή ΧΜL, ή Xml κλπ.). Τα ονόµατα δεν µπορούν να περιέχουν κενά. 3.5 Καλά διαμορφωμένα έγγραφα (well formed documents) Ένα «καλά διαμορφωμένο» έγγραφο ΧΜL είναι ένα έγγραφο που υπακούει στους κανόνες σύνταξης της ΧΜL που αναφέραμε προηγουμένως : Τα έγγραφα ΧΜL πρέπει να περιέχουν ένα αρχικό στοιχείο. Τα στοιχεία ΧΜL πρέπει να έχουν ετικέτες κλεισίματος. Στις ετικέτες ΧΜL υπάρχει διαχωρισμός κεφαλαίων και πεζών. Τα στοιχεία ΧΜL πρέπει να είναι σωστα τοποθετημένα. Οι ιδιότητες ΧΜL πρέπει να εσωκλείονται πάντα σε " " ή σε 3.6 DTD Όπως σε μία γλώσσα προγραμματισμού πρέπει να ξέρουμε τις προδιαγραφές της γλώσσας, με παρόμοιο τρόπο το Document Type Defίnition (DTD) είναι μία προδιαγραφή, η οποία πρέπει να ακολουθηθεί όταν δημιουργούμε ένα έγγραφο ΧΜL. Επίσης, όπως μία από τις εργασίες του μεταγλωπιστή για κάθε γλώσσα προγραμματισμού είναι να ελέγξει αν η προδιαγραφές ακολουθήθηκαν, με παρόμοιο τρόπο υπάρχουν ΧΜL parsers οι οποίοι χρησιμοποιούν το DTD για να ελέγξουν την εγκυρότητα ενός εγγράφου ΧΜL. 33

35 Ένα DTD μας βοηθάει να καθορίσουμε τη δομή ενός εγγράφου ΧΜL. Μας παρέχει ένα αυστηρό πλαίσιο και κανόνες οι οποίοι θα ακολουθηθούν όταν δημιουργούμε έγγραφα ΧΜL. Επιπρόσθετα, το DTD μπορεί να χρησιμοποιηθεί για τον έλεγχο της εγκυρότητας και της ακεραιότητας των δεδομένων που περιέχονται σε ένα έγγραφο ΧΜL. Μερικά χαρακτηριστικά του DTD είναι τα παρακάτω: Το DTD χρησιμοποιείται για να καθορίσει έγκυρα στοιχεία και ιδιότητες που μπορούν να χρησιμοποιηθούν σε ένα έγγραφο ΧΜL. Με ένα DTD μπορούμε να καθορίσουμε μια ιεραρχική δομή στοιχείων. Σε ένα DTD μπορεί επίσης να καθοριστεί η διαδοχική οργάνωση μιας συλλογής στοιχείων-παιδιών τα οποία μπορούν να υπάρχουν σε ένα έγγραφο ΧΜL. Ένα DTD μπορεί να χρησιμοποιηθεί απευθείας μέσα σε ένα έγγραφο ΧΜL ή μπορεί να υπάρχει εκτός του εγγράφου ΧΜL. Στη δεύτερη περίπτωση θα αναφέρεται με ένα δεσμό μέσα στο έγγραφο ΧΜL που δείχνει σε αυτό το DTD. Το DTD αποτελείται από τα παρακάτω στοιχεία : DTD element: Μεταδεδοµένα για ένα στοιχείο. Καθορίζει τι είδους δεδοµένα θα έχει το στοιχείο, τον αριθµό των περιστατικών κάθε στοιχείου, τις σχέσεις µεταξύ των στοιχείων και ούτω καθ 'εξής. DTD Attributes: Καθορίζει διάφορους κανόνες και ορισµούς που σχετίζονται µε τα δεδοµένα. DTD Entities: Χρησιµοποιείται για να αναφέρει ένα εξωτερικό αρχείο ή για να παρέχει συντομεύσεις σε κοινό κείµενο. DTD Notations: καθορίζουν κάποιους τύπους εξωτερικών δυαδικών δεδομένων. Παράδειγµα : <!ELEMENT employee(shift+,home-address, hobbies*)> Ένα στοιχείο employee µπορεί να περιέχει ένα ή περισσότερα στοιχεία shift, πρέπει να έχει ένα στοιχείο home-address και µπορεί να έχει µηδέν ή περισσότερα στοιχεία hobbies. Παράδειγµα: <!ΑΤΤLΙSΤ shift id CDΑΤΑ #REQUIRED> ΤΟ στοιχείο shift πρέπει να έχει µία ιδιότητα id. Εν ολίγοις, ένα DTD χρησιµοποιείται για να καθορίσει µια δοµή εγγράφων µε τη διευκρίνιση των λεπτοµερειών σχετικά µε όλα τα στοιχεία και τις ιδιότητες που πρόκειται να χρησιµοποιηθούν σε ένα έγγραφο XML. Ως εκ τούτου µπορεί να χρησιµοποιηθεί για να ελέγξει την εγκυρότητα ενός εγγράφου ΧΜL που υποτίθεται ότι ακολουθεί τους κανόνες που καθορίζονται από αυτό το DTD. 34

36 3.7 ΧΜL Schema Το ΧΜL Schema'έίναι µια πιο προηγµένη έκδοση του DTD. Το DTD έχει πολλά µειονεκτήµατα σε σχέση µε το schema, όπως το ότι δεν υποστηρίζει ισχυρούς τύπους δεδοµένων, έχει σύνταξη διαφορετική από την ΧΜL και δεν είναι επεκτάσιµο. Το ΧΜL Schema παρουσιάστηκε για να υπερνικήσει αυτά τα μειονεκτήματα. Οι δύο κύριοι στόχοι του W3C ΧΜL Schema working group κατά τη διάρκεια του σχεδιασµού του προτύπου του ΧΜL Schema ήταν: Να µπορέσουν να εκφράσουν µέσα στο πρότυπο αρχές αντικειµενοστραφούς σχεδιασµού οι οποίες µπορούν να βρεθούν σε όλες τις αντικειµενοστραφείς γλώσσες προγραµµατισµού. Να παρέχουν υποστήριξη για σύνθετους τύπους δεδοµένων παρόµοια µε την υποστήριξη που υπάρχει στις περισσότερες σχεσιακές βάσεις δεδοµένων. Τα κυριότερα χαρακτηριστικά της XML schema είναι τα παρακάτω: Η σύνταξη είναι όμοια με της XML. Αυτό σημαίνει ότι μπορούμε να επεξεργαστούμε το schema με οποιοδήποτε επεξεργαστή XML. Δεν καθορίζουμε μόνο βασικούς τύπους δεδομένων όπως αλφαρηθμητικό, ακέραιος, πραγματικός και ούτω καθ'εξής αλλά μπορούμε επίσης να καθορίσουμε δικούς μας τύπους δεδομένων. Για παράδειγμα: <xs:element name="name" type="xs:string " /> Οι νέοι τύποι που μπορούμε να καθορίσουμε μπορεί να είναι απλοί ή σύνθετοι. Οι σύνθετοι τύποι μπορεί να περιέχουν και άλλα στοιχεία ή και ιδιότητες, ενώ οι απλοί τύποι όχι. Αντίθετα μπορούν να περιέχουν μόνο δεδομένα. Το XML Schema παρέχει επικύρωση βασισμένη στο περιεχόμενο (content-based valίdation) δηλαδή μπορεί να ορίσει την σειρά με την οποία τα στοιχεία-παιδιά εμφανίζονται. Επίσης παρέχει επικύρωση στους ίδους τύπους δεδομένων. Για παράδειγμα μπορούμε να ορίσουμε έναν απλό τύπο ''year'' με τιμές μεταξύ 2000 και 2100: <xsd:simpletype name=''year''> < xsd : restriction base = "xsd : ίnteger" > <xsd:minlnclusive value="2000''/> <xsd:maxlnclusive value="2100"/> < /xsd: restriction > </ xsd:simpletype> 35

37 παρομοίως οι σύνθετοι τύποι μπορεί να ορίσουν τη σειρά με την οποία τα στοιχεία-παιδιά θα εμφανίζονται: <xsd:complextype name= 'Employee"> <xsd: sequence> <xsd: element name="name" type="xsd:string" /> <xsd:element name='άddress" type="xsd:string" /> <xsd:element name="phone" type="xsd:string" /> </sd:sequence> </xsd:complextype> Το XMLSchema μας παρέχει τη δυνατότητα να επεκτείνουμε άλλα έγγραφα το οποίο δεν είναι τίποτα άλλο παρά κληρονομικότητα. Αυτό σημαίνει ότι μπορούμε να παράγουμε νέους τύπους δεδομένων βάσει παλαιών τύπων. To ΧML Schema παρέχει υποστήριξη για Namespaces (χρησιμοποιώντας URI) παρέχει σε κάθε στοιχείο ένα μοναδικό αναγνωριστικό, µε το οποίο αποφεύγονται συγκρούσεις ονοµάτων µεταξύ των στοιχείων. Αυτό θα µπορούσε να συµβεί, για παράδειγµα, όταν δύο έγγραφα συγxωνεύονταν, και περιείχαν και τα δύο στοιχεία µε όνοµα "name" τα οποία όµως είχαν διαφορετικό νόηµα σε κάθε έγγραφο. Εν ολίγοις βοηθάει στο να ξεχωρίζουν στοιχεία και ιδιότητες µε ίδιο όνοµα και διαφορετικό νόηµα. Μία απλή αναλογία στις γλώσσες προγραµµατισµού είναι η χρήση καθολικών και τοπικών µεταβλητών. Μια τοπική µεταβλητή είναι µοναδική µέσα στο πεδίο ισχύος της ενώ µια καθολική µεταβλητή πρέπει να είναι µοναδική σε ολόκληρο το πρόγραµµα. Παροµοίως, µε το namespace έχουµε την ελευθερία να ορίσουµε τύπους χωρίς να ανησυχούµε για συγκρούσεις ονομάτων. Τέλος το ΧΜL Schema είναι εύκολα επεκτάσιµο για να ενσωµατώσει και άλλες λειτουργίες στο µέλλον. 3.8 Σύγκριση του ΧΜL Schema µε το DTD ΟΙ κυριότερες διαφορές συνοψίζονται ως εξής : Το ΧΜL Schema είναι επέκταση του DTD. Το ΧΜL Schema υποστηρίζει namespaces ενώ το DTD όχι. Το ΧΜL Schema χρησιµοποιεί σύνταξη ΧΜL η οποία είναι εύκολη να την κατανοήσεις ενώ το DTD χρησιµοποιεί ειδική σύνταξη. Το ΧΜL Schema υποστηρίζει πρότυπους τύπους δεδοµένων καθώς επίσης και τύπους ορισµένους από το χρήστη (user-defίned) ενώ το DTD παρέχει µόνο τύπους κειµένου. Το ΧΜL Schema υποστηρίζει κληρονοµικότητα ενώ το DTD όχι. 36

38 4 WSDL και UDDI 4.1 Ορισµός και σκοπός της WSDL Ο ορισµός που δίνει το W3C για την Web Serνices Description Language είναι ο παρακάτω : Η WSDL είγαι έγα σχήµα ΧΜL για τηγ περιγραφή δικτυακών υπηρεσιών σαν ένα σύνολο από τελικά σηµεία που λειτουργούν σε µηνύµατα τα οποία περιέχουν πληροφορία είτε προσανατολισµένη στα έγγραφα είτε πρσανατολισµένη στις διαδικασίες. Οι λειτουργίες και τα µηνύµατα περιγράφovται περιληπτικά και τότε δένovται σε ένα συγκεκριµένο πρωτόκολλο δικτύων και µορφή µηνυµάτων για να καθορίσουν έγα τελικό σηµείο. Πολλά σχετικά τελικά σηµεία συνδυάζονται σε υπηρεσίες (seιvices). Η WSDL είναι επεκτάσιµη στο να επιτρέπει την περιγραφή τελικών σηµείων και των µηνυµάτων τους άσχετα από τη µορφή των µηγυµάτων και των πρωτοκόλλων δικτύων που xρησιµoπoιoύvται για την επικοινωνία. Παρόλα αυτά, αυτή τη στιγµή στην προδιαγραφή της WSDL οι µόνες συνδέσεις που περιλαµβάνovται περιγράφουν πώς µπορούµε να χρησιµοποιήσουµε την WSDL σε συvδυασµό µε το SOAP 1.1, το ΗΤΤΡ GET/POST και το ΜΙΜΕ " Με πιο απλά λόγια η WSDL µας βηθάει να περιγράψουµε ένα σύνολο από µηνύµατα και το πώς αυτά τα µηνύµατα ανταλλάσσονται. Για να καταλάβουµε την αξία της WSDL, µπορούµε να υποθέσουµε ότι θέλουµε να καλέσουµε ένα web serνice µέσω SOAP το οποίο µας παρέχεται από έναν συνεργάτη µας. Θα µπορούσαµε να του ζητήσουµε µερικά παραδείγµατα µηνυµάτων SOAP και να γράψουµε κώδικα στην εφαρµογή µας για να παράγουµε και να καταναλώνουµε µηνύµατα SOAP που µοιάζουν µε αυτά τα παραδείγµατα. Κάτι τέτοιο όµως είναι επιρρεπές σε λάθη. Για παράδειγµα, θα βλέπαµε ένα ΙD πελάτη µε την τιµή 2837 και θα υποθέταµε ότι είναι ακέραιος ενώ στην πραγµατικότητα θα ήταν αλφαρηθµητικό. Η WSDL καθορίζει τι πρέπει να περιέχει ένα µήνυµα και πώς πρέπει να είναι ένα µήνυµα απάντησης µε σαφή οήµανση. Η σήµανση που χρησιµοποιείται σε ένα αρχείο WSDL για να περιγράψει µορφές µηνυµάτων βασίζεται στο πρότυπο του ΧΜL Schema το οποίο σηµαίνει ότι είναι ταυτόχρονα ανεξάρτητη από γλώσσα προγραµµατισµού και βασισµένη σε πρότυπα. Αυτό το γεγονός την κάνει κατάλληλη για να περιγράψει διεπαφές web serνices οι οποίες είναι προσβάσιµες από µία µεγάλη ποικιλία πλατφορµών και γλωσσών προγραµµατισµού. Επιπλέον, εκτός του ότι περιγράφει τα 37

39 περιεχόµενα των µηνυµάτων, η WSDL ορίζει πού είναι διαθέσιµη µία υπηρεσία και ποιά πρωτόκολλα επικοινωνίας χρησιµοποιούνται για να επικοινωνήσουµε µε αυτή την υπηρεσία. Αυτό σηµαίνει ότι ένα αρχείο WSDL ορίζει όλα όσα χρειάζονται για να γράψουµε ένα πρόγραµµα το οποίο να λειτουργεί µε ένα web service. 4.2 Tεχνική περιγραφή της WSDL Η WSDL παρέχει ένα τρόπο στους παροχείς υπηρεσιών να περιγράψουν τη βασική µορφή των αιτήσεων και απαντήσεων των υπηρεσιών πάνω από διαφορετικά πρωτόκολλα και κωδικοποιήσεις. Η WSDL χρησιµοποιείται για να περιγράψει τι μπορεί να service, πού βρίσκεται και πώς να το καλέσει κανείς. κάνει ένα web Οι κατάλογοι UDDI περιγράφουν πολλές πτυχές των web services, συµπεριλαµβανοµένων και των λεπτοµερειών σύνδεσης µίας υπηρεσίας. Η WSDL ταιριάζει απόλυτα σε µια τέτοια περιγραφή µιας υπηρεσίας του UDDI. Η WSDL ορίζει υπηρεσίες σαν συλλογές από τελικά σηµεία δικτύου ή αλλιώς ports. Στην WSDL ο περιγραφικός ορισµός των τελικών σηµείων και των µηνυµάτων διαχωρίζεται από συγκεκριµένα διακτυακά πρωτόκολλα ή µορφές δεδοµένων. Αυτό επιτρέπει την επαναχρησιµοποίηση των περιγραφικών ορισµών, των µηνυµάτων (messages).τα µηνύµατα είναι αόριστες περιγραφές των δεδοµένων που ανταλλάσσονται και των τύπων τελικών σηµείων (port types).οι τύποι τελικών σηµείων είναι συλλογές λειτουργιών. Το συγκεκριµένο πρωτόκολλο και ο ορισµός της µορφής των δεδοµένων για ένα συγκεκριµένο τύπο τελικών σηµείων δηµιουργεί µία επαναχρησιµοποιούµενη σύνδεση (binding). Ένα τελικό σηµείο (port) ορίζεται συνδέοντας µια διεύθυνση δικτύου µε µία επαναχρησιµοποιούµενη σύνδεση (binding), και µία συλλογή τελικών σηµείων ορίζουν µία υπηρεσία (service). Ως εκ τούτου, ένα έγγραφο WSDL χρησιµοποιεί τα παρακάτω στοιχεία για τον ορισµό δικτυακών υπηρεσιών : Types - ένα περίβληµα για ορισµούς τύπων δεδοµένων χρησιµοποιώντας ένα σύστηµα τύπων (όπως για παράδειγµα το ΧΜL Schema). Message - ένας περιγραφικός ορισµός των δεδοµένων που ανταλλάσσονται. Operation - µία περιγραφή µίας λειτουργίας που υποστηρίζεται από µία υπηρεσία 38

40 Port Type - ένα περιγραφικό σύνολο από λειτουργίες που υποστηρίζονται από ένα ή περισσότερα τελικά σηµεία. Binding - ένα συγκεκριµένο πρωτόκολλο και µορφή δεδοµένων για ένα συγκεκριµένο τύπο τελικών σηµείων (port type). Port - ένα µοναδικό τελικό σηµείο που ορίζεται σαν συνδυασµός µίας σύνδεσης (binding) και µιας διεύθυνσης δικτύου. Service - µία συλλογή από σχετικά τελικά σηµεία. 4.3 Περιγραφή και σκοπός του UDDI Ο σκοπός που δίνει το OASIS για το Universal Description, Discovery and Integration είναι ο παρακάτω : "Τα web services έxouv vόηµα µόvο όταv δυvητικοί χρήστες µπορούv va βρουv πληροφορίες ικαvές ώστε va επιτρέψουv τηv εκτέλεσή τους. Το Universal Descrίption Discovery & Integration (UDDI) εστιάζει στον καθορισµό ενός συvόλου από υπηρεσίες που θα υποστηρίζουv τηv περιγραφή και τηv αvακάλυψη: 1. Των εταιριών, των οργαvισµώv και άλλωv παρόχωv web services 2. Των web services, που είvαι διαθέσιµες 3. Και των τεχvικώv διεπαφώv οι οποίες µπορούv va χρησιµοποιηθούv ώστε να έχει κάποιος χρήστηςπρόσβαση σε αυτές τις υπηρεσίες. Βασισµέvο σε ένα κοιvό σύvολο από βιοµηχαvικά πρότυπα, συµπεριλαµβαvοµέvωv των ΗΤΤP, ΧΜL, ΧΜL Schema και SOAP το UDDI παρέχει µία διαλειτουργική, θεµελιώδη υποδοµή για έvα περιβάλλοv λογισµικού προσαvατολισµέvο στις υπηρεσίες τόσο για δηµόσια διαθέσιµες υπηρεσιές όσο και για υπηρεσίες που εκτίθενται µόvο εσωτερικά εvός οργαvισµσύ." Με πιο απλά λόγια το UDDI είναι ο «χρυσός οδηγός» των web services. Όπως σε ένα χρυσό οδηγό, µπορούµε να αναζητήσουµε µια εταιρία που προσφέρει τις υπηρεσίες που χρειαζόµαστε, να διαβάσουµε για µια προσφερόµενη υπηρεσία και να επικοινωνήσουµε µε κάποιον για περισσότερες λεπτοµέρειες. Φυσικά µπορούµε να προσφέρουµε ένα web service χωρίς να το καταχωρίσουµε στο UDDI, όπως αν ανοίγαµε µία επιχείρηση στο υπόγειο του σπιτιού µας και βασιζόµασταν στη διαφήµιση από στόµα σε στόµα. Αλλά αν θέλουµε να αγγίξουµε το ευρύ κοινό, θα χρειαστούµε το UDDI ώστε οι δυνητικοί µας πελάτες να µπορέσουν να µας βρούν. 39

41 4.4 Υπηρεσίες του UDDI Το UDDI παρέχει ένα µηχανισµό στους πελάτες να βρίσκουν δυναµικά άλλα web services. Χρησιμοποιώντας µία διεπαφή UDDI, οι επιχειρήσεις µπορούν να συνδεθούν δυναµικά µε υπηρεσίες που παρέχονται από εξωτερικούς συνεργάτες. Ένας κατάλογος UDDI (UDDI registry) είναι όµοιος µέ ένα CORBA trader, ή θα µπορούσαµε να τον παροµοιάσουµε µε µία υπηρεσία DNS αλλά για εφαρµογές. Ένας κατάλογος UDDI έχει δύο ειδών πελάτες : επιχειρήσεις που θέλουν να δηµοσιεύσουν µια υπηρεσία (και τις διεπαφές της), και πελάτες που θέλουν να χρησιµοποιήσουν συγκεκριµένες υπηρεσίες και συνδέονται προγραµµατιστικά µε αυτές. Ο παρακάτω πίνακας περιγράφει περιληπτικά τις προσφερόµενες υπηρεσίες του UDDΙ. Πληροφορία Λειτουργίες Λεπτοµέρειες (που υποστηρίζονται από το ΑΡΙ) White pages: Publish: Πώς ο Business Information: Πληροφορίες όπως προµηθευτής ενός Περιλαµβάνεται σε ένα το όνοµα, η web serνice αντικείµενο BusinessEntity, το διεύθυνση, το καταχωρεί των οποίο µε τη σειρά του τηλέφωνο και άλλες εαυτό του. περιλαµβάνει πληροφορίες για πληροφορίες υπηρεσίες, κατηγορίες, επαφές, επικοινωνίας για µία URLs, και άλλα αναγκαία επιχείρηση. για να αλληλεπιδράσουµε µε µία επιχείρηση. Yellow Pages: Find: Πώς µία Serνice Information: Πληροφορίες που εφαρµογή βρίσκει Περιγράφει µία οµάδα από web κατηγοριοποιούν ένα συγκεκριµένο serνices. Αυτές περιλαµβάνονται επ ιχειρήσεις. web seryice. σε ένα αντικείµενο Βασίζονται σε BusinessService. υπάρχοντα πρότυπα κατηγοριοποίησης (μη ηλεκτρονικά) Green Pages: Bind: Πώς µία Binding Information: Οι τεχνικές εφαρµογή απαραίτητες τεχνικές πληροφορίες για τα συνδέεται, και λεπτοµέρειες για την κλήση ενός web serνices που αλληλεπιδρά µε ένα web serνice. Περιλαµβάνουν τα παρέχονται από µία web serνice αφού URLs, πληροφορίες για ονόµατα επιχείρηση. αυτό βρεθεί. µεθόδων, τύπους ορισµάτων και ούτω καθ'εξής. Το αντικείµενο BindingTemplate αναπαριστά αυτά τα δεδοµένα. 40 Serνice Specification Detail: Πρόκειται για µεταδεδοµένα για διάφορες προδιαγραφές που υλοποιούνται από ένα web serνice. Αυτά καλούνται tmodels.

42 Είναι απαραίτητο να σημειωθεί ότι αυτό είναι απλά ένα θεμελιώδες μοντέλο, και πως το UDDI δεν καθορίζει κάποιο συγκεκριμένο μοντέλο αποθήκευσης. Μια καταχώρηση μιας οντότητας στις λευκές σελίδες θα περιέχει και πληροφορίες ταξινόμησης, που θα δείχνουν τη θέση της οντότητας αυτής στις κίτρινες σελίδες, και επίσης, μια καταχώρηση μιας υπηρεσίας κάποιας οντότητας θα περιέχει πληροφορίες υλοποίησης που θα δείχνουν τη θέση της οντότητας αυτής μέσα στις πράσινες σελίδες. Αυτό αντανακλάται στις λεπτομέρειες της δομής businessentity. Το στοιχείο businessentity, πέρα από κάποιες πληροφορίες επικοινωνίας, αναγνώρισης και ταξινόμησης, περιέχει ένα businessservices στοιχείο, που είναι ένα πεδίο για στοιχεία τύπου businessservice. Ένα στοιχείο businessservice με τη σειρά του, περιέχει ένα στοιχείο bindingtemplates, το οποίο είναι ένα πεδίο για στοιχεία τύπου bindingtemplate. Τέλος, οι καταχωρήσεις bindingtemplate δείχνουν σε καταχωρήσεις tmodel. 4.5 Η δομή δεδομένων tmodel Η άλλη σημαντική δομή του μοντέλου πληροφορίας του UDDI, είναι το στοιχείο tmodel. Οι καταχωρήσεις στις πράσινες σελίδες, είναι στην ουσία εξειδικευμένες πληροφορίες κάθε επιχείρησης που συνδέουν πληροφορίες για τύπους υπηρεσιών και άλλες έννοιες που ορίζονται αλλού. Αυτές οι επαναχρησιμοποιήσιμες έννοιες αποκαλούνται μοντέλα τεχνολογίας, και η δομή δεδομένων του UDDI που αντιστοιχεί είναι το στοιχείο tmodel. Αυτό το στοιχείο δίνει τη δυνατότητα σε ομάδες βιομηχανιών, σε σώματα προτύπων αλλά και σε μεμονωμένες επιχειρήσεις να μπορούν να καθορίζουν επαναχρησιμοποιήσιμους εννοιολογικούς ορισμούς τύπων υπηρεσιών, οι οποίοι μπορούν να χρησιμοποιηθούν και να συνδυαστούν, σχηματίζοντας μια υπογραφή για μια υπηρεσία. 4.6 Προγραμματιστική διεπαφή του UDDI Γενική περιγραφή Εκτός από τον ορισμό των δομών δεδομένων που θα αποθηκεύονται στον κατάλογο, οι προδιαγραφές του UDDI παρέχουν και δύο βασικούς τύπους προγραμματιστικών διεπαφών: την προγραμματιστική διεπαφή δημοσίευσης και την προγραμματιστική διεπαφή ερώτησης. Αυτές οι δύο διεπαφές ορίζουν ένα σύνολο από 20 μηνύματα SOAP για το πρωτόκολλο HTTP ή για το HTTPS, τα οποία πρέπει να είναι κατανοητά από οποιοδήποτε κατάλογο συμβατό με το UDDI πρότυπο. Το SOAP τμήμα του μηνύματος καθώς και οι απαντήσεις είναι δομές της XML που καθορίζονται στις προδιαγραφές του UDDI. Η προγραμματιστική διεπαφή δημοσίευσης ορίζει είναι ένα πιστοποιημένο σύνολο λειτουργιών που επιτρέπει στους οργανισμούς να δημοσιεύουν πληροφορία για εταιρίες, υπηρεσίες, υλοποιήσεις ή είδη υπηρεσιών στον κατάλογο UDDI. Το UDDI 41

43 δεν καθορίζει κάποια μέθοδο πιστοποίησης, εκτός από την απαίτηση για ύπαρξη κουπονιού πιστοποίησης (authorization token), και τη χρήση του πρωτοκόλλου HTTPS κατά τις διαδικασίες πιστοποίησης. Έτσι ο κάθε διαχειριστής θα πρέπει να έχει το δικό του μηχανισμό πιστοποίησης. Η αντίστοιχη προγραμματιστική διεπαφή ερωτήσεων, αποτελείται από ένα σύνολο από λειτουργίες οι οποίες δεν απαιτούν πιστοποίηση και επιτρέπουν στους χρήστες να λαμβάνουν τις πληροφορίες που αναζητούν από τον κατάλογο UDDI. Τα ερωτήματα μπορούν να γίνονται με βάση δύο γενικά σχήματα: ένα σχήμα με τη χρήση επόπτη διαδικτύου (browser) για την εύρεση γενικών πληροφοριών, το οποίο και συνήθως ακολουθείται από ένα σχήμα αναζήτησης σε βάθος, με βάση το οποίο αναζητούνται συγκεκριμένες λεπτομερείς πληροφορίες. Το UDDI παρέχει 4 λειτουργίες αποθήκευσης (save_business, save_service, save_binding και save_tmodel), 4 λειτουργίες διαγραφής (delete_business, delete_service, delete_binding και delete_tmodel), 4 λειτουργίες αναζήτησης (find_business, find_service, find_binding και find_tmodel), και 4 λειτουργίες αναζήτησης λεπτομερειών (get_businessdetail, get_servicedetail, get_bindingdetail και get_tmodeldetail), για κάθε ένα από τους 4 τύπους δομών (businessentity, businessservice, bindingtemplate και tmodel) αντίστοιχα (Πίνακας). Οι λειτουργίες αποθήκευσης μπορούν να χρησιμοποιηθούν για τη δημιουργία μιας καινούριας εγγραφής αλλά και για τη διόρθωση μιας υπάρχουσας. Κατά τη δημιουργία μιας καινούριας εγγραφής, η αναγνωριστική παράμετρος (κλειδί της εγγραφής) δεν καταχωρείται, αλλά εκχωρείται από το διαχειριστή και επιστρέφεται κατά την απάντηση του διαχειριστή. Για την ενημέρωση μιας εγγραφής όμως χρειάζεται και η εισαγωγή του κλειδιού αυτού. Οι λειτουργίες διαγραφής δέχονται τα κλειδιά που εκχώρησαν οι διαχειριστές σαν παραμέτρους, και διαγράφουν τις αντίστοιχες εγγραφές από τον κατάλογο. Ειδική περίπτωση διαγραφής αποτελεί η λειτουργία delete_tmodel. Όταν ένας αυθεντικοποιημένος χρήστης, 42

44 χρησιμοποιήσει την παραπάνω λειτουργία για την διαγραφή ενός tmodel, αυτό δεν διαγράφεται φυσικά από τον κατάλογο, αλλά σημειώνεται ως κρυφό. Με τον τρόπο αυτό, είναι ακόμα διαθέσιμο στον αυθεντικοποιημένο χρήστη, αλλά δεν επιστρέφεται ως αποτέλεσμα από τις λειτουργίες αναζήτησης.ο χρήστης, μπορεί να επανεισάγει το tmodel, χρησιμοποιώντας τη λειτουργία save_tmodel περνώντας ως παράμετρο το κλειδί του αρχικού tmodel. Οι λειτουργίες αναζήτησης δέχονται ένα σύνολο από κριτήρια σαν είσοδο, και το αποτέλεσμά τους συνήθως είναι μια δομή λίστας η οποία περιέχει τις εγγραφές που ικανοποιούν τα κριτήρια που είχαν τεθεί. Οι λειτουργίες αναζήτησης λεπτομερειών δέχονται μια λίστα από κωδικούς αναγνώρισης και επιστρέφουν λεπτομερείς πληροφορίες σχετικά με τις καταχωρήσεις που αντιστοιχούν στους κωδικούς της εισόδου. Η προγραμματιστική διεπαφή, παρέχει και μια επιπρόσθετη λειτουργία αναζήτησης λεπτομερειών, την get_businessdetailext, η οποία χρησιμοποιείται για την ανάκτηση εκτεταμένων πληροφοριών για εταιρίες από κόμβους μη διαχειριστών, που διατηρούν αυτές τις πρόσθετες πληροφορίες.επιπλέον, επειδή η προγραμματιστική διεπαφή δημοσίευσης είναι ένα σύνολο από πιστοποιημένες λειτουργίες, όπου η αναγνώριση ενός χρήστη βασίζεται στη χρήση κουπονιών, η διεπαφή αυτη παρέχει και δυο λειτουργίες πιστοποίησης, τις get_authtoken και discard_authtoken. Τέλος, η λειτουργία getregisteredinfo, είναι μια λειτουργία αυθεντικοποίησης, η οποία και επιστρέφει όλα τα κλειδιά businessentity και tmodel, που έχουν καταχωρηθεί από έναν εξουσιοδοτημένο χρήστη. Κλείνοντας την αναφορά στην προγραμματιστική διεπαφή του UDDI, θα πρέπει να τονιστεί, ότι όλες σχεδόν οι λειτουργίες των προγραμματιστικών διεπαφών δημοσίευσης και ερώτησης είναι δυνατόν να πραγματοποιηθούν και από τις ιστοσελίδες των μεμονωμένων διαχειριστών. Η προγραμματιστική διεπαφή όμως, εκτός από του ότι είναι και πολύ πιο πλήρης από το σύστημα αλληλεπίδρασης ενός επόπτη διαδικτύου, παρέχει επίσης τη δυνατότητα στις επιχειρήσεις να εκτελούν όλες τις λειτουργίες προγραμματιστικά, βοηθώντας στην δυναμική (κατά το χρόνο εκτέλεσης) ανεύρεση υπηρεσιών. 43

45 5 SOAP 5.1 Ορισμός και σκοπός του SOAP Το W3C από τον Ιούνιο του 2003 έχει συντάξει µία σύσταση (recommendation) η οποία είναι ό,τι πιο κοντινό υπάρχει στην προδιαγραφή (specification) του Simple Object Access Protocol ν1.2. Μέσα στη σύσταση αυτή βρίσκεται ο παρακάτω ορισµός : "Το SOAP στηv έκδοση 1.2 είvαι έvα ελαφρύ πρωτόκολλο προορισµέvο για τηv αvταλλαγή δοµηµέvωv πληροφοριώv σε έvα αποκεvτρωµέvο, διαvεµηµέvο περιβάλλον. Χρησιµοποιεί Tεχvoλoγίες ΧΜL για να καθορίσει έvα επεκτάσιµο πλαίσιο παρέxovτας µια δοµή µηνυµάτωv η οποία µπορεί να αvταλλαxθεί πάvω από ποικίλα δικτυακά πρωτόκολλα. Το πλαίσιο έχει σχεδιασθεί να είvαι αvεξάρτητο από οποιοδήποτε πρoγραµµατιστικό µovτέλo και σηµασιολογία υλοποίησης. " Δύο βασικοί στόχοι του σχεδιασµού του SOAP είναι η απλότητα και η επεκτασιµότητα. Το SOAP προσπαθεί να πετύχει αυτούς τους στόχους παραλείποντας, από το πλαίσιο µηνυµάτων, χαρακτηριστικά γνωρίσµατα τα οποία συνήθως συναντούνται σε κατανεµηµένα συστήµατα. Μερικά από αυτά τα γνωρίσµατα είναι η «αξιοπιστία» (relίabίlίty),η «ασφάλεια» (security), ο «συσχετιµός» (cοrrelatίοn),η «δροµολόγηση» (routing) και τα «σχέδια ανταλλαγής µηνυµάτων» (Message Exchange Patterns MPEs). Ενώ αναµένεται ότι πολλά χαρακτηριστικά θα καθοριστούν, η παρούσα προδιαγραφή παρέχει τις λεπτοµέρειες µόνο για δύο MEPs : το ΗΤΤΡ και το SMTP. Τα υπόλοιπα χαρκατηριστικά γνωρίσµατα αφήνονται να καθοριστούν από άλλες προδιαγραφές. Με πιο απλά λόγια το SOAP είναι ένα πρωτόκολλο βασισµένο στην ΧΜL το οποίο επιτρέπει στις εφαρµογές να ανταλλάσουν πληροφορία πάνω από κοινώς χρησιµοποιούµενα πρωτόκολλα του διαδικτύου. 5.2 SOAP και άλλα πρωτόκολλα ανταλλαγής µηνυµάτων Πριν ανακαλυφθεί το SOAP είχαµε και άλλες κατανεµηµένες τεχνολογίες τόσο για ανταλλαγή µηνυµάτων όσο και για αποµακρυσµένη κλήση διαδικασιών (remote procedure call). Για να καταλάβουµε καλύτερα τα πλεονεκτήµατα του SOAP καλό θα ήταν να εξετάσουµε, έστω και επιφανειακά, αυτές τις τεχνολογίες ώστε να 44

46 καταλάβουµε τα πλεονεκτήµατα και κύριως τα µειονεκτήµατα της κάθε µίας τα οποία και µας οδήγησαν στη δηµιουργία αυτού του πρωτοκόλλου EDI Το κυριότερο πρωτόκολλο ανταλλαγής µηνυµάτων στον χώρο των επιχειρήσεων ήταν και είναι ακόµη το Electronic Data Interchange (EDI) το οποίο όµως δε χρησιµοποιεί το διαδίκτυο αλλά ιδωτικά δίκτυα γεγονός που το καθιστά µια ακριβή τεχνολογία από άποψη υποδοµής. Τώρα πλέον είναι πολύ φθηνότερο να δηµιουργήσουµε ιδεατά ιδιωτικά δίκτυα (Virtual Private Networks - VPNs) πάνω από το διαδίκτυο για να ανταλλάσουµε µηνύµατα EDI. Ένα ακόµη µειονέκτηµα του EDI είναι ότι η µορφή των µηνυµάτων του είναι πολύ ειδική για κάθε βιοµηχανία οπότε δεν είναι τόσο ευέλικτο όσο το SOAP. Το EDI θεωρείται µια δύσκολη και αρκετά ακριβή τεχνολογία για να την υλοποιήσει µια επιχείρηση Επικοινωνούντα αντικείμενα Οι πιο σηµαντικές σηµαντικές τεχνολογίες, που δε βασίζονται στην ΧΜL, για το πέρασµα µηνυµάτων και για αποµακρυσµένη κλήση διαδικασίας (remote procedure call) είναι οι CORBA και DCOM. Μερικοί σηµαντικοί όροι που αφορούν και τις δύο τεχνολογίες είναι οι παρακάτω: Interface Defίnition Language (IDL) : Η γλώσσα που χρησιµοποιείται για να καθορίσει την διεπαφή που ένα αντικείµενο χρησιµοποιεί για την επικοινωνία µε τον έξω κόσµο. Marshalling ή Serializing : Η διαδικασία µετατροπής της δοµής ενός αντικειµένου ενός προγράµµατος σε ένα ρεύµα από ψηφιολέξεις (bytes). Unmarshalling ή Deserializing : Η διαδικασία µετατροπής ενός ρεύµατος από ψηφιολέξεις στην αρχική δοµή του αντικειµένου. Encoding : Η µετατροπή των δεδοµένων σε µία µορφή η οποία µπορεί να µεταφερθεί από ένα συγκεκριµένο πρωτόκολλο. Για παράδειγµα, για να περιλάβουµε τα δυαδικά δεδοµένα που σχηµατίζουν µία εικόνα σε ένα µήνυµα ΧΜL, τα bytes πρέπει να κωδικοποιηθούν σαν χαρακτήρες συµβατοί µε τις ετικέτες της XML. 45

47 CORBA Μία πρωτοποριακή προσπάθεια για να έχουµε αξιόπιστη επικοινωνία αντικειµένων µεταξύ διαφορετικών συστηµάτων ήταν το Common Object Request Broker Architecture (CORBA). Το Object Management Group (OMG) ήθελε να δηµιουργήσει ένα πρωτόκολλο ικανό να παρέχει επικοινωνία µεταξύ αντικειµένων σε εντελώς διαφορετικά λειτουργικά συστήµατα και γραµµένα σε διαφορετικές γλώσσες προγραµµατισµού. Ένα Object Request Broker (ORB) παρέχει τη αναγκαία διεπαφή ώστε ένα πρόγραµµα-πελάτης να µιλήσει µε αποµακρυσµένα αντικείµενα. Λόγω του ότι η αρχική προδιαγραφή του CORBA δηµοσιεύτηκε το 1992, είχε αρκετό καιρό για βελτίωση σε σχέση µε άλλες τεχνολογίες. Πολλοί µεγάλοι προµηθευτές λογισµικού έχουν δηµιουργήσει προϊόντα για αυτή την τεχνολογία. Το CORBA θεωρείται µια δύσκολη κατανεµηµένη τεχνολογία. Το OMG δηµιούργησε µια πρότυπη γλώσσα την Interface Description Language (IDL) η οποία επιτρέπει τον καθορισµό της διεπαφής ενός αντικειµένου σε µία µορφή ανεξάρτητη από γλώσσα προγραµµατισµού. Το OMG δηµιούργησε επίσης και ένα πρωτόκολλο το Internet Inter-ORB Protocol (IIOP) για επικοινωνία µέσω µηνυµάτων πάνω από το Internet. Το OMG τώρα εργάζεται για τη δηµιουργία ενός προτύπου διεπαφής µεταξύ SOAP και CORBA COM και DCOM Το Common Object Model (COM) είναι µια προδιαγραφή της Microsoft για ενοποίηση συστατικών (components integration) µέσα σε µια εφαρµογή. Η επικοινωνία είναι χαµηλού επιπέδου και επιτρέπει συστατικά γραµµένα σε διαφορετικές γλώσσες προγραµµατισµού να αλληλεπιδρούν. Το Distributed COM (DCOM) είναι µια πιο πρόσφατη προσπάθεια που επιτρέπει συστατικά να αλληλεπιδρούν πάνω από ένα δίκτυο. Η µορφή επικοινωνίας είναι ουσιαστικά µια κλήση αποµακρυσµένης διαδικασίας. Τα COM και DCOM θεωρούνται ώριµες τεχνολογίες και παρότι οι κύριοι χρήστες του DCOM είναι Microsoft Windows συστήµατα, θα µπορούσε να επεκταθεί και σε άλλα λειτουργικά συστήµατα. 46

48 Απόδοση του SOAP (CORBA DCOM) Τα πρωτόκολλα CORBA και DCOM χρησιμοποιούν δυαδική κωδικοποίηση (binary encoding) για τα μηνύματα που ανταλλάσσουν και θεωρούν δεδομένη την συμφωνία των δυο επικοινωνούντων κόμβων ως προς συμβάσεις σχετικά με το νόημα των δεδομένων που ανταλλάσσονται. Αντίθετα το SOAP χρησιμοποιεί κωδικοποίηση XML στα μηνύματα του για να προσδώσει νόημα στα ανταλλασσόμενα δεδομένα. Το γεγονός αυτό το καθιστά εύκολο στην διαχείριση, διαλειτουργικό και επεκτάσιμο, ωστόσο υστερεί κάπως σε επιδόσεις, συγκριτικά με τα COBRA/DCOM. Οι τυπικές επιδόσεις που έχουν μετρηθεί για το πρωτόκολλο SOAP είναι 500 μηνύματα/sec όταν είναι σε διαφορετικά μηχανήματα. Το μεγάλο πλεονέκτημα της συμβατότητας του SOAP φαίνεται στα παρακάτω σχήματα. 47

49 Όπως φαίνεται από τα παραπάνω σχήματα, το μεγάλο πλεονέκτημα του SOAP και των Web Services είναι ότι μπορούν να διασυνδέουν συστήματα που χρησιμοποιούν διαφορετικά middleware σε μια ενιαία πλατφόρμα επικοινωνίας. Η πλατφόρμα αυτή είναι ανεξάρτητη από το λογισμικό που τρέχει σε κάθε ένα σύστημα. Η συμβατότητα είναι ένα πολύ σημαντικό χαρακτηριστικό του SOAP. Οι υπάρχουσες υποδομές σε middleware δεν είναι απαραίτητο να καταργηθούν RMI Η πιο απλή µορφή επικοινωνίας στη Java µεταξύ αντικειµένων σε κατανεµηµένα συστήµατα παρέχεται από το Remote Method Invocation (RMI). Το RMI επιτρέπει στους προγραµµατιστές να χειριστούν, ένα αποµακρυσµένο αντικείµενο σαν να βρίσκεται µέσα στην τοπική εφαρµογή. Αυτό που πρέπει να κάνει ο προγραµµατιστής είναι να καθορίσει τη δηµόσια διεπαφή που πρόκειται να εκτεθεί για ένα αντικείµενο. Με το βοηθητικό πρόγραµµα rmic εξετάζει τη διεπαφή και δηµιουργεί κλάσεις γνωστές ως stub και skeleton. Στην πλευρά του διακοµιστή η εφαρµογή δηλώνει τη διεπαφή στο rmiregistry και περιµένει νέες συνδέσεις. Μια εφαρµογή-πελάτης χρησιµοποιεί το rmiregistry το οποίο «ζει» στο δίκτυο σε µία πρότυπη πόρτα, για να λάβει ένα στιγµιότυπο της stub κλάσης η οποία υλοποιεί την επιθυµητή διεπαφή. Οι κλήσεις που γίνονται στο στιγµιότυπο της stub κλάσης συµπεριφέρονται σαν να βρίσκεται το αποµαρκυσµένο αντικείµενο στην τοπική Java Virtual Machine. Τις λεπτροµέρειες του serialίzing και deserializing των αντικειµένων, και της επικοινωνίας µεταξύ των συστηµάτων τις χειρίζονται οι κλάσεις stub και skeleton. Το πιο προφανές πλεονέκτηµα του RMI είναι η ευκολία χρήσης και η απόλυτη συµβατότητα των τύπων δεδοµένων. Για τους προγραµµατιστές, όλες τις λεπτοµέρειες του serialization και deserialization τις αναλαµβάνουν οι κλάσεις του RMI. Από τη στιγµή που ένα αντικείµενο είναι serializable, µπορεί να χρησιµοποιηθεί σε µια αποµακρυσµένη κλήση µεθόδου. Για αυτούς τους λόγους το RMI είναι η ουσιαστική τεχνολογία για κατανεµηµένες εφαρµογές σε Java. Παρόλα αυτά, το RMI έχει και µειονεκτήµατα. Φυσικά.µπορεί να χρησιµοποιηθεί µόνο µεταξύ εφαρµογών Java. Επίσης, και οι δύο πλευρές πρέπει να έχουν πρόσβαση στις κλάσεις της διεπαφής. Ακόµη ένα µειονέκτηµα είναι ότι οι πόρτες (ports) που χρησιµοποιούνται συνήθως µπλοκάρονται από firewalls και proxy servers. Για αυτούς τους λόγους τo RMI είναι περισσότερο επιτυχηµένο στα τοπικά δίκτυα (intranets). 48

50 Για τη πλατφόρµα της Java 2, η Sun δηµιούργησε εργαλεία ικανά να γεφυρώσουν το κενό ανάµεσα σε αντικείµενα RMI και αντικείµενα CORBA γραµµένα σε άλλες γλώσσες προγραµµατισµού. Αυτό το πακέτο ονοµάζεται RMI- IIOP και αν πρέπει να επικοινωνήσουµε µε αποµακρυσµένα αντικείµενα σε παλαιά συστήµατα αυτή η επλογή είναι η πιο κατάλληλη XML - RPC Το πρωτόκολλο XML-RPC δηµιουργήθηκε από τον Dave Winer της UserLand το 1998 και είναι ο πρόδροµος του πρωτοκόλλου SOAP. Το XML-RPC εκτελεί αποµακρυσµένες κλήσεις διαδικασίας µέσω µιας αίτησης HTTP POST µε κωδικοποίηση ΧΜL. Χρησιµοποιώντας το ευρέως υποστηριζόµενο πρωτόκολλο HTTP κάνει δυνατή την προσθήκη επεξεργασίας του XML-RPC σε κάθε εξυπηρετητή ιστού που υποστηρίζει CGI (Common Gateway Interface ) Επίσης χρησιµοποιώντας αυτό το πρότυπο πρωτόκολλο επιτρέπει το πέρασµα των τυχών προστασίας, κάνοντας εύκολη την εγκατάσταση ενός εξυπηρετητή XML-RPC χωρίς συµβιβασµούς στην ασφάλεια. Το XML-RPC είναι πολύ πιο απλό από το SOAP αλλά δεν έχει και τόσες δυνατότητες όσες το SOAP. Υποστηρίζει βασικούς τύπους δεδοµένων αλλά και σύνθετους (µέσω των τύπων <struct> και <array> ). Η πρώτη προσπάθεια για τη δηµιουργία του SOAP (έκδοση 1.1) είχε σαν βάση της αυτό το πρωτόκολλο. 49

51 5.3 Τι προσφέρει το SOAP Αν εξετάσουµε τις παραπάνω τεχνολογίες θα δούµε ότι σε κάθε περίπτωση έχουµε κάποια από τα παρακάτω µειονεκτήµατα: Κόστος υποδοµής (ΕDΙ, CORBA) Κόστος και πολυπλοκότητα υλοποίησης (ΕDΙ, CORBA) Χρήση µόνο σε ιδιωτικά δίκτυα (ΕDΙ, CORBA, DCOM, RMI) Χρήση µόνο σε εφαρµογές που εκτελούνται στην ίδια πλατφόρµα (DCOM) Χρήση µόνο σε εφαρµογές γραµµένες στην ίδια γλώσσα προγραµµατισµού (RMI) Μειωµένες λειτουργίες (XML-RPC) Έλειψη ευελιξίας (ΕDΙ, CORBA, DCOM, RMI) Στην προσπάθεια δηµιουργίας του SOAP λήφθηκαν υπόψιν όλα τα παραπάνω και δηµιουργήθηκε ένα πρωτόκολλο µε τα εξής χαρακτηριστικά : Το SOAP είναι απλό. Άρα το κόστος και η πολυπλοκότητα υλοποίησης µειώνονται αισθητά. Το SOAP είναι ανεξάρτητο από πλατφόρµα και γλώσσα προγραµµατισµού οπότε µπορεί να χρησιµοποιηθεί για επικοινωνία µεταξύ εφαρµογών γραµµένων για διαφορετικές πλατφόρµες και σε διαφορετικές γλώσσες προγραµµατισµού. Το SOAP είναι ευέλικτο. Χρησιµοποιεί πρότυπα πρωτόκολλα όπως το ΗΤΤΡ και το SMTP ως µέσα µεταφορας οπότε µπορεί να χρησιµοποιηθεί στο διαδίκτυο και να διαπερνά τύχη προστασίας χωρίς συµβιβασµούς στην ασφάλεια της υποδοµής µιας επιχείρησης. Αυτό αυτομάτως µειώνει και σε ορισµένες περιπτώσεις εξαλήφει το κόστος υποδοµής αφού οι περισσότερες επιχειρήσεις σήµερα έχουν και τον εξοπλισµό και την τεχνογνωσία για τη χρήση του διαδικτύου. Το SOAP είναι επεκτάσιµο. Αν και δεν προσφέρει τόσες πολλές λειτουργίες όσο άλλες τεχνολογίες όπως το CORBA και το DCOM επιτρέπει σε αλλα πρότυπα να το επεκτείνουν παρέχοντας υπηρεσίες που λείπουν από αυτό. Αυτό το χαρακτηριστικό αποδείχθηκε ίσως το σηµαντικότερο γιατί επάνω του βασίζονται πολλές αναπτυσσόµενες τεχνολογίες των web services που προσφέρουν υπηρεσίες όπως «αξιοπιστία» (reliability), «δροµολόγηση» (routing) και «σφάλεια» (security). 50

52 5.4 Δοµή ενός µηνύµατος SOAP Ένα µήνυµα SOAP είναι ένα συνηθισµένο έγγραφο ΧΜL το οποίο περιέχει τα παρακάτω στοιχεία (elements) : Ένα απαιτούµενο στοιχείο Envelope από το οποίο αναγνωρίζεται το έγγραφο ΧΜL ως µήνυµα SOAP. Ένα προαιρετικό στοιχείο Header που περιλαµβάνει βοηθητικές πληροφορίες. Ένα απαιτούµενο στοιχείο Body το οποίο περιλαµβάνει την κύρια πληροφορία του µηνύµατος. Ένα προαιρετικό στοιχείο Fault το οποίο παρέχει πληροφορίες για σφάλµατα που προκλήθηκαν κατά την επεξεργασία ενός µηνύµατος. Μερικοί σηµαντικοί κανόνες σύνταξης είναι οι παρακάτω : 1. Ένα µήνυµα SOAP ΠΡΕΠΕΙ να είναι κωδικοποιηµένο χρησιµοποιώντας XML. 2. Ένα µήνυµα SOAP ΠΡΕΠΕΙ να χρησιµοποιεί το SOAP Envelope namespace. 3. Ένα µήνυµα SOAP ΠΡΕΠΕΙ να χρησιµοποιεί το SOAP Encoding namespace. 4. Ένα µήνυµα SOAP ΔΕΝ ΠΡΕΠΕΙ να περιέχει αναφορά σε DTD. 5. Ένα µήνυµα SOAP ΔΕΝ ΠΡΕΠΕΙ να περιέχει ΧΜL Processing Instructions. Σχηματικά ο σκελετός ενός μηνύματος SOAP θα μπορούσε να παρασταθεί ως εξής : 51

53 Δομή ενός μηνύματος SOAP. Όταν το μήνυμα SOAP περιέχει το στοιχείο Fault, σχηματικά είναι ως εξής : Δομή ενός μηνύματος SOAP με Fault. 52

54 5.5 SOAP Envelope Το SOAP Envelope είναι το στοιχείο που περικλείει όλα τα υπόλοιπα στοιχεία σε ένα µήνυµα SOAP. Η ύπαρξη του ως αρχικού στοιχείου (root element) ενός εγγράφου ΧΜL σηµατοδοτεί ότι πρόκειται για µήνυµα SOAP. Για το SOAP Εnvelope είναι απαραίτητα τα εξής: Το όνοµα του στοιχείου πρέπει να είναι Envelope. Το όνοµα του namespace του να είναι Να περιέχει µηδέν ή περισσότερες ιδιότητες ορισµένες µε namespace. Να περιέχει ένα ή δύο στοιχεία-παιδιά µε την εξής σειρά : ο Ένα προαιρετικό στοιχείο Header ο Ένα απαραίτητο στοιχείο Body 5.6 SOAP - «ειδικές» ιδιότητες ΧΜL (ΧΜL attributes) Οι παρακάτω ιδιότητες ΧΜL έχουν ειδικό νόηµα για την επεξεργασία ενός µηνύµατος SOAP : encodingstyle: υπoδεικvύει τους κανόνες κωδικοποίησης που χρησιµοποιούνται για το serialίzation των διάφορων τµηµάτων ενός µηνύµατος SOAP. role: χρησιµοποιείται για να υποδείξει τον κόµβο επεξεργασίας (SOAP node) για τον οποίο προορίζεται το SOAP header block. mustunderstand: χρησιµοποιείται για να υποδείξει ότι η επεξεργασία ενός SOAP header block είναι υποχρεωτική ή προαιρετική. relay: χρησιµοποιείται για να υποδείξει αν το SOAP header block που προορίζεται για ένα κόµβο επεξεργασίας πρέπει να αναµεταδοθεί αν δεν υποστεί επεξεργασία. 5.7 SOAP Header Το SOAP Header παρέχει ένα µηχανισµό για επέκταση ενός µηνύµατος SOAP µε ένα αποκεντρωµένο και δοµηµένο τρόπο. 53

55 Για το SOAP Header είναι απαραίτητα τα εξής: Το όνοµα του στοιχείου πρέπει να είναι Header. Το όνοµα του namespace του να είναι '' Μπορεί να περιέχει µηδέν ή περισσότερες ιδιότητες ορισµένες µε namespace. Μπορεί να περιέχει µηδέν ή περισσότερα στοιχεία-παιδιά ορισµένα µε namespace. Κάθε στοιχείο-παιδί του SOAP header ονοµάζεται SOAP header block SOAP header block Για κάθε SOAP header block είναι απαραίτητα τα εξής: Το όνοµα του στοιχείου πρέπει να είναι ορισµένο µε namespace. Μπορεί να περιέχει µηδέν ή περισσότερους κόµβους-παιδιά χαρακτήρων. Μπορεί να περιέχει µηδέν ή περισσότερα στοιχεία-παιδιά τα οποία µπορεί να είναι ορισµένα µε namespace. Μπορεί να περιέχει µηδέν ή περισσότερες ιδιότητες. Ανάµεσα σε αυτές µπορεί να υπάρχουν κάποιες ή όλες από τις παρακάτω που έχουν ιδιαίτερο νόηµα για την επεξεργασία του µηνύµατος SOAP. ο Η ιδιότητα encodingstyle. ο Η ιδιότητα role. ο Η ιδιότητα mustunderstand ο Η ιδιότητα relay. 5.8 SOAP Body Το SOAP Body παρέχει ένα µηχανισµό για µετάδοση πληροφοριών στον τελικό αποδέκτη ενός µηνύµατος SOAP. Για το SOAP Body είναι απαραίτητα τα εξής: Το όνοµα του στοιχείου πρέπει να είναι Body. Το όνοµα του namespace του να είναι '' Μπορεί να περιέχει µηδέν ή περισσότερες ιδιότητες ορισµένες µε namespace. 54

56 Μπορεί να περιέχει µηδέν ή περισσότερα στοιχεία-παιδιά ορισµένα µε namespace. Μπορεί να περιέχει µηδέν ή περισσότερους κόµβους-παιδιά χαρακτήρων. Κάθε στοιχείο-παιδί του SOAP Body ονοµάζεται SOAP Body child Element SOAP Body child Element Για κάθε στοιχείο-παιδί του SOAP Body είναι απαραίτητα τα εξής: Το όνοµα του στοιχείου καλό θα ήταν να είναι ορισµένο µε namespace. Μπορεί να περιέχει µηδέν ή περισσότερους κόµβους-παιδιά χαρακτήρων. Μπορεί να περιέχει µηδέν ή περισσότερα στοιχεία-παιδιά τα οποία µπορεί να είναι ορισµένα µε namespace. Μπορεί να περιέχει µηδέν ή περισσότερες ιδιότητες. Ανάµεσα σε αυτές µπορεί να υπάρχει η παρακάτω που έχει ιδιαίτερο νόηµα για την επεξεργασία του µηνύµατος SOAP: ο Η ιδιότητα encodingstyle. 5.9 SOAP Fault Το SOAP Fault χρησιµοποιείται για να κουβαλάει πληροφορίες σφαλµάτων µέσα σε ένα µήνυµα SOAP. Για το SOAP Fault είναι απαραίτητα τα εξής: Το όνοµα του στοιχείου πρέπει να είναι Fault. Το όνοµα του namespace του να είναι '' Πρέπει να περιέχει δύο ή περισσότερα στοιχεία-παιδιά µε την παρακάτω σειρά: ο Ένα υποχρεωτικό στοιχείο Code. ο Ένα υποχρεωτικό στοιχείο Reason. ο Ένα προαιρετικό στοιχείο Node. ο Ένα προαιρετικό στοιχείο Role. ο Ένα προαιρετικό στοιχείο Detail. 55

57 Για να αναγνωριστεί ότι ένα µήνυµα SOAP κουβαλάει πληροφορίες σφάλµατος πρέπει να περιέχει ένα στοιχείο Fault σαν το µοναδικό στοιχείο-παιδί του SOAP Body Στοιχείο SOAP Code Για το στοιχείο SOAP Code ισχύουν τα παρακάτω: Το όνομα του στοιχείου πρέπει να είναι Code. Το όνομα του namespace του να είναι '' Πρέπει να περιέχει ένα ή και τα δύο από τα στοιχεία-παιδιά με την παρακάτω σειρά: ο Ένα υποχρεωτικό στοιχείο Value. ο Ένα υποχρεωτικό στοιχείο Subcode Στοιχείο SOAP Value (με πατέρα το στοιχείο Code) Για το στοιχείο SOAP Code ισχύουν τα παρακάτω : Το όνομα του στοιχείου πρέπει να είναι Code. Το όνομα του namespace του να είναι '' Ο τύπος αυτού του στοιχείου είναι env:faultcodeenum. Το SOAP καθορίζει ένα μικρό σύνολο από πιθανές τιμές Kαλύπτωvτας σφάλματα SOAP υψηλού επιπέδου. 56

58 Οι τιμές που ορίζει το SOAP είναι οι εξής: Όνομα VersionMismatch MustUnderstand DataEncodingUnknow n Sender Receiver Νόημα Βρέθηκε λάθος στοιχείο στη θέση του στοιχείου Envelope. Το όνομα, το namespace ή και τα δύο δεν ταιριάζουν με αυτά του προτύπου για το στοιχείο Envelope. Υπάρχει SOAP header block με τιμή "true" στην ιδιότητα mustunderstand του που όμως ο κόμβος δεν μπορεί να επεξεργαστεί. Ένα SOAP header block ή ένα SOAP body child που προοριζόταν για αυτόν τον κόμβο είχε κωδικοποίηση δεδομένων που δεν υποστηρίζει ο κόμβος. Το μήνυμα δεν ήταν σωστά δομημένο ή δεν περιείχε τη σωστή πληροφορία για να επιτύχει η επεξεργασία του. Για παράδειγμα, το μήνυμα θα μπορούσε να μην περιείχε πληροφορίες αυθεvτιkoπoίησης ή Είναι ενδεικτικό. ότι το μήνυμα δεν μπορεί να ξανασταλεί χωρίς αλλαγές. Δεν µπόρεσε να γίνει η επεξεργασία του µηνύµατος για λόγους που είχαν να κάνουν µε την ίδια τη διαδικασία παρά µε τα περιεχόµενα του µηνύµατος. Για παράδειγµα η επεξεργασία θα µπορούσε να περιέχει επικοινωνία µε άλλο κόµβο η οποία να µην πέτυχε. Το µήνυµα θα µπορούσε να επιτύχει αν αποστελόταν κάποια στιγµή Στοιχείο SOAP Subcode (µε πατέρα το στοιχείο Code) Για το στοιχείο SOAP Subcode ισχύουν τα παρακάτω: Το όνοµα του στοιχείου πρέπει να είναι Subcode. Το όνοµα του namespace του να είναι '' Πρέπει να περιέχει ένα ή και τα δύο από τα στοιχεία-παιδιά µε την παρακάτω σειρά: ο Ένα υποχρεωτικό στοιχείο Value. ο Ένα υποχρεωτικό στοιχείο Subcode (ανδροµικά). 57

59 Στοιχείο SOAP Value (με πατέρα το στοιχείο Subcode) Για αυτό το στοιχείο ισχύουν τα παρακάτω : Το όνοµα του στοιχείου πρέπει να είναι Value. Το όνοµα του namespace του να είναι '' Ο τύπος αυτού του στοιχείου είναι xs:qname. Η τιµή αυτού του στοιχείου είναι µια υποκατηγορία της τιµής του στοιχείου Value µε πατέρα το στοιχείο Subcode. Η τιµή αυτή καθορίζεται από την ίδια την εφαρµογή κάθε φορά Στοιχείο SOAP Reason Το οτοιχείο Reason προορίζεται για να παρέχει μία εξήγηση του σφάλματος κατανοήσιμη από τον άνθρωπο. Για αυτό το οτοιχείο ισχύουν τα παρακάτω: Το όνομα του οτοιχείου πρέπει να είναι Reason. Το όνομα του namespace του να είναι '' Πρέπει να περιέχει ένα ή περισσότερα οτοιχεία-παιδιά Text. κάθε οτοιχείο Text θα ήταν καλό να περιέχει διαφορετική τιμή για κάθε γλώσσα Στοιχείο SOAP Text Το οτοιχείο Text προορίζεται να κουβαλάει το κείμενο της εξήγησης σφάλματος. Για αυτό το οτοιχείο ισχύουν τα παρακάτω: Το όνομα του οτοιχείου πρέπει να είναι Text. Το όνομα του namespace του να είναι '' Πρέπει να περιέχει υποχρεωτικά μία ιδιότητα με όνομα lang και namespace '' Σημειωτέον ότι ο ορισμός της ιδιότητας lang απαιτεί το πρόθεμα xml (ανεξαρτήτα από κεφαλαία- πεζά). Οποιοδήποτε αριθμό χαρακτήρων. 58

60 Αυτό το στοιχείο θα πρέπει να περιέχει πληροφορία που εξηγεί τη φύση του σφάλματος και δεν προορίζεται για αλγοριθμική επεξεργασία Στοιχείο SOAP Node Το στοιχείο Node προορίζεται να παρέχει πληροφορίες για το ποιός κόµβος επεξεργασίας SOAP προκάλεσε το σφάλµα. Για αυτό το στοιχείο ισχύουν τα παρακάτω: Το όνοµα του στοιχείου πρέπει να είναι Node. Το όνοµα του namespace του να είναι '' Ο τύπος αυτού του στοιχείου είναι xs:uri. Κάθε κόµβος επεξεργασίας αναγνωρίζεται από ένα URI. Η τιµή αυτού του στοιχείου είναι το URI του κόµβου επεξεργασίας στον οποίο προκλήθηκε το σφάλµα. Στην περίπτωση που το σφάλµα προκλήθηκε από την επεξεργασία του µηνύµατος σε έναν ενδιάµεσο κόµβο τότε ο κόµβος αυτός πρέπει οπωσδήποτε να περιλάβει στην απάντησή του αυτό το στοιχείο για να δηλώσει ότι το σφάλµα προκλήθηκε σε αυτόν. Αν πρόκειται για τον τελικό παραλήπτη του µηνύµατος τότε αυτός µπορεί προεραιτικά να περιλάβει αυτό το στοιχείο Στοιχείο SOAP Role Το στοιχείο Role υπoδεικvύει το ρόλο τον οποίο είχε ο κόµβος στον οποίο προκλήθηκε το σφάλµα. Για αυτό το στοιχείο ισχύουν τα παρακάτω: Το όνοµα του στοιχείου πρέπει να είναι Role. Το όνοµα του namespace του να είναι '' Το SOAP καθορίζει τρεις από αυτούς που έχουν ειδικό νόηµα και είναι οι εξής: 59

61 Όνοµα next Περιγραφή Κάθε ενδιάµεσος κόµβος ή ο τελικός παpαλήπτης πρέπει να δράσει. none κανένας κόµβος δεν πρέπει να δράσει. ultimatereceiver Ο τελικός παραλήπτης πρέπει να δράσει Στοιχείο SOAP DetaiI Το στοιχείο Detaίl προορίζεται για να κουβαλάει πληροφορίες για σφάλµατα που σχετίζονται µε το SOAP Body. Για αυτό το στοιχείο ισχύουν τα παρακάτω : Το όνοµα του στοιχείου πρέπει να είναι DetaiI. Το όνοµα του namespace του να είναι '' Μπορεί να περιέχει µηδέν ή περισσότερες ιδιότητες. Μπορεί να περιέχει µηδέν ή περισσότερα στοιχεία-παιδιά τα οποία µπορεί να είναι ορισµένα µε namespace. Το στοιχείο DetaiI µπορεί να περιέχει χαρακτήρες. Το στοιχείο Detaίl µπορεί να είναι παρόν σε ένα SOAP Fault και στην περίπτωση αυτή κουβαλάει επιπλέον πληροφορίες σχετικές µε τους κωδικούς σφάλµατος περιγράφοντας έτσι το σφάλµα. Για παράδειγµα, το στοιχείο Detail θα µπορούσε να περιέχει πληροφορίες σχετικές µε το ότι ένα µήνυµα δεν περιλαµβάνει κατάλληλα πιστοποιητικά. Η παρουσία του στοιχείου DetaiI δεν έχει καµία σηµασία στο ποια µέρη του µηνύµατος έχουν υποστεί επεξεργασία. Όλα τα στοιχεία-παιδιά αυτού του στοιχείου ονοµάζονται detail entries. 60

62 SOAP DetaiI Entry Για κάθε detaίl entry ισχύουν τα παρακάτω: Το όνοµα του στοιχείου µπορεί να είναι ορισµένο µε namespace. Μπορεί να περιέχει µηδέν ή περισσότερα στοιχεία-παιδιά. Μπορεί να περιέχει µηδέν ή περισσότερους κόµβους-παιδιά χαρακτήρων. Μπορεί να περιέχει µηδέν ή περισσότερες ιδιότητες. Ανάµεσα σε αυτές µπορεί να υπάρχει η παρακάτω που έχει ιδιαίτερο νόηµα για την επεξεργασία του µηνύµατος SOAP: ο Η ιδιότητα encodingstyie. Αν είναι παρούσα, η ιδιότητα encodingstyie υπoδεικvύει τον τρόπο κωδικοποίησης για αυτό το detail entry Μοντέλα ανταλλαγής μηνυμάτων Το SOAP είναι ένα απλό πλαίσιο μηνυμάτων για ανταλλαγή μηνυμάτων σε μορφή ΧΜL μεταξύ ενός αρχικού αποστολέα και ενός τελικού αποδέκτη. Τα πιο ενδιαφέροντα σενάρια περιλαμβάνουν πολλαπλές ανταλλαγές μηνυμάτων μεταξύ των δύο αυτών κόμβων. Η πιο απλή από αυτές τις περιπτώσεις είναι η μορφή αίτησηαπάντηση (request-response) Απομακρυσμένες κλήσεις διαδικασιών (RPC) Οι αρχικές χρήσεις του SOAP έδιναν έμφαση στο μοντέλο αίτησης-απάντησης για τη χρήση του σε απομακρυσμένες κλήσεις διαδικασίας που ήταν και ένας από τους στόχους κατά το σχεδιασμό του πρωτοκόλλου. Το SOAP έχει καθορίσει μία ομοιόμορφη αναπαράσταση μηνύματος γία κλήσεις RPC και απαντήσεις. 61

63 5.12 Συνοµιλητικές ανταλλαγές µηνυµάτων Ένα ακόµη µεγαλύτερο σύνολο από σενάρια χρήσης τα οποία µπορούν να καλυφθούν από το µοντέλο αίτησης-απάντησης µπορούν να µοντελοποιηθούν απλά σαν ανταλλαγή ολόκληρων εγγράφων ΧΜL µε τη µορφή µιας µπρος-πίσω «συνοµιλίας», όπου η σηµασιολογία εξαρτάται από τις ίδιες τις εφαρµογές. Αυτό το ενδεχόµενο µας δίνει πληρη ευελιξία για εφαρµογές web services αν και µέχρι στιγµής οι περισσότερες εφαρµογές web services βασίζονται σε σενάρια RPC, ίσως και λόγω του γεγονότος ότι οι προγραµµατιστές είναι πιο κοντά νοητικά σε αυτό το σενάριο Πλαίσιο Συνδέσεων Binding Framework Τα µηνύµατα SOAP µπορούν να ανταλλάσσονται χρησιµοποιώντας µια πληθώρα από πρωτόκολλα δικτύου συµπεριλαµβανοµένων και πρωτοκόλλων επιπέδου εφαρµογών (application layer protocols). Η προδιαγραφή για το πώς µηνύµατα SOAP µπορούν να περνιούνται από ένα κόµβο σε ένα άλλο χρησιµοποιώντας ένα πρωτόκολλο ονοµάζεται «σύνδεση SOAP» (SOAP binding) ΗΤΤΡ Binding Το ΗΤΤΡ έχει ένα ευρέως γνωστό µοντέλο σύνδεσης και µορφή ανταλλαγής µηνυµάτων. Ο πελάτης αναγνωρίζει τον εξυπηρετητή µέσω ενός URI, συνδέεται σε αυτόν χρησιµοποιώντας το TCP/IP, εκτελεί µία αίτηση ΗΤΤΡ και λαµβάνει µία απάντηση ΗΤΤΡ πάνω από την ίδια σύνδεση TCP. Το ΗΤΤΡ συνδέει το µήνυµα αίτησης µε το µήνυµα απάντησης. Για αυτό το λόγο µια εφαρµογή που χρησιµοποιεί αυτή τη σύνδεση µπορεί να επιλέξει να συνδέσει ένα µήνηµα SOAP που στάλθηκε στο σώµα µιας αίτησης ΗΤΤΡ µε ένα µήνυµα SOAP που επιστρέφηκε στο σώµα µιας απάντησης ΗΤΤΡ. Η απλότητα χρήσης του ΗΤΤΡ είναι και ο λόγος για τον οποίο είναι το πιο ευρέως χρησιµοποιούµενο πρωτόκολλο για την αποστολή µηνυµάτων SOAP. 62

64 5.15 Σύνοψη για το SOAP Από τα προαναφερθέντα γύρω από το πρωτόκολλο SOAP θα πρέπει να έχει ήδη γίνει αντιληπτό ότι οι σχεδιαστές του πέτυχαν τους στόχους τους. Το Simple Object Access Protocol είναι ένα απλό, ευέλικτο και επεκτάσιµο πρωτόκολλο ανταλλαγής µηνυµάτων σε µορφή ΧΜL και µπορεί να χρησιµοποιήσει άλλα πρότυπα πρωτόκολλα σα µέσα µεταφοράς. Ίσως το λιγότερο εµφανές σε όλα τα παραπάνω είναι η επεκτασιµότητά του η οποία όµως είναι το σηµαντικότερο πλεονέκτηµά του αφού πάνω σε αυτό το χαρακτηριστικό βασίζονται πολλές νέες τεχνολογίες των web serνices. 63

65 Κεφάλαιο Δημιουργία και υλοποίηση των Web Services Υπάρχουν αρκετές διαφορετικές πλατφόρμες στις οποίες μπορεί να βασιστεί κανείς για τη δημιουργία ενός web service. Από τη μεριά της Microsoft, οι έτοιμες λύσεις που δίνει το περιβάλλον Visual Studio.net έχουν προσελκύσει πολλούς προγραμματιστές για να δημιουργούν τέτοιες υπηρεσίες. Επίσης άλλες μεγάλες εταιρίες όπως η IBM και η ORACLE χρησιμοποιούν τα δικά τους προγραμματιστικά εργαλεία. Τέλος ακόμα και οι περισσότερες γλώσσες προγραμματισμού έχουν ενσωματώσει στις δυνατότητές τους την αυτόματη δημιουργία SOAP servers και την υποστήριξη των web services. Μία δωρεάν λύση προσφέρεται και στους προγραμματιστές δυναμικών ιστοσελίδων που χρησιμοποιούν την γλώσσα PHP. Υπάρχουν έτοιμες βιβλιοθήκες (π.χ. nusoap) που μπορούν να χρησιμοποιηθούν από οποιοδήποτε για να δημιουργήσει απλά προσθέτοντας μόνο πεντε γραμμές εντολών ένα web service. O Τομέας Ερευνητικών Προγραμμάτων της ALTEC, δημιούργησε την καινοτόμο πλατφόρμα σχεδιασμού και ανάπτυξης για Web services που φέρει το όνομα ONAR, κάνοντας χρήση τεχνολογιών του Semantic Web και state-of-the-art εργαλείων οντολογικής διαχείρισης. Η πλατφόρμα, εκτός από ένα σημαντικό βοήθημα για την ταχύτερη και τεχνολογικά προηγμένη υλοποίηση εφαρμογών over Internet, παρέχει τη δυνατότητα σε φορείς που διαθέτουν μία βασική υποδομή πληροφορικής και τεχνογνωσία (π.χ. Νομαρχίες, μεγάλες επιχειρήσεις και οργανισμούς κ.λ.π.), να οργανώσουν την μετάβαση τους στην Κοινωνία της Πληροφορίας. Επίσης, διάφορες πλατφόρμες έχουν υλοποιηθεί τα τελευταία χρόνια που εκτός της παροχής υπηρεσιών για την επεξεργασία σημασιολογικών δεδομένων, εξελίσσονται προς την κατεύθυνση της παροχής υπηρεσιών ενδιάμεσου λογισμικού. Οι υπηρεσίες αυτές προσφέρουν απομακρυσμένη και ελεγχόμενη πρόσβαση σε μία ή περισσότερες βάσεις δεδομένων εκ μέρους εφαρμογών-πελάτη, οι οποίες δεν χρειάζεται να γνωρίζουν ή να εξαρτώνται από τις λεπτομέρειες υλοποίησής τους. Μια τέτοια πλατφόρμα είναι η Semantic Web Knowledge Manager (SWKM). Κοινή απαίτηση από αυτές τις πλατφόρμες είναι η παροχή κάποιου είδους αναπαράστασης κύριας μνήμης για σημασιολογικά δεδομένα, η οποία είναι αφενός απαραίτητη για την εσωτερική (από το ενδιάμεσο λογισμικό) επεξεργασία αυτών των δεδομένων, και αφετέρου χρήσιμη για τους πελάτες των υπηρεσιών. Επίσης άλλες μεγάλες εταιρίες όπως η IBM και η ORACLE χρησιμοποιούν τα δικά τους προγραμματιστικά εργαλεία. Εκτός από τα εμπορικά πακέτα, οι περισσότερες γλώσσες προγραμματισμού, όπως για παράδειγμα ηjava, PHP, έχουν ενσωματώσει 64

66 στις δυνατότητες τους την δυνατότητα για αυτόματη δημιουργία SOAP servers και δημοσίευση και ανάκληση των web services. Υπάρχουν μερικά εργαλεία που διατίθεται δωρεάν στο διαδίκτυο και απλουστεύουν σημαντικά τον προγραμματισμό Διαδικτυακών Υπηρεσιών. Ακολουθεί λίστα με τα σημαντικότερα από αυτά Apache Axis Ο οργανισμός Apache κατασκεύασε ένα εργαλείο συμβατό με το SOAP 1.1, το οποίο ονομάστηκε Apache SOAP και το οποίο αργότερα μετεξελίχθηκε σε περιβάλλον ανάπτυξης Java, με το όνομα Apache Axis. Για να λειτουργήσει σε ένα σύστημα, το Apache Axis απαιτεί την εγκατάσταση ενός διακομιστή εφαρμογών, όπως είναι ο Apache Tomcat, και έναν συντακτικός αναλυτής XML (XML parser). Αρχικά δημιουργείται η εφαρμογή της Διαδικτυακής Υπηρεσίας σε γλώσσα Java και κατόπιν δίνεται η δυνατότητα στον διαχειριστή του διακομιστή να δημοσιεύσει επιλεκτικά κάποιες από τις μεθόδους της εφαρμογής ή και όλες καθώς και να ρυθμίσει διάφορες άλλες σχετικές παραμέτρους. Το αρχείο WSDL παράγεται αυτόματα IBM web services Toolkit Η άλλη μεγάλη εταιρία που έχει συμβάλλει τα μέγιστα στον σχεδιασμό, ανάπτυξη και καθιέρωση των τεχνολογιών των Διαδικτυακών Υπηρεσιών, διαθέτει και αυτή ένα δικό της σύνολο εργαλείων με όνομα Web Services Toolkit 3.0. Στο πακέτο υπάρχει ενσωματωμένη μια περιορισμένη έκδοση του διακομιστή εφαρμογών WebSphere της IBM. Το toolkit παρέχει την λειτουργικότητα που παρέχουν και τα προηγούμενα πακέτα, όπως για παράδειγμα αυτόματη ή χειρωνακτική δημιουργία του αρχείου περιγραφής των δημιουργηθεισεών Διαδικτυακών Υπηρεσιών (WSDL). Αυτό που πρέπει να τονισθεί, διότι κάνει το πακέτο να ξεχωρίζει από τα προηγούμενα, είναι η πολύ καλή τεκμηρίωση και το πλούσιο συνοδευτικό υλικό που περιλαμβάνει έτοιμα παραδείγματα σύνθετων εφαρμογών που βασίζονται σε Διαδικτυακές Υπηρεσίες, όσο και μελέτες περιπτώσεων (case studies) για την επιτυχή αξιοποίηση και εισαγωγή των σχετικών τεχνολογιών στον κύκλο συναλλαγών μιας σύγχρονης επιχείρησης. 65

67 6.1.3 Microsoft SOAP Toolkit 2 Με το MS Toolkit 2 είναι δυνατή στον προγραμματιστή η αξιοποίηση των Διαδικτυακών Υπηρεσιών σε πλατφόρμες Windows στις οποίες δεν έχει εγκατασταθεί το.net Framework. Μπορεί να ενσωματωθεί στο περιβάλλον του Visual Studio 6. Υποστηρίζει το SOAP έκδοση 1,1, την WSDL έκδοση 1,1 και το UDDI. Προσφέρει συστατικά τόσο πελάτη όσο και διακομιστή. Υπάρχει η δυνατότητα για αλληλεπίδραση των Διαδικτυακών Υπηρεσιών με στοιχεία COM και για το λόγο αυτό παράγονται αυτόματα δύο αρχεία, ένα με επέκταση.wsdl και ένα με επέκταση.wsml (Web Services Meta Language). Υπάρχει επίσης και το συστατικό Remote Object Proxy Engine (ROPE) για την αυτοματοποίηση της διαδικασίας παραγωγής μηνυμάτων για την επικοινωνία με απομακρυσμένα αντικείμενα των Διαδικτυακών Υπηρεσιών. Τέλος για την απλούστευση της διαδικασίας δημιουργίας και επεξεργασίας των XML εγγράφων που στέλνονται ως SOAP μηνύματα, χρησιμοποιείται το SOAP Messaging Object (SMO) framework. 6.2 Οι Web Services στο περιβάλλον.νετ Η πλατφόρμα.net βασίζεται στο.net Framework, το οποίο διαθέτει μια σειρά από βιβλιοθήκες κλάσεων (Framework Class Library - FCL) και ένα περιβάλλον εκτέλεσης των εφαρμογών καλούμενο Common Language Runtime (CLR). Ο κώδικας που αναπτύσσεται με μια από τις γλώσσες που υποστηρίζουν τα FCL και CLR (όπως είναι για παράδειγμα οι Visual Basic.NET, Visual C++.NET, Visual C#, Perl και Python) μεταφράζεται πρώτα σε μια ενδιάμεση μεταφέρσιμη μορφή, που καλείται Microsoft Intermediate Language (MSIL). Ο binary κώδικας MSIL μπορεί να μεταφερθεί και να «τρέξει» σε οποιοδήποτε μηχάνημα έχει εγκατεστημένο το CLR, σε αντιστοιχία με την λογική εκτέλεσης των προγραμμάτων με Java Virtual Machine. Το.NET framework περιγράφεται αναλυτικά στο Common Language Specification (CLS), το οποίο έχει υποβληθεί για τυποποίηση στην ECMA (European Computer Manufacturers Association). Κατά την δημιουργία και δημοσίευση μιας web service στο Visual Studio, δημιουργούνται τα εξής αρχεία στο σύστημα: Το αρχείο που περιέχει τον πηγαίο κώδικα της Web Service και μπορεί να είναι για παράδειγμα.vb ή.cs, ανάλογα με τη γλώσσα που χρησιμοποιείται για την κωδικοποίηση της υπηρεσίας. Το αρχείο.asmx που περιέχει τεκμηρίωση για την υπηρεσία. Πλήρης περιγραφή της υπηρεσίας παρέχεται και από το αρχείο WSDL, αλλά η 66

68 περιγραφή του asmx δίνει χρήσιμα στοιχεία για την υπηρεσία, όπως το που βρίσκεται το source αρχείο που αναφέρθηκε παραπάνω. Το αρχείο.asax που αποτελεί μια περιγραφή της συνολικής εφαρμογής στην οποία ανήκει η συγκεκριμένη Web Service. Τα αρχεία.disco,.vdisco και.map που χρησιμοποιούνται για την αναζήτηση και εντοπισμό της υπηρεσίας από πιθανούς clients που θέλουν να την χρησιμοποιήσουν. Πρόκειται για μια τεχνολογία που χρησιμοποιείται από την Microsoft για να ευρετηριοποιούνται οι τοπικά διαθέσιμες Web Services. Η τεχνολογία των αρχείων.disco λειτουργεί παράλληλα με το UDDI το οποίο χρησιμεύει στην ευρετηριοποίηση όλων των εξωτερικών για ένα σύστημα διαθέσιμων Web Services. Ωστόσο η χρήση των αρχείων DISCO αντικαθίσταται βαθμιαία από την τεχνολογία WS-Inspection με την οποία δημιουργούνται αρχεία WS-Inspection για αναφορές σε τοπικές Web Services σε έναν server. Το αρχείο.wdsl είναι ένα έγγραφο xml που αποτελεί μια λεπτομερή τεχνική περιγραφή της υπηρεσίας. Το αρχείο.wdsl μπορεί κανείς να το προβάλει στον browser πληκτρολογώντας [Διαδρομή αρχείου asmx].asmx?wsdl, π.χ file:///%system%/visual Studio/MyProject/MyService.asmx?WSDL. Για την ανάκληση μιας Web Service πρέπει να αναπτυχθεί με τη βοήθεια του Visual Studio μια client εφαρμογή. Πρέπει να εκτελεστεί στην συνέχεια μέσα από το τρέχον έργο η εντολή Add Web Reference. Με την εντολή αυτή δημιουργείται ένας φάκελος ο οποίος περιέχει ένα αντίγραφο του.wsdl αρχείου της καλούμενης υπηρεσίας αρχεία.disco και μια κλάση διαμεσολάβησης (proxy class). Η κλάση proxy για την υπηρεσία κατασκευάζεται με βάση το αρχείο περιγραφής WSDL. Η δοκιμαστική ανάκληση των Web Services στο.νετ στην σελίδα του αρχείου.asmx γίνεται όχι με το SOAP αλλά με ένα πρωτόκολλο που βασίζεται σε μηνύματα HTTP POST (request/respose) και χρησιμοποιεί την σύνταξη URI/method?arg1=value1&arg2=value2. Το πρόγραμμα client δημιουργεί ένα instance της κλάσης proxy και μετά στέλνει σε αυτή τα μηνύματα (με την κλήση των κατάλληλων μεθόδων). Η κλάση proxy έχει το ίδιο όνομα με την αντίστοιχη κλάση της Web Service και βρίσκεται καθ όλη τη διάρκεια μεταξύ της Web Service και της εφαρμογής client. Για κάθε κλήση μιας μεθόδου της Web Service ουσιαστικά η εφαρμογή client καλεί μια αντίστοιχη μέθοδο της κλάσης proxy. Μετά την εκτέλεση της μεθόδου από την Web Service και SOAP στην μέθοδο Web Service. Μετά την εκτέλεση της μεθόδου από την Web Service και επιστροφή του αποτελέσματος στην κλάση proxy, η κλάση μορφοποιεί τα αποτελέσματα ώστε να είναι κατανοητά από την εφαρμογή client. Το σημαντικό είναι ότι σε όλη την διαδικασία η κλάση proxy είναι διαφανής από την εφαρμογή client. Έτσι δημιουργείται η εντύπωση ότι καλούμε μεθόδους των Web Services σαν να βρίσκονταν διαθέσιμες τοπικά. 67

69 Η Microsoft διαθέτει και μια σειρά από άλλες συνοδευτικές τεχνολογίες για την βελτίωση των Web Services με επιπρόσθετα λειτουργικά χαρακτηριστικά. Μερικές από αυτές τις τεχνολογίες είναι: Global XML Web Service Architecture, για ανάπτυξη σύνθετων Web Service. WS-Inspection και WS-Referral για παραμετροποίηση της δρομολόγησης των SOAP μηνυμάτων. WS-Security, για εξασφάλιση της ιδιωτικότητας και της ακεραιότητας των μηνυμάτων. WSE (Web Service Enhancements), μια σειρά από υπηρεσίες που προσφέρουν αυξημένα λειτουργικά χαρακτηριστικά κατά την δημιουργία, δημοσίευση και κατανάλωση μιας Web Service. Ας πάρουμε λοιπόν την γλώσσα PHP για να ξεκινήσουμε ένα απλό παράδειγμα.. (Για περισσότερες και αναλυτικότερες λεπτομέρειες μπορεί κανείς να απευθυνθεί σε on -line βοηθήματα στο Internet όπως το « κ.α.). Ας υποθέσουμε πως η εκκλησία της Ελλάδος επιθυμεί να υλοποιήσει ένα web service το οποίο θα παρέχει υπηρεσίες εορτολογίου. Δηλαδή για κάθε ημερομηνία που θα δέχεται θα επιστρέφει τα ονόματα των Αγίων που γιορτάζουν εκείνη την ημέρα Έχοντας δημιουργήσει μία απλή βάση δεδομένων με τις ημερομηνίες και τις αντίστοιχες εορτές το υπόλοιπο κομμάτι της υλοποίησης περιγράφεται παρακάτω: 1. Δημιουργούμε τη διαδικασία ερώτησης στην βάση και επιστροφής αποτελεσμάτων. Αυτό γίνεται με μία συνάρτηση σε PHP π.χ. evresi_eortis(date) 2. Δημιουργούμε τον SOAP server. Χρησιμοποιώντας την έτοιμη βιβλιοθήκη nusoap με 5 εντολές δημιουργούμε τον server μας σε ένα αρχείο π.χ. eortes.php 3. Ορίζουμε στον server τη λειτουργία που επιθυμούμε να κάνει. Π.χ. Ορίζουμε τη λειτουργία vres_giorti η οποία αντιστοιχεί στη συνάρτηση evresi_eortis. 4. Δημιουργούμε το wsdl αρχείο με τις πληροφορίες για τον server μας την λειτουργία τους και τα δεδομένα που δέχεται και επιστρέφει. Σε αυτό το σημείο έχουμε δημιουργήσει ένα web service το οποίο εκτελεί μόνο μία λειτουργία και μπορεί κανείς να το προσπελάσει στη διεύθυνση που έχουμε αποθηκεύσει το αρχείο eortes.php. Tο αρχείο eortes.php <?php // evresi eortis function evresi_eortis($date) { 68

70 $query = "select onomata from imerologio where hmerominia = ". $Date; if (mysql_connect("localhost", "username", "passwd")) else { $error = "Database connection error"; return $error; } if (mysql_select_db("imerologio")) else { $error = "mysql_error()"; return $error; } $onomata = mysql_result($result, 0, 0); return $onomata; } // SOAP SERVER require_once('nusoap.php'); $server = new soap_server; $server->register('evresi_eortis'); $server->service($http_raw_post_data);?> 69

71 7 Αναπτυσσόµενες τεχνολογίες Οι τρεις βασικές τεχνολογίες των web serνices : SOAP, WSDL, και UDDI µαζί µε την ΧΜL στην οποία βασίζονται παρέχουν µόνο τις βασικές λειτουργίες των web serνices. Άλλα χαρακτηριστικά τα οποία είναι αναγκαία για µία ολοκληρωµένη κατανεµηµένη τεχνολογία είναι η αξιοπιστία (reliability) η ασφάλεια (security) και οι συναλλαγές (transactions). Η παροχή αυτών των υπηρεσιών στο περιβάλλον των web serνices είναι ευθύνη κάποιων άλλων προδιαγραφών που βρίσκονται αυτή τη στιγµή ακόµη υπό ανάπτυξη. 7.1 Web services και ασφάλεια Τα web serνices παρέχουν πολλά πλεονεκτήµατα στις εφαρµογές αλλά επίσης εκθέτουν σηµαντικούς νέους κινδύνους στην ασφάλεια. Η δηµιουργία και η διατήρηση ενός ασφαλούς περιβάλλοντος web serνices περιλαµβάνει και τη διαχείριση διαφόρων µηχανισµών για το διαδίκτυο, την ΧΜL και τα ίδια τα web serνices. Η γενική αντιµετώπιση αφορά τα παρακάτω: Ασφάλεια σε επίπεδο µεταφοράς όπως τα τείχη προστασίας (firewalls), τα ιδεατά ιδιωτικά δίκτυα (VPNs), η επικύρωση (authentication), η µη αποκήρυξη ευθύνης (non-repudiation), και η κρυπτογράφηση ( encryption). Ασφάλεια σε επίπεδο µηνύµατος όπως τα στοιχεία επικύρωσης (authentication tokens) για να επικυρώσουν την ταυτότητα του αιτούντα και οι δηλώσεις έγκρισης (authorization assertions) για να ελέγξουν την πρόσβαση στις υπηρεσίες του παρόχου. Ασφάλεια σε επιπεδο δεδοµένων όπως είναι η κρυπτογράφηση (encryption) και η ηλεκτρονική υπογραφή (digitai signature) για την προστασία ενάντια στις αθέµητες αλλαγές των δεδοµένων. Ασφάλεια σε επίπεδο περιβάλλοντος όπως είναι η διαχείριση (management), η αναγραφή (logging) και ο έλεγxος (auditing) για την αναγνώριση των προβληµάτων που πρέπει να διορθωθούν. Για την αντιμετώπιση όλων των παραπάνω δημιουργήθηκε μια ομόδα από προδιαγραφές που είναι ακόμη υπό ανάπτυξη. Οι κυριότερες από αυτές είναι οι παρακλατω : 70

72 WS-Security: καθορίζει μια αρχιτεκτονική για ασφαλή επικοινωνία. WS-Polίcy: και οι σχετικές με αυτήν προδιαγραφές καθορίζουν μια πολιτική από κανόνες για το πώς οι υπηρεσίες θα αλληλεπιδρούν μεταξύ τους. WS-Trust: καθορίζει το μοντέλο εμπιστοσύνης για ασφαλείς συναλλαγές. WS-Privacy: καθορίζει πώς τηρείται η ιδιοτικότητα στις πληροφορίες. WS-Secure Conversation: καθορίζει πώς θα επιτευχθεί μια ασφαλή συνεδρία μεταξύ υπηρεσιών που ανταλλάσουν δεδομένα με κανόνες ορισμένους στα WS-Policy, WS-Trust, WS-Privacy. WS-Federation: καθορίζει τους κανόνες σχετικά με την ταυτότητα σε κατανεμημένο περιβάλλον. WS-Authorization: χειρίζεται την επεξεργασία για την επικύρωση που αφορά στην πρόσβαση και την ανταλλαγή δεδομένων. Όλα τα παραπάνω χρησιμοποιούν το SOAP Header και έτσι εκμεταλλεύονται στο έπακρο την επεκτασιμότητα του πρωτοκόλλου SOAP. 7.2 Web services και μηνυματοδότηση (messaging) Υπάρχει ακόμη μία ομάδα προδιαγραφών που πραγματεύεται ζητήματα που έχουν να κάνουν με την αξιόπιστη αποστολή μηνυμάτων (reliable messaging) και τις ειδοποιήσεις (notifιcation): WS-ReliableMessaging και WS-Reliability: καθορίζουν μηχανισμούς για την εξασφάλιση της παράδοσης των μηνυμάτων, με τη σωστή σειρά, και την εξάλειψη των διπλότυπων. WS-Eventing και WS-Notifίcation: παρέχουν ένα μηχανισμό σχετικά με τα γεγονότα (events) ώστε οι συνδρομητές να ειδοποιούνται ανεξάρτητα από τη σχέση μεταξύ του παρόχου και του αιτούντα. Και οι παραπάνω τεχνολογίες χρησιμοποιούν το SOAP Header. 7.3 Web services και συναλλαγές (transactions) Οι συναλλαγές αποτελούν ένα πολύ σηµαντικό χαρακτηριστικό το οποίο έχει αποδειχθεί πολύ χρήσιµο στο πέρασµα των χρόνων. Οι συναλλαγές στο περιβάλλον των web services µας εξασφαλίζουν ότι µία οµάδα από web services πετυχαίνει ένα κοινό αποτέλεσµα. Τα web services συχνά 71

73 εξαρτώνται το ένα από το άλλο για να ολοκληρώσουν πολύπλοκες αιτήσεις σε µία εφαρµογή όπως η ενηµέρωση µιας εγγραφής πελάτη (η οποία µπορεί να ενηµερώνει πολλαπλές βάσεις δεδοµένων µε στοιχεία πελάτη) ή η επεξεργασία µίας παραγγελίας (η οποία µπορεί να ενηµερώνει πολλαπλές βάσεις δεδοµένων αποθηκών). Οι πιο σηµαντικές προσπάθειες που σχετίζονται µε τις συναλλαγές στο περιβάλλον των web services είναι οι παρακάτω: WS-Transaction: µία οικογένεια προδιαγραφών που περιλαµβάνει: o WS-AtomicTransactions (WS-AT): Ένα πρωτόκολλο twophase commit για διαλειτουργικότητα των web services. o WS-BusinessActivity (WS-BA): Ένα ανοικτό ενσωµατωµένο πρωτόκολο για µακροπρόθεσµες επιχειρισιακές διαδικασίες. o WS-Coordination (WS-C): Ένα πλαίσιο συντονισµού που υποστηρίζει τα WS-AT και WS-C. WS-Composite Applίcation Framework µία οικογένεια προδιαγραφών που περιλαµβάνει: o WS-Context (WS-CTX): Ένας γενικός µηχανισµός διαχείρισης πλαισίου. o WS-CoordinationFramework (WS-CF): Ενα πλαίσιο συντονισµού που υποστηρίζει τα WS-AT, WS-BA, και τα τρία πρωτόκολλα στο WS-TXM. o WS- TransactionManagement (WS- ΤΧΜ): Ένα πρωτόκολλο για two-phase commit για διαλειτουργικότητα των Web Services (ACID), ένα πρωτόκολλο βασισµένο στη διόρθωση (compensation) για µακροπρόθεσµες διαδικασίες (LRA), και ένα πρωτόκολλο διαχείρισης επιχειρησιακών διαδικασιών (ΒΡ). 72

74 Κεφάλαιο 8 8 Συμπεράσματα-αποτίμηση των web services Τα τελευταία χρόνια η ΧΜL έχει επιτρέψει σε διαφορετικά υπολογιστικά περιβάλλοντα να µοιράζονται πληροφορίες µέσω του παγκόσµιου ιστού. Τώρα προσφέρει ένα απλοποιηµένο τρόπο µε τον οποίο µπορούν να µοιράζονται και να επεξεργάζονται την πληροφορία. Από τεχνικής σκοπιάς, η άνθηση των Web services δεν είναι µια επανάσταση στα κατανεµηµένα συστήµατα. Αντίθετα είναι µια φυσική εξέλιξη της εφαρµογής της ΧΜL από δοµηµένη αναπαράσταση πληροφορίας σε δοµηµένη αναπαράσταση µηνυµάτων µεταξύ των εφαρμονών. Πριν την άφιξη των Web services,η ολοκλήρωση επιχειρηµατικών συστηµάτων ήταν πολύ δύσκολη εξαιτίας των διαφορών στις γλώσσες προγραµµατισµού και του υλικολογισμικού (middleware) που χρησιµοποιούνταν µέσα στις επιχειρήσεις. Αυτό οδήγησε σε µια κατάσταση όπου η διαλειτουργικότητα ήταν δύσκολη και επίπονη. Με την άφιξη των Web services κάθε εφαρµογή µπορεί να ολοκληρωθεί αρκεί να είναι διαδικτυακή. Είναι δύσκολο να αποφύγει κανείς τη δηµοσιότητα και τη διαφηµιστική εκστρατεία γύρω από τα Web services. Κάθε µεγάλος προµηθευτής λογισµικού έχει κάποια πρωτοβουλία σχετική µε τα Web services και υπάρχει πάντα µια θεωρία για το µέλλον της αγοράς. Όπως και να έχει, οι αρχιτεκτονικές Web services παρέχουν ένα πολύ διαφορετικό τρόπο σκέψης για την ανάπτυξη λογισµικού. Από το µοντέλο πελάτη-διακοµιστή στα συστήµατα ν-επιπέδων, στα κατανεµηµένα συστήµατα, οι εφαρµογές Web services αντιπροσωπεύουν το αποκορύφωµα κάθε µίας από αυτές τις αρχιτεκτονικές σε συνδυασµό µε το διαδίκτυο. 73

75 Κεφάλαιο 9 9 Παράδειγματα web services Παραδειγμα 1 Στο παράδειγμα που ακολουθεί θα χρησιμοποιήσουμε ASP.NET για να δημιουργήσουμε ένα απλό web service που θα μετατρέπει την θερμοκρασία απο βαθμούς Fahrenheit σε βαθμούς Celsius. <%@ WebService Language="VBScript" Class="TempConvert" %> Imports System Imports System.Web.Services Public Class TempConvert :Inherits WebService <WebMethod()> Public Function FahrenheitToCelsius (ByVal Fahrenheit As String) As String dim fahr fahr=trim(replace(fahrenheit,",",".")) if fahr="" or IsNumeric(fahr)=false then return "Error" return ((((fahr) - 32) / 9) * 5) end function <WebMethod()> Public Function CelsiusToFahrenheit (ByVal Celsius As String) As String dim cel cel=trim(replace(celsius,",",".")) if cel="" or IsNumeric(cel)=false then return "Error" return ((((cel) * 9) / 5) + 32) end function end class 74

76 Το αρχείο αυτό είναι αποθηκευμένο ως.asmx file. Είναι η ASP.NET προέκταση για την XML web service. Επεξήγηση του παραδείγματος Σημείωση: για να λειτουργήσει αυτό το παράδειγμα,χρειάζεται ένα.net server. Η πρώτη γραμμή στο παράδειγμα δηλώνει οτι είναι ένα web service γραμμένο σε VBScript και έχει την κλάσση με το όνομα "TempConvert": WebService Language="VBScript" Class="TempConvert" %> Οι επόμενες γραμμές εισάγουν το namespace "System.Web.Services" από το πλαίσιο.net Imports System Imports System.Web.Services Η επόμενη γραμμή ορίζει οτι τοη κλάσση "TempConvert" είναι μία κλάσση web service. Public Class TempConvert :Inherits WebService Τα επόμενα βήματα είναι βασικός VB προγραμματισμός.η εφαρμογή αυτή, έχει δύο λειτουργείες,μία να μετατρέπει απο Fahrenheit se Celcius και μία απο Celcius σε Fahrenheit. Η μόνη διαφορά με μια κανονική εφαρμογή είναι οτι αυτή η λειτουργία ορίζεται ως "WebMethod()". Χρησιμοποιούμε το "WebMethod()" για να μετατρέψουμε τις λειτουργίες της εφαρμογής μας σε web service. 75

77 <WebMethod()> Public Function FahrenheitToCelsius (ByVal Fahrenheit As String) As String dim fahr fahr=trim(replace(fahrenheit,",",".")) if fahr="" or IsNumeric(fahr)=false then return "Error" return ((((fahr) - 32) / 9) * 5) end function <WebMethod()> Public Function CelsiusToFahrenheit (ByVal Celsius As String) As String dim cel cel=trim(replace(celsius,",",".")) if cel="" or IsNumeric(cel)=false then return "Error" return ((((cel) * 9) / 5) + 32) end function Τέλος,τελειώνουμε την κλάσση με end class Σημείωση: με το ASP.NET δεν χρειάζεται να γράψουμε τα δικά μας αρχεία WSDL και SOAP. Παραδειγμα 2 Το e.centric v.3 επιτρέπει τη δημιουργία Enterprise Information Portals (Internet, Intranet, Extranet sites) και προσφέρει Content Management, Knowledge Management, διαθέσιμα modules e-learning, collaboration & messaging και Project Management. Ταυτόχρονα όμως, παρέχει τη δυνατότητα ανάπτυξης εφαρμογών 76

78 εύκολα και γρήγορα με χρήση των παραπάνω ως υποδομή, ενώνοντας, ελέγχοντας και πολλαπλασιάζοντας τα οφέλη. H πλατφόρμα e.centric έχει σχεδιαστεί ώστε να είναι εύκολα επεκτάσιμη και χρησιμοποιεί standards τελευταίας γενιάς, όπως XML, XSLT, XML Schema, WEBDAV, ICE, RSS και Web Services, ενώ λειτουργεί εξ ολοκλήρου με τη χρήση του HTTP πρωτοκόλλου. Οι ASP επεκτάσεις του συστήματος δίνουν τη δυνατότητα σε ένα e.centric Administration portal να φιλοξενεί πολλαπλά e.centric sites. Επίσης δίνουν τα εργαλεία για την κεντρική και καθολική διαχείριση των φιλοξενούμενων (hosted) e.centric sites. Η αρχιτεκτονική του συστήματος επιτρέπει την κλιμάκωσή του σε πολλαπλές μηχανές (υποστηρίζοντας web farms, automatic content replication, scalable session management, κλπ.), για τη κατανομή του φόρτου εργασίας και την αποφυγή οποιουδήποτε single point of failure. Ακόμη, έχει σχεδιαστεί ώστε να είναι εφικτή η διασύνδεσή του με την πλειοψηφία των συστημάτων βάσεων δεδομένων. Το περιεχόμενο που φυλάσσεται στον κοινό αποθηκευτικό χώρο, μπορεί να διανεμηθεί σε πολλαπλά κανάλια, όπως το Intranet, Internet ή ακόμη και WAP πύλες, σε ένα απεριόριστο αριθμό γλωσσών. 77

79 Παραδειγμα 3 Το σχήμα που ακολουθεί (Σχήμα ) παρουσιάζει συνοπτικά το τελικό περιβάλλον διαλειτουργικότητας στο δημόσιο τομέα και την επαφή του πολίτη και της επιχείρησης με αυτό. Διακρίνονται οι διάφοροι δημόσιοι φορείς και τα πληροφοριακά συστήματά τους, άλλα από τα οποία υποστηρίζουν το ΠΔΗΔ (Πλαίσιο Διαλειτουργικότητας Ηλεκτρονικής Διακυβέρνησης) με Middleware και άλλα χωρίς, τα οποία ανταλλάσσουν δεδομένα μεταξύ τους ή με επιχειρήσεις και με τον πολίτη μέσω ενός κυβερνητικού portal ή απευθείας μέσω των δικών του web sites. 78

80 Ας θεωρήσουμε συγκεκριμένο παράδειγμα για να επιδείξουμε την χρήση της XML και των XML Schemas κατά την επικοινωνία και την υλοποίησή της.θεωρούμε ότι ένας από τους φορείς του παραπάνω σχήματος διατηρεί στοπληροφοριακό σύστημά του όλα τα στοιχεία των οχημάτων και θέλει ναπροσφέρει τις εξής δυο υπηρεσίες σε κάποιους άλλους φορείς (το παράδειγμα είναι φανταστικό και εστιάζεται στη χρήση XML): Αναζήτηση των στοιχείων δεδομένου οχήματος και του νόμιμου κατόχου του με κλειδί το αριθμό της πινακίδας. Μεταφορά της κυριότητας ενός οχήματος με δεδομένο αριθμό πινακίδας και σε πολίτη με δεδομένα στοιχεία (θεωρούμε ότι ο φορέας που διατηρεί τα στοιχεία των οχημάτων δεν διατηρεί και τα στοιχεία όλων των πολιτών). Για το σκοπό αυτό ο φορέας προσθέτει στο πληροφοριακό σύστημα του δύο Web Services που περιγράφει με το ακόλουθο αρχείο WSDL (Web Service Definition Language) Αρχείο περιγραφής των Web services (κατά WSDL) 79

81 <wsdl:definitions xmlns=" xmlns:apachesoap=" xmlns:ym=" xmlns:soapenc=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" xmlns:veh=" xmlns:addr=" xmlns:cd=" xmlns:ns=" targetnamespace=" <wsdl:types> <schema targetnamespace=" xmlns=" <import namespace=" <import namespace=" schemalocation="gr_address_types.xsd.xml"/> <import namespace=" schemalocation="gr_citizen_types.xsd.xml"/> <import namespace=" schemalocation="gr_vehicle_types.xsd.xml"/> </schema> </wsdl:types> 80

82 <wsdl:message name="getvehiclelicenserequest"> <wsdl:part name="platenumber" type="veh:platenumbertype"/> </wsdl:message> <wsdl:message name="getvehiclelicenseresponse"> <wsdl:part name="vehiclelicense"type=" veh:vehiclelicensestructure"/> </wsdl:message> <wsdl:message name="transferownershiprequest"> <wsdl:part name="newvehiclelicense" type="veh: VehicleLicenseStructure"/> </wsdl:message> <wsdl:message name="transferownershipresponse"> </wsdl:message> <wsdl:porttype name="ymservice"> <wsdl:operation name="getvehiclelicense"> <wsdl:input name="getvehiclelicenserequest" message="ym:getvehiclelicenserequest"/> <wsdl:output name="getvehiclelicenseresponse" message="ym:getvehiclelicenseresponse"/> </wsdl:operation> <wsdl:operation name="transferownership"> 81

83 <wsdl:input name="transferownershiprequest" message="ym:transferownershiprequest"/> <wsdl:output name="transferownershipresponse" message="ym:transferownershipresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="ymsoapbinding" type="ym:ymservice"> <wsdlsoap:binding style="rpc" transport=" <wsdl:operation name="getvehiclelicense"> <wsdlsoap:operation/> <wsdl:input> <wsdlsoap:body use="encoded encodingstyle=" </wsdl:input> <wsdl:output> <wsdlsoap:body use="encoded" encodingstyle=" </wsdl:output> </wsdl:operation> 82

84 <wsdl:operation name="transferownership"> <wsdlsoap:operation/> <wsdl:input> <wsdlsoap:body use="encoded" encodingstyle=" </wsdl:input> <wsdl:output> <wsdlsoap:body use="encoded" encodingstyle=" </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="ypourgeio_metaforwn"> <wsdl:port name="ym" binding="ym:ymsoapbinding"> <wsdlsoap:address location=" </wsdl:port> </wsdl:service> </wsdl:definitions> 83

85 Παραδειγμα 4 Ανάπτυξη λογισμικού υποδομής (WebServices) που θα επιτρέπει την διασύνδεση των φορέων μέσω τεχνολογίας WebServices για πρόσβαση σε εφαρμογές και δεδομένα. 84

86 Παραδειγμα 5 Φορείς υλοποιούν βασικές λειτουργίες σαν Web Services π. χ φορολογική ή ασφαλιστική ενημερότητα, έκδοση πιστοποιητικών. 85

87 Παραδειγμα 6 Αγορά εισιτηρίου: Πρόσβαση στην υπηρεσία, Εγγραφή/καταχώρηση, Πληρωμή, Διαμόρφωση του XML εισιτηρίου, Υπογραφή του εισιτηρίου με βάση το XML DSIG, Αποστολή του υπογεγραμμένου XML εισιτηρίου μέσω Επικύρωση του εισιτηρίου: Υποβολή του εισιτηρίου στον ελεγκτή εισιτηρίων, Επαλήθευση υπογραφής, Έλεγχος της πληροφορίας του εισιτηρίου, Είσοδος στην υπηρεσία 86

88 87

89 Κεφαλαιο Ηλεκτρονικη υγεια Ο όρος ηλεκτρονική υγεία (ehealth) καλύπτει ένα ευρύ φάσμα εργαλείων βασισμένων στις τεχνολογίες πληροφοριών και επικοινωνιών που στοχεύουν στην καλύτερη πρόληψη, διάγνωση, θεραπεία, παρακολούθηση και διαχείριση της υγείας και του τρόπου ζωής. Η ηλεκτρονική υγεία περιλαμβάνει τη συνεργασία μεταξύ ασθενών και φορέων παροχής υγειονομικών υπηρεσιών, την ανταλλαγή δεδομένων μεταξύ διαφόρων ιδρυμάτων και την επικοινωνία μεταξύ ασθενών ή απασχολουμένων στον τομέα της υγείας περιλαμβάνει επίσης δίκτυα πληροφοριών για την υγεία, ηλεκτρονικά μητρώα υγείας, υπηρεσίες τηλεϊατρικής και ατομικά ενδυτά και φορητά επικοινωνούντα συστήματα για την παρακολούθηση και στήριξη των ασθενών. Τα εργαλεία ηλεκτρονικής υγείας παρέχουν, για παράδειγμα, πρόσβαση σε πληροφορίες για την υγεία που μπορούν να σώσουν ζωές, γεγονός ιδιαίτερα σημαντικό λόγω της ολοένα μεγαλύτερης διασυνοριακής κυκλοφορίας πολιτών και ασθενών. Η ηλεκτρονική υγεία μπορεί να αποφέρει σημαντικά οφέλη σε ολόκληρη την κοινωνία, βελτιώνοντας την πρόσβαση στην παρεχόμενη περίθαλψη καθώς και την ποιότητά της. Επιπλέον, συμβάλλει στην ανάπτυξη συστημάτων υγείας προσανατολισμένων στον πολίτη και στην εν γένει αποτελεσματικότητα, αποδοτικότητα και βιωσιμότητα του τομέα της υγείας. Η Ευρωπαϊκή Ένωση προωθεί τη δημιουργία ενός ευρωπαϊκού χώρου ηλεκτρονικής υγείας, συντονίζοντας δράσεις και διευκολύνοντας τη συνέργεια μεταξύ συναφών πολιτικών και ενδιαφερομένων φορέων με στόχο την εξεύρεση καλύτερων λύσεων, την αποφυγή του κατακερματισμού της αγοράς και τη διάδοση ορθών πρακτικών. Ειδικότεροι στόχοι της είναι η δημιουργία ενός συστήματος ηλεκτρονικών μητρώων υγείας με τη στήριξη της ανταλλαγής πληροφοριών και της τυποποίησης η ανάπτυξη δικτύων ανταλλαγής πληροφοριών για την υγεία μεταξύ φορέων περίθαλψης, ώστε να υπάρχει συντονισμός των δράσεων σε περίπτωση κινδύνου για τη δημόσια υγεία η παροχή υπηρεσιών υγείας σε απευθείας σύνδεση, όπως πληροφοριών για μια υγιεινή ζωή και πρόληψη των ασθενειών και, τέλος, η ανάπτυξη συστημάτων τηλεσυμβουλευτικής (teleconsultation), ηλεκτρονικής συνταγογράφησης (eprescribing), ηλεκτρονικής παραπομπής (ereferral) και ηλεκτρονικής επιστροφής των ιατρικών εξόδων. Για να στεφθεί από επιτυχία το εγχείρημα αυτό, θα πρέπει να ληφθούν υπόψη οι ανάγκες των πολιτών, των ασθενών και των απασχολουμένων στον τομέα της υγείας και, παράλληλα, να εξασφαλιστεί η συμμετοχή τους στην υλοποίηση των σχετικών σχεδίων και στρατηγικών. 88

90 10.2 E-patients (ηλεκτρονικοι ασθενής) Ο όρος e-patient Hλεκτρονικός ασθενής είναι πολύ καινούριος για την Ελληνική πραγματικότητα, αλλά όχι για την διεθνή κοινότητα του διαδικτύου. Τι σημαίνει όμως ό όρος αυτός ; Σύμφωνα με το με τον όρο e-patients ή internet patients εννοούμε άτομα, όχι υποχρεωτικά ασθενείς, αλλά καταναλωτές, χρήστες υπηρεσιών υγείας που χρησιμοποιούν το ιντερνέτ, αλλά όχι μόνον αυτό, για να συγκεντρώσουν πληροφορίες για ένα θέμα υγείας, μια ασθένεια, φάρμακα, ή θεραπείες που τους ενδιαφέρουν. Ο όρος περιλαμβάνει όχι μόνον τους ίδιους τους ασθενείς που ενδιαφέρονται για πληροφορίες για συγκεκριμένη ασθένεια αλλά και τους φίλους, τα μέλη της οικογένειάς τους, τα άτομα που τους φροντίζουν (e-caregivers) που αναζητούν ιατρικής φύσης πληροφορίες για λογαριασμό τους. H Trisha Torrey δημιούργησε τον όρο ΕmPatients (από το empowered patients). Οι όροι e-patient και EmPatients είναι συνώνυμοι. Ο αριθμός των e-patients αυξάνεται συνεχώς και η παρουσία τους στα κοινωνικά μέσα του διαδικτύου είναι σημαντική, ιδιαίτερα στην Αμερική, Αυστραλία και Ευρώπη. Η αύξηση του αριθμού των e- patients ενισχύει τα μοντέλα συμμετοχικής ιατρικής Participatory Medicine ή παροχής ιατρικών υπηρεσιών μέσω διαδικτύου Health 2.0 / Medicine 2.0. Ποιά είναι τα χαρακτηριστικά του ηλεκτρονικού ασθενούς/e-patient; Σύμφωνα μέ την Krū Research, που καλύπτει τον τομέα «empowered patients», o ηλεκτρονικός ασθενής χαρακτηρίζεται από τα επτά E, ως «equipped, enabled, empowered, engaged, equal, emancipated and expert». «Equipped»: εξοπλισμένος με τις κατάλληλες δεξιότητες για την διαχείριση της ασθένειάς τους «Enabled»: έχει διευκολυνθεί να κάνει επιλογές για την φροντίδα της υγείας του και οι επιλογές του είναι σεβαστές. «Empowered»: ενδυναμωμένος ψυχολογικά «Engaged»: δεσμεύμενος για την φροντίδα της υγείας του, επικοινωνεί μέ άλλους για τα θέματα που τον απασχολούν «Equal»: αισθάνεται ισότιμος στην σχέση του με τους γιατρούς που ασχολούνται με την περίθαλψή του «Emancipated»: απελευθερωμένος από προκαταλήψεις «Expert»: έμπειρος, οι έμπειροι ασθενείς μπορούν να βελτιώσουν την κατάσταση της υγείας τους, να αντιμετωπίσουν καλύτερα την κόπωση και άλλα συμπτώματα χρονίων ασθενειών και να μειώσουν τον βαθμό ανικανότητας και εξάρτησης από νοσοκομειακή φροντίδα. Τι γίνεται όμως στή χώρα μας ; Υπάρχουν e-patients ; Eίναι αρκετοί για να δημιουργήσουν μια κρίσιμη μάζα που ενδεχόμενα θα πυροδοτούσε στην αρχή 89

91 κάποιες αλλαγές στις σχέσεις ασθενών και χρηστών υπηρεσιών υγείας με την κοινότητα των επαγγελματιών υγείας; Για να εκτιμήσουμε την ανάπτυξη της ενασχόλησης του πληθυσμού στη χώρα με το ιντερνέτ για θέματα υγείας αρκεί να κάνουμε μια απλή αναζήτηση στο google. Tα αποτελέσματα μιλούν μόνα τους. Ο αριθμός των αποτελεσμάτων αναζήτησης σήμερα στο Google με λέξεις όπως patient, health consumer, e-patient, empowered patient, digital health consumer έδωσε τα εξής αποτελέσματα και είναι ενδεικτική για το πώς εξελίσσεται ο χώρος: 90

92 10.3 Τι χρησιμοποιείται σήμερα στην ιατρική Σήμερα, παρόλο που με τα διάφορα επιχειρησιακά προγράμματα (Κοινωνία της πληροφορίας κλπ) έχει προχωρήσει αρκετά η μηχανογράφηση των νοσοκομείων, αρκετά νοσοκομεία δε διαθέτουν λειτουργικό σύστημα ηλεκτρονικού ιατρικού φακέλου, ή διαθέτουν σύστημα πληροφορικής μόνο για το διοικητικό κομμάτι τους. Επιπλέον αρκετά Κέντρα Υγείας δε διαθέτουν αντίστοιχες υποδομές. Αυτό έχει ως αποτέλεσμα την υποβάθμιση του επιπέδου της παρεχόμενης περίθαλψης αλλά και την αύξηση του οικονομικού κόστους. Επίσης, η έλλειψη μηχανογράφησης κάποιων νοσοκομείων έχει ως αποτέλεσμα να υπάρχουν φαινόμενα κακής διαχείρισης ιατρικού υλικού και εξοπλισμού με σημαντικό οικονομικό κόστος. Τι ωθεί όμως τον κλάδο της υγείας στην εξοικείωση του με τις νέες τεχνολογίες; Η ιατρική πράξη δεν παραμένει ανεπηρέαστη; Αν εξαιρέσουμε τις εφαρμογές τηλεϊατρικής, η παροχή των καθεαυτό ιατρικών υπηρεσιών στους ασθενείς, η νοσηλεία, οι εξετάσεις δεν θα γίνονται με τον ίδιο τρόπο; Ναι, όμως υποστηρίζονται καλύτερα και συνεπώς ο πολίτης - ασθενής μένει περισσότερο ικανοποιημένος από τις υπηρεσίες που λαμβάνει. Παράλληλα, ενισχύεται η παραγωγικότητα του προσωπικού και η απόδοση του συνόλου κάθε μονάδας. Οι δικτυακές υπηρεσίες στις μονάδες υγείας (ηλεκτρονικός φάκελος ασθενούς, ηλεκτρονική διακίνηση-διαχείριση ιατρικών εγγράφων, ηλεκτρονική συνταγογράφηση, αποπληρωμή των υπηρεσιών, ηλεκτρονικές προμήθειες, κλπ) έχουν στόχο την εσωτερική οργάνωση και διεπικοινωνία μεταξύ μεμονωμένων μονάδων / υπομονάδων, ώστε να μειωθεί το λειτουργικό κόστος. Ένα σύστημα όμως σωστά δομημένο με άρτιες διαδικασίες εκπληρώνει καλύτερα τους στόχους του, δηλαδή την εξυπηρέτηση των ασθενών Artemis-Ανάπτυξη σημασιολογικά εμπλουτισμένων web services στην διαχείριση της υγείας Τα περισσότερα από τα πληροφοριακά συστήματα υγείας είναι ιδιωτικά και συχνά υπηρετούν μόνο ένα συγκεκριμένο τμήμα μέσα σε ένα ινστιτούο υγείας, που έχει ως αποτέλεσμα να δημιουργούνται δύσκολα διαλειτουργικά προβλήματα. Τα πράγματα γίνονται χειρότερα, όταν το ιατρικό ιστορικό ενός ασθενούς μεταφέρεται ανάμεσα σε πολλά ιατρικά ισντιτούτα, που δεν επικοινωνούν μεταξύ τους. Αυτό δυσκολεύει τους γιατρούς να έχουν μια σωστή ολοκληρωμένη εικόνα για το ιατρικό ιστορικό του ασθενούς. 91

93 Από την άλλη πλευρά, το μοντέλο των web services παρέχει στην βιομηχανία της υγείας μια ιδανική πλατφόρμα για την αποφυγή των δύσκολων διαλειτουργικών προβλημάτων. Τα web services είναι σχεδιασμένα να μαζεύουν και να εκθέτουν τις υπάρχουσες πηγές και να παρέχουν διαλειτουργικότα μεταξυ διαφόρων εφαρμογών. Η εμφάνιση των web services στον τομέα της υγείας έχει τα ακόλουθα πλεονεκτήματα: Γινεται εφικτή η παροχή της διαλειτουργικότητας των συστημάτων ιατρικών πληροφοριών μέσω της τυποποίησης της προσβασης σε δεδομένα μέσω WSDL και SOAP. Συστήματα ιατρικών πληροφοριών πάσχουν από πολλαπλασιασμό των standards για την απεικόνηση των ίδιων δεδομένων. Τα web services επιτρέπουν την απρόσκοπτη ενσωμάτωση διαφορετικών εφαρμογών που εκπροσωπούν διαφορετικά και, κατά καιρούς, ανταγωνιστικά πρότυπα. Τα web services θα επεκτείνουν τις επιχειρήσεις υγείας, με το να κάνουν τις δικές τους υπηρεσίες διαθέσιμες στους άλλους. Τα web services θα επεκτείνουν το χρόνο ζωής των ήδη υπαρχόντων λογισμικών με το να εκθέτουν τις προηγούμενες υπάρχουσες λειτουργίες ως web services. Παρόλαυτα είναι γενικά αποδεκτό, οτι τα web services προσφέρουν μειωμένη χρήση, αν δεν περιγραφεί και εξηγηθεί η σημασιολογία τους. Υπάρχουν δύο εκδοχές για την προτυποποιήση της υγείας. Η πρώτη βασίζεται σε μήνυμα όπως η HL7(Health Level 7). H άλλη είναι βασισμένη στην Electronic Health Care Record (EHR) όπως η CEN ENV13606 και η GEHR Πρότυπες πληροφορίες υγείας και web services Ο κύριος στόχος του HL7 είναι να παρέχει τυποποιήσεις για την ανταλλαγή των δεδομένων ανάμεσα σε υπολογιστικές εφαρμογές υγείας. Η τυποποίηση αναπτύσεται με την προυπόθεση οτι ένα γεγονός στον κόσμο της υγείας, που καλείται trigger event,προκαλεί ανταλλαγή μηνυμάτων ανάμεσα σε ένα ζεύγος εφαρμογών. Όταν ένα γεγονός συμβαίνει σε σε ένα σύστημα συμβατό με HL7,ετοιμάζεται ένα μήνυμα HL7 με το να συλλέγει τις απαραίτητες πληροφορίες από τα οικέια συστήματα και μεταφέρεται στον αιτούντα,συνήθως με την μορφή EDI. Για παράδειγμα ένα trigger event μπορεί να συμβεί όταν ένας ασθενής είναι δεκτός και τα στοιχεία του συλλέγονται και και στέλνονται σε έναν αριθμό από άλλα συστήματα. 92

94 Καθώς η HL7 ορίζει γεγονότα που βασίζονται σε μηνύματα, κάποιος μπορεί να σκεφτεί οτι μπορούν να προσκοληθούν σε web services. Αυτό μπορεί να καταλήξει σε αρκετές ανεπάρκειες. Τα μυνήματα εισόδου και εξόδου που ορίζονται για HL7 είναι συνήθως πολύπλοκα που περιέχουν αναρίθμητα τμήματα διαφορετικών τύπων και επιλογών. Επίσης όλες οι σημασιολογίες για την επιχειρησιακή λογική και την δομή του εγγράφου,είναι ο κωδικας πυρηνας του μυνήματος. Αυτο δηλαδή υποδεικνύει ότι ό,τι αφορά τα web services πρέπει να είναι συμβατό με HL7, έτσι ώστε το περιεχόμενο των παραμέτρων εξόδου που επιστρέφεται απο την υπηρεσία να βγάζει νόημα. Για να ορίσουμε την διακριτότητα των web services αναφερόμαστε στα πρόπυπα που βασίζονται στο Electronic Healthcare Record (EHR) από τα κύρια τυποποιημένα σώματα όπως CEN και GEHR. Αυτά τα πρότυπα ορίζουν μεταδεδομένα για το EHR μέσα από ουσιώδη στοιχεία (meaningful components). Όταν ένα web service είναι σχεδιασμένο να ανακτά μια πολύ καλή διακριτότητα στα ουσιώδη στοιχεία ενός EHR, μπορεί να είναι σημασιολογικά ορισμένο ως τέτοιο. Με άλλα λόγια, προτείνεται να ορίσουμε τις σημασιολογίες πολύ καλών διακριτών web services, μέσα από τις σημασιολογίες των μηνυμάτων που φέρουν. Με αυτό τον τρόπο, ενα ιατρικό ισντιτούο, ας πούμε νοσοκομείο Α,σύμφωνο με το HL7, μπορεί να ορίσει τα web services του σύμφωνα με την συμορφούμενη οντολογία του HL7. Από την άλλη πλευρά ένα ας πούμε νοσοκομείο Β, σύμφωνο με τον CEN μπορεί να ορίσει τα web services του σύμφωνα με μια συμφωνούμενη οντολογία CEN. Αυτό μας δίνει τα εξής πλεονεκτήματα: Οι σημασιολογίες των web services μπορούν να χαρτογραφηθούν μεταξύ διαφόρων προτύπων EHR για να επιτευχθεί διαλειτουργικότητα. Η επαναχρησιμοποίηση των web services βελτιώνεται. Ένα web service δεν μπορεί μόνο να επικαλεστεί από άλλες εφαρμογές, που χρειάζονται μόνο αυτό το κομμάτι δεδομένων, αλλά μπορεί να χρησιμοποιηθεί ως στοιχείο μιας μεγαλυτερης συνολικής επιχείρησης. 93

95 Λειτουργική οντολογία των web services Καθώς η HL7 έχει αρχίσει μια προσπάθεια να κατηγοριοποιήσει τα γεγονότα στον τομέα της υγείας λαμβάνοντας υπόψιν την λειτουργικότητα των υπηρεσιών, προτείνεται να χρησιμοποιηθεί αυτή η ταξινόμηση σαν βάση για μια λειτουργική υπηρεσία οντολογίας. Ο όρος οντολογία, που προέρχεται απο την φιλοσοφία όπως περιγράφεται από τους (Kivela and Hyvonen, 2002) and (Smith and Welty, 2001), υιοθετήθηκε από τους ερευνητές για να περιγράψουν επίσημα κυρίαρχα μοντέλα. Πολλοί ορισμοί της οντολογίας αναπτύχθηκαν τις τελευταίες δεκαετίες. Ο πιο συχνός ορισμός δόθηκε το 1993 από τον Gruber, σύμφωνα με τον οποίο η οντολογία είναι ένας ρητός καθορισμός της εννοιολογικοποίησης. Με άλλα λόγια, μια οντολογία είναι ένα κυρίαρχο μοντέλο που περιγράφεται επακριβώς. Η HL7 προτυποποίηση κατηγοριοποιεί τα ΗL7 γεγονότα στις παρακάτω κατηγορίες: Διοίκηση ασθενών, είσοδος προτεραιότητας, αναμονή, οικονομική διαχείρηση, αναφορά παρακολούθησης, κύρια αρχεία, διαχείρηση ιατρικών πληροφοριών, προγραμματισμός, αναφορά ασθενών και φροντίδα ασθενών. Αυτές οι κατηγορίες 94

96 επίσης έχουν υποκατηγορίες. Μια μερική λειτουργική οντολογία ενός web service βασισμένο σε HL7 δίνεται στο παραπάνω σχήμα (fig.2). Ψάχνοντας για τα σωστά web services, οι καταναλωτές μπορούν να συμβουλευτούν αυτή την οντολογία για να βρουν τις υπηρεσίες που ψάχνουν χρησιμοποιώντας τις λειτουργικές σημασιολογίες της υπηρεσίας. Επιπρόσθετα, η ανακάλυψη υπηρεσιών διευκολύνεται από την ενσωμάτωση των κόμβων αυτής της οντολογίας στο μητρώο της υπηρεσίας Oντολογία μηνυμάτων των web services Ένα web service στον τομέα της υγείας συνήθως έχει προσβαση ή ανανεώνει ένα ηλεκτρονικό αρχείο υγείας, μέρος του ΕΗR και αποτελούν τις παραμέτρους της υπηρεσίας. Ένα ηλεκτρονικό αρχείο υγείας μπορεί να γίνει πολύ περίπλοκο με δεδομένα να έρχονται από ποικίλα συστήματα όπως εργαστηριακά tests διαγνώσεις κλπ. Τυποποιήσεις που βασίζονται στο ηλεκτρονικό αρχείο υγείας Electronic Healthcare Record (EHR) όπως το HL7 CDA (Clinical Document Architecture), GOM ( GEHR Object Model ) και CEN s ENV13606 σκοπεύουν να διευκολύνουν την διαλειτουργικότητα μεταξύ των συστημάτων πληροφορίας υγείας. Παρόλαυτα δεν στοχεύουν στην απευθείας διαλειτουργικότητα μηχανής με μηχανή. Γιαυτό, αυτά τα πρότυπα δεν ορίζουν μια μονολιθική ΕΗR αρχιτεκτονική, αλλά παρέχουν εννοιολογικά building blocks ή meaningful components, με τα οποία κάθε μοντέλο μπορεί να αναπαρασταθεί μέσα στο τυποποιημένο πλαίσιο. Αυτό παρέχει ελαστικότητα με το να επιτρέπει στο ίδιο building block να συντάσσεται διαφορετικά απο δύο διαφορετικά ινστιτούτα, που με τη σειρά του καταλήγει σε διαφορετικές δομές μηνυμάτων. Αυτό απαιτεί δομημένες και σημασιολογικές χαρτογραφήσεις μεταξύ των στοιχείων των μηνυμάτων με σκοπό την αυτοματοποίηση της διαλειτουργικότητας τους. Σε αυτή την αρχιτεκτονική, ιατρικά ινστιτούτα παρέχουν web services για να έχουν πρόσβαση στα στοιχεία του EHR και να ανακτήσουν τους κόμβους του κλινικού σεναρίου οντολογίας. Οι σημασιολογίες των παραμέτρων των υπηρεσιών ορίζονται χρησιμοποιώντας οντολογίες μηνυμάτων. Όταν μαρκάρονται σημασιολογικά, αυτά τα στοιχειώδη web services σφραγίζονται με την οντολογία λειτουργίας της υπηρεσίας. Για παράδειγμα ένα web service που ανακτά πληροφορίες Diagnosis μπορεί να σφραγισθεί με το GetClinicalInformation κόμβο, όπως φαινεται και στο fig.2. Τα ιατρικά ινστιτούτα μπορούν να αναπτύξουν τις δικές τους οντολογίες μυνημάτων για να σχολιάσουν τα web services τους. Παρολαυτά αν αυτές οι οντολογίες από το κλινικό οντολογικό σενάριο που βασίζεται σε διακεκριμένα ιατρικά πρότυπα όπως HL7, CEN, TC251, ISO TC215 και GEHR, η οντολογική χαρτογράφηση διευκολύνεται. 95

97 Χαρτογράφηση οντολογίας Παρόλο που η αναπαράσταση των κλινικών συνταγών, που ορίζονται από διαφορετικές προσπάθειες προτυποποίησης, μπορεί αρχικά να καταλήξει σε ανόμοιες κλινικές οντολογίες, ορίζοντας αυτές μέσω οντολογικών γλωσσών, ανοιγεται ο δρόμος της χαρτογράφησης τους μέσω κανόνων χαρτογράφησης. Θεωρούμε τις δυο οντολογικές μερικές κλινικές συντaγές HL7 και ENV13606 που φαίνονται στο fig.3. Όταν αυτές οριστούν, η χαρτογράφηση μεταξύ τους μπορεί να επιτευχθεί χρησιμοποιώντας την κατάλληλη οντολογική χαρτογράφηση όπως η MAFRA. Η MAFRA χρησιμοποιεί ένα συστατικό που ορίζει τις σχέσεις και τις αλλαγές μεταξύ 96

98 οντολογιών. Γενικά μιλώντας, η οντολογική χαρτογράφηση έχει τρεις βασικές διαστάσεις: ανακάλυψη, αναπαράσταση και εκτέλεση. Ανακάλυψη που είναι η εξαγωγή των σημασιολογικών σχέσεων ομοιότητας μεταξύ ενοτήτων των οντολογιών, επιτυγχάνεται χρησιμοποιώντας υπάρχουσες προσεγγίσεις μέτρησης ομοιότητας,όπως αλγοριθμοι που βασίζονται στην γλωσσολογία. Για την αναπαράσταση των ομοιοτήτων με επίσημο τρόπο,η MAFRA παρέχει μια μεταοντολογία που ονομάζεται σημασιολογική γέφυρα οντολογίας, Semantic Bridge Ontology (SBO). Σημασιολογικές γέφυρες στην SBO ενσωματώνουν τις απαιτούμενες πληροφορίες για να μεταφράσουν μια πηγή οντότητας (σενάριο, σχέση, κυριότητα) σε ένα στόχο οντότητας. Οι σημασιολογικές γέφυρες παρέχουν προδιαγραφές χαρτογράφησης απο 1-1 σε m-n και επιτρέπουν πολύπλοκες δομές χαρτογράφησης όπως εξειδίκευση, άντληση,σύνθεση και εναλλακτικές λύσεις. Η MAFRA έχει δυο θεμελιακές σημασιολογικές γέφυρες: γέφυρα σεναρίου και ιδιόκτητη γέφυρα. Η γέφυρα σεναρίου ορίζει την σημασιολογική ισότητα μεταξύ δυο οντολογικών κλάσεων. Στο βήμα εκτέλεσης ένα στιγμιαίο σενάριο του οντολογικού στόχου δημιουργείται για κάθε σενάριο πηγής, όταν τα δυο σενάρια σχετίζονται μέσω μιας γέφυρας σεναρίου. Με τον ίδιο τρόπο, μια γέφυρα ιδιοκτησίας ορίζει την ισότητα μεταξύ των ιδιοτήτων πηγής και στόχου. Όταν οι σχέσεις μεταξύ δυο οντολογιών έχουν οριστεί μέσω σημασιολογικών γεφυρών, οι περιπτώσεις της οντολογικής πηγής μπορούν να μεταμορφωθούν σε οντολογικές περιπτώσεις στόχου με την αξιολόγηση των σημασιολογικών γεφυρών στο βήμα της εκτέλεσης. Σε αυτό το βήμα, πρωτίστως, οι περιπτώσεις της οντολογίας στόχου δημιουργούνται, εάν οι συνθήκες των σχετιζόμενων γεφυρών σεναρίου είναι σωστές. Αφού έχουν δημιουργηθεί όλες οι περιπτώσεις, εκτελούνται οι γέφυρες ιδιοκτησίας και οι ιδιότητες των στιγμιαίων στόχων ορίζονται με βάση αυτές. Αυτό το βήμα χρησιμοποιείται για την μετατροπή μιας οντολογίας ιατρκού ινστιτούτου (που για παράδειγμα βασίζεται στο ENV13606) σε ένα άλλο (παράδειγμα HL7) με την απόκτηση των απαραίτητων σημασιολογικών γεφυρών από την χαρτογράφηση των γνήσιων οντολογιών που βασίζονται στο ENV13606 και στο HL7. 97

99 Αξιοποίηση σημασιολογικά σχολιασμένων web services Σε αυτήν την παράγραφο, πριγράφεται πως χρησιμοποιούνται οι ορισμένες σημασιολογίες στην εύρεση του κατάλληλου web service. Θεωρούμε το ιατρικό ινστιτούτο Α που χρειάζεται τις κλινικές πληροφορίες ενός ασθενή που είναι καταχωρημένες στο ιατρικό ινστιτούτο Β. Όπως έχει αναφερθεί,υπάρχει η ευεληξία στα ιατρικά ινστιτούτα, να ορίσουν τις δικές τους κλινικές οντολογίες μηνυμάτων στα υπάρχοντα πρότυπα. Ως εκτούτου το ιατρικό ινστιτούτο Α μπορεί να ορίσει τις κλινικές πληροφορίες όπως παρουσιάζονται στο fig.5 part A, 98

100 σε αντιδιαστολή με τις κλινικές πληροφορίες που ορίζονται απο HL7 fig.3 και το ιατρικό ινστιτούτο Β μπορεί να ορίσει το ίδιο σενάριο οπως φαίνεται στο fig.5 part B σε αντιδιαστολή με τα κλινικά σεναάρια που ορίζονται απο το ENV Στην πραγματικότητα, αυτά είναι μέρος της οντολογίας μηνυμάτων των ινστιτούτων, που χρησιμοποιούνται στην ανταλλαγή κλινικών πληροφοριών. Παρατηρήστε οτι και τα δυο building blocks των μηνυμάτων οντολογιών καθώς και οι ιεραρχικές δομές τους ειναι διαφορετικές. Ως εκτούτου οταν το ιατρικό ινστιτούτο Α ζητάει τις ιατρικές πληροφορίες από το ιατρικό ινστιτούτο Β, είναι απαραίτητη και η δομική και η σημασιολογική μετατροπή των αρχείων. Οι σημασιολογιές χαρτογραφήσεις μεταξύ δυο σεναρίων σε αυτές τις δυο οντολογίες μηνυμάτων, χειρίζονται με την χρησιμοποίηση χαρτογράφων οντολογίας όπως MAFRA, για την επεξεργασία των σημασιολογικών γεφυρών, ορισμένων μεταξύ των σεναρίων κλινικών οντολογιών. Για παράδειγμα, όπως φαίνεται στο fig.3, Allergy State (DF03) στο ENV-13606, ανταποκρίνεται στο Allergies (AL1) του HL7. Αν το ιατρικό ινστιτούτο Β παρέχει τα web services για την πρόσβαση στο Test Results, Allergy State και Diagnosis,όταν οι σημασιολογικές αντιστοιχίες μεταξύ των κλινικών σεναρίων έχουν καθοριστεί και εξηγηθεί όπως παραπάνω,οι δομημέμες χρτογραφήσεις αντιμετωπίζονται εύκολα ως εξής: μετά την ανακάλυψη, τα web services ανακτούν Test Results, Allergy State και Diagnosis, το αποτέλεσμα που ζητήται απο το ιατρικό ινστιτούτο Α μπορεί να εξασφαλιστεί. Εδώ υποθέτουμε οτι οι σημασιολογικές χαρτογραφήσεις μεταξύ αυτών των δυο σεναρίων έχουν ήδη οριστεί μέσω σημασιολογικών γεφυρών στη MAFRA, που είναι Allergy State σε Allergies ; και Diagnosis σε Diagnosis. Αν δεν υπάρχουν σημασιολογικές αντιστοιχίες μεταξύ των δυο σεναρίων, πρέπει να εφαρμοστεί η ίδια διαδικασία αποσύνθεσης μεχρι να επιτευχθεί λεπτομερέστερη αναλυτικότητα των σημασιολογικών στοιχείων. Αφότου τα web services σχολιάζονται με οντολογίες μηνυμλατων που βασίζονται σε κλινικά οντολογικά σενάρια, είναι δυνατόν να αναγνωρίσουμε τα web services, παρέχοντας την ζητούμενη πληροφορία όπως Diagnosis στα μητρώα των υπηρεσιών. Γιαυτό το λόγο τα tmodels που σχετίζονται με τους κόμβους των κλινικών σεναρίων οντολογίας, χρησιμοποιούνται για να βρουν σχετικές υπηρεσίες στο UDDI. Στο ebxml, το κλινικό σενάριο οντολογίας υπάρχει και οι σχετικοί κόμβοι αυτής της οντολογίας όπως Diagnosis:DD01 χρησιμοποιούνται για να βρουν τις ζητούμενες υπηρεσίες Σημασιολογικός συνυπολογισμός των web services σε ιατρικές υπηρεσίες Μολονότι η ταξινόμηση των web services μέσα πο σημασιολογικές κατηγορίες των δεδομένων που ανακτούν διευκολύνει την ανακάλυψη των υπηρεσιών που δίνουν ένα συγκεκριμένο μέρος των δεδομένων EHR, μπορεί να μην είναι πάντα εύκολο να βρεθεί μια υπηρεσία που να παραδίδει ακριβώς τα ζητούμενα δεδομένα. Για 99

101 παράδειγμα, ενα ιατρικό ινστιτούτο μπορεί να ζητήσει πληροφορίες Diagnosis, ενώ το ινστιτούρο στόχος μπορεί να παρέχει τις πληροφορίες διάγνωσης σαν μέρος ενός άλλου κλινικού σεναρίου. Αυτό μπορεί να χρειαστεί πιο πολύπλοκα συσσωματώματα των web services. Με άλλα λόγια, όταν προσπαθούμε να συνθέσουμε ένα web service από υψυλής αναλυτικότητας web services σύμφωνα με την δομή και τις σημασιολογίες των σύνθετων εξωτερικών παραμέτρων του web service, μπορεί να μην βρούμε πάντα κομματιασμένα web services για να παράγουμε το ζητούμενο αποτέλεσμα. Σαν παράδειγμα, θεωρούμε την περίπτωση όπου το ιατρικό ινστιτούτο Α ζηταέι κλινικές πληροφορίες όπως φαίνεται και στο fig.5 part A,αλλά το ιατρικό ινστιτούτο Β παρέχει web services μόνο για να ανακτά Encounter και Ongoing Problem πληροφορίες ενός ασθενή fig.5. Δεδομένης της σημασιολογικής δομής των σεναρίων Encounter και Ongoing Problem, είναι δυνατόν να κατασκευάσουμε το σενάριο Clinical Information που έχει ζητηθεί από το ιατρικό ινστιτούτο Α, μέσα από ένα σύνολο Semantic Aggregation Operators (SAO). Για παράδειγμα μπορούμε να κατασκευάσουμε το σενάριο Clinical Information που ζητήται από το ιατρικό ινστιτούτο Α ως εξής : ClinicalInformation:A = (ClinicalInformation:A s Encounters:B ) s ClinicalInformation:A s OngoingProblems:B). Καλούμε τα web services που έιναι σημασιολογικά συσσωματώματα άλλων web services σαν εικονικά web services (VWS). Αυτά τα web services είναι αφηρημένα, δεν είναι εκτελέσιμα, παρά μόνο διευκρινίζουν πως να αντλήσουμε το ζητούμενο αποτέλεσμα ενός πολύπλοκου web service από άλλα web services μέσω του SAO. Στο παράδειγμα που αναφέρθηκε, το ιατρικό ινστιτούτο Α χρησιμοποιεί ένα εικονικό web service για να ανακτήσει τις πληροφορίες απο το ιατρικό ινστιτούτο Β Semantic Aggregation Operators (SOA) Συστήνεται ένας αριθμός από SOA με στόχο την κατασκευή εικονικών web services. Αυτά είναι τα εξής : VWS1( s)vws2 σημασιολογική ένωση : αυτή η λειτουργία χρησιμοποιείται για την κατασκευή ενός VWS, που παρέχει την ένωση των αποτελεσμάτων των VWS1 και VWS2. VWS1( s)vws2 σημασιολογικά υπερπλήρεις : αυτή η λειτουργία χρησιμοποιείται για την κατασκευή ενός VWS, που παρέχει τα συνδυασμένα αποτελέσματα των VWS1 και VWS2, με την συλλογή όλων των σεναρίων που λαμβάνουν χώρα και στα δυο και αγνοώντας αν τα σενάρια είναι σημασιολογικά ίσα ή οχι. 100

102 VWS1( s)vws2 σημασιολογική διατομή : αυτή η λειτουργία χρησιμοποιείται για την κατασκευή ενός VWS, που παρέχει την σημασιολογική ισότητα που προερχεται και απο το VWS1 και απο το VWS2. VWS1( s)vws2 σημασιολογική διαφορά : αυτή η λειτουργία χρησιμοποιείται για την κατασκευή ενός VWS, που μας δίνει τα σενάρια που παρέχονται από το VWS1, χωρίς την σημασιολογική ισότητα των σεναρίων που προέρχονται απο το VWS2. VWS1(>>s)VWS2 σημασιολογικό περιεχόμενο : αυτή η λειτουργία μπορεί να χρησιμοποιηθεί για να ελέγξει αν τα σενάρια που παρέχονται από το VWS1 είναι ένα υπερσύνολο των σεναρίων που προέρχονται απο το VWS2. Δεδομένων αυτών των SAO, χονδροειδή web services μπορούν να συνθεθούν απο υψυλότερης αναλυτικότητας υπηρεσίες, ακόμα και αν δεν υπάρχει υψυλότερης αναλυτικότητας υπηρεσίας που να ανακτά ακριβώς τα ζητούμενα δεδομένα. Για παράδειγμα, όπως φαίνεται στο fig.5 το web service που παρέχει πληροφρίες Encounters ενλος ασθενή, κατατάσεται με το clinical concepts στο αποτέλεσμα του όπως Problem:DD02, TestResults:DTC08, Diagnoses:DD01, και CarePlan:DTC12 Τα αποτελέσματα αυτών των συσσομάτων πχ. εικονικά web services, είναι επίσης επαναχρησιμοποιούμενα στοιχεία. Εισάγωνται σαν περιπτώσεις σε μια υπηρεσία λειτουργικής οντολογίας μαζί με τις περιγραφές τους. Για παράδειγμα η εικονική υπηρεσία που ανακτά κλινικές πληροφορίες ενός ασθενή στο προαναφερθέν παράδειγμα, αποθηκεύεται στιγμιαία σαν κόμβος GetClinicalInformation της υπηρεσίας λειτουργικής οντολογίας που παρουσιάζεται στο fig.2. Όταν αυτά τα δυο νοσοκομεία επικοινωνήσουν πάλι, αυτοί οι ορισμοί για τα VWS μπορούν να επαναχρησιμοποιηθούν. Παρέχοντας τέτοια εικονικά web services και δημιουργώντας μια αποθήκη από VWS, σε βάθος χρόνου, μπορεί να βελτιώσει την διαλειτουργικότητα των συστημάτων ιατρικών πληροφοριών. Παρόλο που αυτά τα VWS μπορεί να φαίνονται ως αμφίπλευρες συμφωνίες μεταξύ ινστιτούτων, μπορούν να χρησιμποιηθούν για την δημιουργία μιας ευρύτερης κοινωνίας μέσω μεταβατικών συμφωνιών Συσχετισμός οντολογιών web services με μητρώα web services Καθώς οι σημασιολογίες των web services έχουν οριστεί, είναι απαραίτητο να τις συσχετίσουμε με τις υπηρεσίες που διαφημίζονται στα μητρώα υπηρεσιών. 101

103 Υπάρχουν δύο σημεία κλειδιά σε αυτήν την διαδικασία, η πρώτη είναι που θα αποθηκευτούν οι οντολογίες. Η UDDI δεν προβλέπει έναν μηχανισμό για την αποθήκευση μιας οντολογίας μέσα στο μητρώο. Το ebxml, από την άλλη πλευρά μέσα από τον ιεραρχικά ταξινομημένο μηχανισμό επιτρέπει κύριες ειδικές οντολογίες να αποθηκεύονται στα μητρώα. Σημειώστε οτι για μητρώα UDDI κύριες ειδικές οντολογίες μπορούν να αποθηκευτούν απο τα πρότυπα σώματα που τα ορίζουν και ο εξυπηρετητής, οπου αναφέρεται η υπηρεσία, μπορεί να φιλοξενήσει την σημασιολογική περιγραφή της στιγμιαίας υπηρεσίας. Το δεύτερο σημείο κλειδί είναι πως θα συσχετιστούν οι υπηρεσίες που διαφημίζονται στο μητρώο με τις σημασιολογίες που ορίζονται μέσω μιας οντολογίας. Ο μηχανισμός αυτός είναι η χρήση των tmodels και οι κατηγορίες με τις καταχωρήσεις μητρώου. Τα tmodels παρέχουν την δυνατότητα να περιγράψουν, συμβατά με την ταξινόμηση, οντολογίες ή ελεγχόμενα λεξιλόγια. Γιαυτόν τον λόγο, αν τα tmodels συσχετίζονται με τους κόμβους της οντολογίας (παράδειγμα στο fig.2) και αν οι υπηρεσίες βάλουν τα ανταποκρινόμενα tmodels στις κατηγορίες τους, τότε είναι πιθανή η εύρεση υπηρεσιών σύμφωνες με τις σημασιολογίες που δίνονται σε έναν συγκεκριμένο κόμβο της οντολογίας. Ένα μητρώο ebxml από την άλλη πλευρά, επιτρέπει τον ορισμό των σημασιολογιών μέσω δυο μηχανισμών:πρώτα, επιτρέπει στις ιδιότητες των στοιχείων των μητρώων να ορισθούν μέσω slots, έπειτα, μεταδεδομένα μπορούν να αποθηκευτούν στο αρχείο μέσω μιας ClassificationScheme. Επιπλέον τα στοιχεία του Classification, ρητα, συνδέουν τις υπηρεσίες που διαφημίζονται με τους κόμβους ενός ClassificationScheme. Αυτή η πληροφορία μπορεί μετά να χρησιμοποιηθεί για την ανακάλυψη των υπηρεσιών εκμεταλευόμενοι τους μηχανισμούς της ebxml Αρχιτεκτονική Artemis Το project Artemis αντιμετωπίζει το πρόβλημα της διαλειτουργικότητας στον τομέα της υγείας, όπου οργανισμοί έχουν ιδιόκτητα συστήματα εφαρμογών για να έχουν πρόσβαση στα δεδομένα. Για την ανταλλαγή πληροφοριών υπάρχουν διαφορετικά πρότυπα όπως HL7, GEHR ή CEN s ENV Ο σκοπός του Artemis είναι να επιτρέπει στους οργανισμούς να έχουν τα ιδιόκτητα τους συστήματα και να εκθέτουν την λειτουργικότητα τους μέσω web services. Επίσης προτείνεται η περιγραφή των ανταλλασσόμενων δεδομένων να βασίζεται στην οντολογία. Ένας από τους σκοπούς της χρήσης οντολογιών είναι η μείωση εννοιολογιών και τερμινολογικών διαφορών ανάμεσα στα πρότυπα μεταδιδόμενα δεδομένα στο χώρο της υγείας μέσω σημασιολογικής διαμεσολάβησης. 102

104 Οι διαμεσολαβητές υπάρχουν για να επεξεργάζονται δεδομένα από πιθανών πολλές πηγές δεδομένων, και να τα προετοιμάζουν για την κατάλληλη χρήση απο τις εφαρμογές Artemis - διαμεσολαβητής στην P2P αρχιτεκτονική Στο Artemis, ιατρικά ινστιτούτα επικοινωνούν μεταξύ τους μέσω διαμεσολαβητών που λύνουν τις διαφορές τους διμερώς. Οι ακόλουθες παρατηρήσεις αφορούν στην οργάνωση των μεσολαβητών: Οι διαμεσολαβητές πρέπει να έχουν μια κατανεμημένη αρχιτεκτονική για να παρέχουν επεκτασιμότητα. Όταν ένα ιατρικό ινστιτούτο πχ Α θέλει να επικοινωνήσει με ένα άλλο ιατρικό ινστιτούτο πχ Β, πρέπει να μπορεί να εντοπίσει αυτόματα τον διαμεσολαβητή του Β. Πολλά πλεονεκτήματα προκύπτουν, όταν οργανώνονται λογικά αρκετά ινστιτούτα και χρησιμοποιούν μόνο έναν διαμεσολαβητή. 103

105 Με αυτά υπόψη, οι διαμεσολαβητές σχεδιάζονται και αναφέρονται ως υπερκόμβοι JXTA. JXTA είναι ένα ανοικτής πηγής project που υποστηρίζεται και διαχειρίζεται από την Sun Microsystems. Κυρίως το JXTA είναι ένα σύνολο από XML προτώκολλα για την εφαρμογή P2P λειτουργειών. Στην αρχιτεκτονική JXTA υπερκόμβων, κόμβοι σε ένα σύνολο κόμβων επικοινωνούν με τους υπερκόμβους τους για να διαφημίσουν τις δυνατότητές τους αλλά και να ψάξουν και για άλλους κόμβους Αrtemis στοιχεία διαμεσολαβητή Γενικά μιλώντας, η σημασιολογική χαρτογράφηση είναι η διαδικασία όπου δύο οντολογίες σχετίζονται σημσιολογικά σε εννοιολογικό επίπεδο και οι στιγμιαίες οντολογικές πηγές μεταμορφώνονται σε οντολογικές οντότητες στόχων σύμφωνα με αυτές τις σημασιολογικές σχέσεις. Στην Artemis οι οντολογίες πηγής και στόχου ανήκουν στα δυο ιατρικά ινστιτούτα που θέλουν να ανταλλάξουν πληροφορίες. Παρόλαυτα, η χαρτογράφηση αυτών των δυο οντολογιών ολοκληρώνεται μέσω των οντολογιών αναφοράς που υπάρχουν στον διαμεσολαβητή: η γενική λειτουργεία της υπηρεσίας και υπηρεσίες μυνημάτων οντολογίας. Ο διαμεσολαβητής λύνει τις σημασιολογικές διαφορές μεταξύ οντολογίες πηγής και στόχου με το να χρησιμοποιεί αυτά και και σημασιολογικές γέφυρες οντολογίας. Πρέπει να σημειωθεί οτι εφόσον όλες οι εμπλεκόμενες οντολογίες με κάποιο τρόπο συνδέονται με βασικά πρότυπα υγείας, η υπηρεσία διαμεσολάβησης είναι ευκολότερη και πιο αποτελεσματική. Επίσης λυμένες σημασιολογικές διαφορές αποθηκεύονται ως εικονικα web services (virtual web services VWS) για επαναχρησιμοποίηση. Η αρχιτεκτονική διαμεσολαβητή, όπως φαίνεται στο fig.9 που ακολουθεί, περιλαμβάνει τα ακόλουθα στοιχεία : Οντολογικός εξυπηρετητής : περιλαμβάνει τις επόμενες οντολογίες: λειτουργικότητα υπηρεσίας και υπηρεσία μυνημάτων οντολογίας. Κάθε ιατρικό ινστιτούτο μπορεί να αναπτύξει τις δικές του λειτουργικές υπηρεσίες και υπηρεσίες μηνυμάτων οντολογίας βασισμένα σε υπάρχοντα πρότυπα ιατρικών πληροφοριών. Η ελάχιστη απαίτηση είναι ο σχολιασμός των υπηρεσιών τους μέσω τέτοιων οντολογιών. Το υποσύστημα των εικονικών web services χειρίζεται την δημιουργία εικονικών web services (VWSs) για να παρέχει πολύπλοκα συσσωματώματα web services. Η δημιουργία των VWSs διαμορφώνεται ανάλογα με την χαρτογράφηση μεταξύ των οντολογιών στις σημασιολογικές εισόδους και εξόδους των web services. Σημασιολογικός επεξεργαστής: μπορεί να υπάρχει πάνω από μια λειτουργικότητα υπηρεσίας και υπηρεσία ομηνυμάτων οντολογίας στον διαμεσολαβητή και ο διαμεσολαβητής δημιουργεί τις χαρτογραφήσεις μεταξύ τους χρησιμοποιώντας τις δικές του πρότυπες οντολογίες βασισμένες στα πρότυπα της ιατρικής. Στην Artemis η MAFRA χρησημοποιείται για να αναπαραστήσει τις χαρτογραφήσεις και να μετατρέψει τις περιπτώσεις οντολογίας. MAFRA χρησημοποιεί τη σημασιολογική γέφυρα οντολογίας, για 104

106 να ορίσει τις χαρτογραφήσεις. Ο διαμεσολαβητής αποθηκεύει τις προηγούμενες ορισμένες χαρτογραφήσεις μέσω σημασιολογικών γεφυρών. Για παράδειγμα η σημασιολογική ισοτική σχέση μεταξύ του DiagnosticTestResult στο ENV13606 και του ObservationResult στο HL7 μπορεί να αναπαρασταθεί χρησιμοποιώντας σημασιολογικές γέφυρες MAFRA όπως παρκάτω : <a:conceptbridge rdf:id="cb163312"> <a:relatestargetentity rdf:resource= " <a:relatessourceentity rdf:resource= " <a:abstract rdf:resource="&a;true"/> </a:conceptbridge> Μητρώα υπηρεσιών όπως UDDI και ebxml. Τα web services των εμπλεκόμενων ιατρικών κέντρων δημοσιεύονται στα μητρώα UDDI ή ebxml του διαμεσολαβητή. Στοιχείο θεσμοθέτησης του web service χειρίζεται την ανάμειξη των web services και μεταδίδει τα αποτελέσματά τους. Στοιχέιο των υπηρεσιών υπερκόμβων περιέχει τις υπηρεσίες που παρέχουν την επικοινωνία με άλλουε διαμεσολαβητές σε μια δομή P2P. Βασικά αυτές οι υπηρεσίες εκτελούτα τα πρωτόκολλα JXTA Ο πελάτης διεπαφής χειρίζεται την επικοινωνία των ιατρικών ινστιτούτων με τον διαμεσολαβητή χρησιμοποιώντας πρωτόκολο πελάτη - διαμεσολαβητή. 105

107 Αποτίμηση Artemis - συμπεράσματα Τα σημσιολογικά web services πρέπει να επευθύνονται σε έναν τομέα με συγκεκριμένο τρόπο,καθώς διαφορετικοί τομείς έχουν πολύ διαφορετικές ανάγκες,έχουν αναπτυχθεί πολύ διαφορετικά και οι σημασιολογίες είναι συγκεκριμένες πληροφοριές τομέα. Μέχρι τώρα, παρουσιάσαμε μια καινούρια αρχιτεκτονική για την ανακάλυψη των σημασιολογικών web services στον τομέα της υγείας. Τα αποτελέσματα είναι τα παρακάτω : Για την παροχή διαλειτουργικότητας στον τομέα της υγείας, παρουσιάσαμε διαάφορες εφαρμογές υγείας αποκαλωντας τες ως σημασιολογικά εμπλουτισμένα web services. Απόσο γνωρίζουμε μέχρι τώρα το Artemis είναι η πρώτη προσπάθεια για την χρήση σημασιολογικά εμπλουτισμένων web services στον τομέα της υγείας. Στην πραγματικότητα, πολύ πρόσφατα αρχισαν να χρησιμοποιούνται στον τομέα της υγείας τα web services. Μια πρωτοβουλία επιχείρησης να χρησιμοποιήσει web services είναι η Integrating the Healthcare Enterprise (IHE). Η IHE έχει ορίσει μερικά βασικά web services όπως Retrieve Information for Display Integration Profile (RID). Ακόμα, αφού η IEH δεν απευθύνεται σε σημασιολογικά θέματα,για να χρησιμοποιήσουμε IEH web services, είναι απαραίτητη η προσαρμογή στις προδιαγραφές τους,με το να καλούμε τα web services με το όνομα που τους έχει καθοριστεί και παρέχοντας τα μυνήματα όπως δομούνται στις προδιαγραφές τους. Ένα άλλο αποτέλεσμα είναι η αναγνώριση της ανάγκης για λειτουργικότητα της υπηρεσίας και υπηρεσίες μυνημάτων οντολογίας να σχολιάζουν σημασιολογικά τα web services. Η σημασιολογική πληροφορία που χρειάζεται βασίζεται στα υπάρχοντα πρότυπα ιατρικής. Η HL7 αποτελεί την βάση της οντολογικής υπηρεσίας λειτουργικότητας αφού η HL7 έχει κατηγοριοποιήσει τα γεγονότα στον τομέα της υγείας λαμβάνοντας υπόψην την λειτουργικότητα υπηρεσίας. Οργανώνουμε τα meaningful components που ορίζονται από τα πρότυπα του electronic healthcare record ΕΗR όπως HL7 CDA (Clinical Document Architecture), GOM (GEHR Object Model) και CEN TC251 s ENV σε οντολογίες. Μετά χρησιμοποιούμε τέτοιες οντολογίες με την συμμετοχή σημασιολογιών στ μυνήματα και στα έγγραφα που ανταλλάσονται μέσω web services. Παρόλο που προτείνουμε οντολογίες που βασίζονται σε διακεκριμένα πρότυπα υγείας, οι οντολογίες που προτείνουμε είναι απλά για την διευκόλυνση της οντολογικής διαμεσολάβησης. Στην αρχιτεκτονική Artemis τα ιατρικά ινστιτούρα μπορούν να ανπτύξουν τις δικές τους οντολογίες. Παρόλαυτά,όταν αυτές οι οντολογίες βασίζονται σε πρότυπα που αναπτύσονται από την προτυποποίηση της υγείας όπως CEN TC251, ISO TC215, GEHR ή HL7, φαίνεται οτι οι οντολογικές χαρτογραφήσεις διευκολύνονται σε μεγάλο βαθμό μέσω σημασιολογικής διαμεσολάβησης. Η αρχιτεκτονική διαμεσολάβησης στο Artemis βασίζεται στην δομή κόμβοκόμβο για να παρέχει επεκτασιμότητα και να διευκολύνει την ανακάλυψη άλλων διαμεσολαβητών. 106

108 Παρά την ταξινόμηση των web services μέσω σημασιολογικών κατηγοριών των δεδομένων που παρέχουν,που διευκολύνει την ανακάλυψη των υπηρεσιών μέσα σε ένα συγκεκριμένο μέρος δεδομένων της EHR,μπορεί να μην είναι πάντα δυνατόν να βρεθεί μια υπηρεσία που να παραδίδει ακριβώς τα δεδομένα που ζητήθηκαν. Για παράδειγμα ένα ιατρικό ινστιτούτο μπορεί να παρέχει τις πληροφορίες διάγνωσης σαν μέρος ενός άλλου κλινικού σεναρίου. Τότε μπορέι νa χρειαστούν πιο πολύπλοκα συσσωματώματα των web services. Απευθυνόμαστε στα πολύπλοκα συσσωματώματα των web services που μπορεί να χειριστουν, χρησιμοποιώντας το SAO που ορίστηκε παραπάνω. Αναπτύσεται η εφαρμογή ενός πρωτοτύπου σεναρίου για να οδηγήσει την εφαρμογή σε πλήρη κλίμακα που βρίσκεται σε εξέλιξη. Μέχρι τώρα συγκεντωθήκαμε στο μέρος του κλινικού σεναρίου του οντολογικού μυνήματος. Το κύριο κίνητρο για να στρέψουμε την προσοχή μας στο κλινικό σενάριο οντολογίας, είναι οτι τα πρότυπα που βασίζονται στο αρχείο ηλεκτρονικής υγείας προυσιάζουν λεπτομερείς σημασιολογίες. Πρόλαυτα, ο τομέας της υγείας καλύπτει πολλές επιχειρήσεις. Δεν είναι μόνο η σύνδεση ενός νοσοκομείου με τις διάφορες κλινικές, αλλά ένας πίνακας απο εξωτερικές και εσωτερικές υπηρεσίες όπως υπηρεσίας ασφάλειας,οικονομικά ινστιτούτα κι διοικητικές υπηρεσίες. Για αυτόν τον λόγο, υπάρχουν και αλλές πλευρές ιατρικών πληροφοριών που χρειάζονται ν καλυφθούν, όπως οι λογαριασμοί και η ασφάλεια Πειραματική πιλοτική μελέτη σχετικά με την AC (Adaptive Collaboration ) και τις δυνατότητες στην Υγεία Η ανάπτυξη των Πληροφοριών και της Τεχνολογίας των Επικοινωνιών (Information and Communications Technology, ICT), προκαλέσει το ενδιαφέρον καθώς μπορεί να φέρει υγιέστερη και ασφαλέστερη ζωή για κάθε άτομο ξεχωριστά. Η προώθηση της ICT στον ιατρικό τομέα, έχει λάβει μεγάλο ενδιαφέρον καθώς μπορεί να βελτιώσει την ποιότητα και την αποτελεσματικότητα των ιατρικών υπηρεσιών και τη διαχείριση της υγείας. Πιο κάτω, θα συζητηθούν οι δυνατότητες και η επεκτασιμότητα των εφαρμογών των XML Web Services με βάση το σενάριο του Adaptive Collaboration AC (προσαρμοσμένη συνεργασία). Ειδικά, από την εξέταση των πειραματικών πιλοτικών μελετών σχετικά με την XML Web Services, θα θέλαμε να διερευνήσουμε πώς μπορεί να βελτιωθεί η ποιότητα και η αποτελεσματικότητα της υγείας και των υπηρεσιών συντήρησης και περιφερειακών ιατρικών υπηρεσιών μέσα στη κοινωνία. Συνέπειες της μελέτης Σε μια επαρκή κοινωνία, η ανοικτή δικτύωση των πληροφοριών συστημάτων είναι ζωτικής σημασίας και επιτρέπουν στους ανθρώπους να συνεργάζονται με άλλους ανεξάρτητα από την τοποθεσία και το είδος της επιχείρησης. Σε αυτό το περιβάλλον, θα δοκιμάσουμε shifts στην επικοινωνία μας 107

109 τόσο από πλευράς ποσότητας όσο και ποιότητας. Οχι μόνο "από άνθρωπο σε υπολογιστή», αλλά ένα νέο σχήμα "PC-to- PC" θα επεκτείνει τη διάσταση των επικοινωνιών. Οι πληροφορίες που μοιραζόμαστε με τους άλλους δεν θα περιλαμβάνουν μόνο πληροφορίες κειμένου, αλλά και ανόμοιο φάσμα των δεδομένων και πληροφοριών,ακόμα και αυτές τις γνώσεις που είναι αναγκαίες για τη λήψη αποφάσεων. Ως εκ τούτου, ορίζουμε το Adaptive Collaborative Work (ACW) ως ένα σύστημα που αποτελεσματικά συσχετίζει, μοιράζει και αξιοποιεί τα δεδομένα, πληροφορίες και τις γνώσεις στην πανταχού παρούσα κοινωνία, όπου ο όγκος της πληροφορίας αυξάνεται με ταχύτερο ρυθμό. Ο σκοπός της μελέτης αυτής είναι να αποδειχθεί η αποτελεσματικότητα της εφαρμογής των XML Web Services στην ACW από τη σκοπιά των χρηστών. Θα ταξινομεί και θα συσχετίζει αυτόματα διαφορετικές εφαρμογές συστημάτων και υπολογιστικών πόρων που απαιτούνται για την επεξεργασία των αναζητήσεων στο Διαδίκτυο, ανεξάρτητα από τη μορφή του προγράμματος. Ως εκ τούτου, πιστεύουμε ότι με την εφαρμογή αυτής της τεχνολογίας,οι χρήστες μπορούν να είναι σε θέση να εκτελέσουν την διαδικασία χωρίς να ανησυχούν για άγνωστες τεχνολογίες και περίπλοκες διαδικασίες. Απαίτηση και σκοπός της μελέτης Οι βασικές απαιτήσεις για την επίτευξη των ACW είναι οι εξής: οι χρήστες πρέπει να είναι γεωγραφικά διάσπαρτοι και να ανήκουν σε διαφορετικό οργανισμό οι πληροφορίες της γνώσης πρέπει να είναι εύκολες στην αποθήκευση και στην ανάκτηση, καθώς και η μακροπρόθεσμη αποθήκευση πληροφοριών πρέπει να είναι ασφαλής και σίγουρη.η γνώση της πληροφορίας, επίσης πρέπει να είναι διαθέσιμη για υψηλού επιπέδου στατιστική επεξεργασία και ανάλυση θα πρέπει να λειτουργούν αδιάλειπτα, και χρειάζεται να είναι χαμηλού κόστους και υψηλής αξιόπιστίας. Ο σκοπός της μελέτης είναι να συνειδητοποιήσουμε σε πραγματικό χρόνο το ACW περιβάλλον μέσω της κοινοχρησίας δεδομένων. Γι 'αυτό το σκοπό, πραγματοποιήσαμε τα ακόλουθα πειράματα: ένα πείραμα επίδειξης για τη Διαχείριση συστημάτων αποθήκευσης η οποία επιτρέπει στους χρήστες να μοιράζονται πληροφορίες που βρίσκονται στο αποθηκευτηκό idc (Internet Data Center) 108

110 ένα πείραμα επίδειξης για τα στοιχεία διαχείρισης με την εφαρμογή των XML Web Services στην συνεργασία σε πραγματικού χρόνου σύστηματος εργασίας με την κοινοχρησία δεδομένων Πειραματικές μέθοδοι Πρώτον, εξετάσαμε τη δυνατότητα συνεργασίας μεταξύ των εταιρειών, των πανεπιστημίων και των ερευνητικών ιδρυμάτων κατασκευάζοντας ένα περιβάλλον ανταλλαγής πληροφοριών πριν από την εφαρμογή των XML Web Services στα δεδομένα του σύστηματος διαχείρισης που χρησιμοποιεί τις αποθηκευμένες πληροφορίες εντός του IDC (Internet Data Center). Δεύτερον, εξετάσαμε την αποτελεσματικότητα των σύστηματων αποθήκευσης δεδομένων και αξιολογήθηκε εάν οι εξωτερικές εφαρμογές είναι σε θέση για υψηλού επιπέδου χρησιμοποίηση όπως η επάρκεια του να παράγει τη γνώση από τις πληροφορίες, την παρουσίαση στοιχείων αποτελεσματικά, και την σωστή αποθήκευση. Τα ακόλουθα κριτήρια εξετάστηκαν από το πείραμα επίδειξης χρησιμοποιώντας τη συλλογική εργασία: 1. Η δυνατότητα για τη δημιουργία ψηφιακών οπτικών περιεχομένων εικόνας στο κατανεμημένο περιβάλλον. Όλα τα υλικά στην οπτική βιβλιοθήκη ήταν αποθηκευμένα, καλά διαχειρισμένα και με ασφαλή εφεδρικά, με ένα ολοκληρωμένο τρόπο χωρίς επαναλήψεις σε οργανισμούς εντός του διανεμηθέντος περιβάλλοντος. 2. Οι δυνατότητες σύνδεσης των διαφόρων οργανισμών μέσω του idc(internet Data Center) με δίκτυο υψηλής ταχύτητας και το χτίσιμο ένός σύστηματος με το οποίο οι χρήστες μπορούν να ανταλλάσσουν μεγάλο όγκο δεδομένων online και εγκαιραα. Η αποτελεσματικότητά της είναι να ξυπνά την ακαδημαϊκή περιέργεια για την περαιτέρω ανάπτυξη της τεχνολογίας για μεγάλη ταχύτητα, μεγάλη χωρητικότητα δεδομένων και ανταλλαγής πληροφοριών και ανταλλαγή δεδομένων. 3. Η ικανότητα του IDC (Internet Data Center) και των proxy servers να χειρίζονται διαδραστικές λειτουργίες ελέγχου, ακόμη και όταν οι πελάτες και οι servers τους βρίσκονται σε μια απρόσιτη IP περιοχή. 4. Η αποτελεσματικότητα της συλλογικής ανάπτυξης εκπαιδευτικού υλικού, μειώνοντας τη δυναμική διαδικασίας πριν από τη διάθεσή του στις τάξεις, καθώς και τη μείωση στο κόστος της ασφάλειας από την εξέταση των ζητημάτων που λειτουργούν με τροποποιημένες εφαρμογές server για να καταστούν πιο κατάλληλες και χρησιμοποιήσιμες στο πλαίσιο της IDC (Internet Data Center). Η λειτουργικότητα της δυναμικής στο αρχείο εικόνων. 5. Η εγκυρότητα στη δομή δεδομένων, η ανάκτηση, η προμήθεια και χρήση με XML στα συστήματα διαχείρισης της γνώσης που αναπτύσσεται στη πλατφόρμα. Ιδιαίτερα, η ικανότητα του να ζητά την έγκριση συλλογικής εργασίας, με ταυτόχρονη προστασία της ιδιωτικής ζωής δεδομένων 109

111 επιτρέποντας στους χρήστες να αλλάξουν τους συλλογικούς τους χώρους εργασίας ανάλογα με το αντικείμενό τους, στις οποίες η πρόσβαση ελέγχεται από κάθε οργάνωση, έτσι ώστε να επιτρέπονται μόνο τα μέλη της ομάδας για να ανταλλάσσουν δεδομένα. Τα αποτελέσματα του πειράματος και της διαχείρησης της υγειονομικής περίθαλψης Το πείραμα απέδειξε ότι η συζήτηση σε πραγματικό χρόνο με την ανταλλαγή δεδομένων και πόρων μεταξύ των γεωγραφικά διασκορπισμένων ομάδων ήταν δυνατό. Επιπλέον, επιβεβαιώσαμε ότι είναι δυνατόν συλλογικά να επεξεργαστουμε δεδομένα εικόνας μεταξύ των απομακρυσμένων τοποθεσιών που χρησιμοποιούν δίκτυο υψηλής ταχύτητας. Από το πείραμα, αποδείχθηκαν τα ακόλουθα οφέλη από την εφαρμογή των XML Web Services 1. ευέλικτη συνεργασία και συλλογικότητα μέσω της ανταλλαγής των ICP πόρων 2. ευέλικτη μεταφορά δεδομένων 3. αυτόματη εκτέλεση των ενοτήτων 4. δυνατότητα εφαρμογής των υπαρχουσων τεχνολογιών που βασίζονται στο διαδίκτυο(ανεξαρτήτου προμηθευτή) 5. αποτελεσματική χρήση των ήδη υπαρχων προγραμμάτων 6. μικρό κόστος για την εφαρμογή Με τη χρησιμοποίηση αυτών των οφελών, οι ακόλουθες υπηρεσίες για την διατήρηση της υγείας μπορεί να παρέχονται : 1. τσεκάπ ρουτινας και υπηρεσία αυτόματης ειδοποίησης για τους κατ 'οίκον ασθενείς με αρτηριακή πίεση, ελέγχο παλμών, εξετάσεις αίματος, τεστ ούρων, σακχάρου και παρακολούθηση του αίματος 2. συμβουλές από τα αποτελέσματα του τσεκαπ 3. φροντίδα από νοσοκόμες 4. απομακρυσμένη υγεια και υπηρεσίες συμβουλευτικής ιατρικής 5. επείγοντα περιστατικά 6. παρακολούθηση εργασιακού περιβάλλοντος των τηλεργαζομένων όπως η θερμοκρασία και η υγρασία Επίσης, η προστασία των προσωπικών δεδομένων είναι ιδιαίτερα σημαντική. Η εφαρμογή των AC στις υπηρεσίες της ιατρικής και υγειονομικής περίθαλψης, η ενσωμάτωση υψηλής αξιοπιστίας IDC (Internet Data Center) και οι XML Web Services καθιστούν το σύστημα εξαιρετικά αξιόπιστο και εγγυάται την ασφάλεια για θέματα προστασίας της ιδιωτικής ζωής. 110

112 Το δεύτερο σχήμα (figure 2) αναπαριστά ένα σύστημα web service που επεξεργάζεται το ιατρικό ιστορικό ενός ασθενή σε σύγκριση με αύτο στο σχημα 1 (figure 1). Αυτό το σύστημα είναι ιδαίτερα χρήσιμο για την αποφυγή υπερβολικής δόσης φαρμάκων και των παρενεργειών, όταν ο ασθενής πάσχει από αρκετές διαφορετικές αρρώστιες ή δέχεται την θεραπέια ταυτόχρονα απο διαφορετικούς γιατρούς (οδοντιατρος καρδιολόγος). Το σύστημα διαχείρησης γνώσης βρίσκει εφαρμογή στην ανάλυση των 111

113 δεδομένων και των δομών των στοιχείων και την σχέση μεταξύ των όρων που προέρχονται από διαφορετικά ιατρικά ινστιτούτα. Συμπέρασμα της έρευνας Πολλοί άνθρωποι αναγνωρίζουν την ανάγκη για βελτίωση της ποιότητας και της αποτελεσματικότητας του συστήματος διαχείρησης υγείας. Σε μία επαρκή κοινωνία αναμένεται με την χρήση εξελιγμένων ICT, μια πιο ακριβής διαχείρηση υγειας και ποιοτικότερες παροχές φροντίδας. Χρειάζεται να υπάρξει ένα σύστημα που αποτελεσματικά θα κάνει κατάλληλες συμβουλές και εκπαιδευτικές πληροφορίες προσιτές στον κόσμο για την αποφυγή ασθενειών που θα επηρεάσουν την δουλειά και την ζωή τους. Οι XML web services στο AC δίνει την δυνατότητα σε πολλούς ανθρώπους να ερθουν σε στενή επαφή με τους γιατρούς τους όποτε χρειαστούν,από το διαδίκτυο. Επίσης η χρήση των XML web services θα δημιουργούσε καινοτόμους δρόμους στους ανθρώπους για να διατηρήσουν την σωματική και ψυχική τους υγεία. Το πείραμα αυτό διεξήχθη σε περιορισμένο αριθμό πανεπιστημίων και ερευνητικά ινστιτούτα σαν πιλοτική εργασία. Παρολαυτά έχουμε αρκετές αποδείξεις για να επιβεβαιώσουμε την αξία του ACW. Ειδικά είναι χρήσιμο στην τηλεργασία που χρησιμοποιήται σαν adaptive collaboration. Δίνει την δυνατότητα σε πολλούς ανθρώπους να δουλεύουν μαζί στο ίδιο project με το να τους επιτρέπει να ανταλλάσουν μεγάλο όγκο δεδομένων. Επίσης δεν χρειάζεται να κατέχουν όλοι την ίδια ορολογία. Συγκεκριμένα για να εκπληρώσουν γρήγορα τις ιατρικές ανάγκες ενος κατοίκου, πρέπει να ενθαρυνθεί η τηλεργασία μεταξύ γειτωνικών ιατρικών κέντρων, που θα ενισχύσουν την ποιότητα των παρεχόμενων υπηρεσιών στους κατοίκους και θα καταστεί δυνατή η βέλτιστη κατανομή της διαχείρησης των πηγών των ιατρικών κέντρων φροντίδας. Η εφαρμογή των XML web services στο AC είναι μια ουσιαστική συνεισφορά στην υγειονομική περίθαλψη και στον ιατρικό τομέα για την πραγματοποίηση των υπηρεσιών προσανατολισμένες στον ασθενή (patient-oriented service). 112

114 ΠΑΡΑΡΤΗΜΑ Το Hospital Το Hospital είναι ένα ελεύθερο Σύστημα Ηλεκτρονικού Ιατρικού Φακέλου ανοικτού κώδικα με δυνατότητες κλιμάκωσης και μπορεί, με ελάχιστο κόστος, να προσφέρει μία ποιοτική λύση στον τομέα αυτό. Το λογισμικό υλοποιείται ως άρθρωμα (module) το οποίο εκτελείται μέσα στο επίσης ανοικτού κώδικα σύστημα Διαχείρισης Επιχειρησιακών Πόρων openerp. Σε συνδυασμό με το openerp λοιπόν μπορεί να αποτελέσει μία πλήρη λύση μηχανογράφησης (προμήθειες, διαχείριση αποθήκης, διαχείριση προσωπικού). Λόγω των ιδιαιτεροτήτων του Συστήματος Υγείας της κάθε χώρας, απαιτείται η αναμόρφωση του λογισμικού Ιατρικού Φακέλου για να μπορεί να χρησιμοποιηθεί αποτελεσματικά. Αυτό το κενό ακριβώς φιλοδοξεί να καλύψει το Hospital στην κατηγορία των EMR ανοικτού κώδικα στην Ελλάδα. Μοντέλο ανάπτυξης/υλοποίησης: Εγκατάσταση σε Νοσοκομεία και υποστήριξη από τα Τμήματα Πληροφορικής τους. Παροχή ως υπηρεσία (Software as a service, SaaS) από τις Δ.Υ.ΠΕ. σε Κέντρα Υγείας, μέσω του ΣΥΖΕΥΞΙΣ. Παροχή σε όσα αγροτικά ιατρεία υπάρχει η υποδομή (δίκτυο και υπολογιστής) πάλι ως υπηρεσία. Το μοντέλο ανάπτυξης που ακολουθεί το Ηospital είναι αυτό του λογισμικού ανοικτού κώδικα (open source). Το μοντέλο αυτό στηρίζεται στη συνεχή, από κοινού ανάπτυξη προγραμμάτων μέ χρήση συνεργατικών εργαλείων ανάπτυξης. Το αποτέλεσμα του πηγαίου κώδικα διανέμεται ελεύθερα για χρήση και παραμετροποίηση. Το μοντέλο αυτό μπορεί ως ένα βαθμό να αποτρέψει σχεδιαστικά λάθη, διότι οι προδιαγραφές δεν καθορίζονται από τον εκάστοτε decision-maker/manager αλλά από τους ίδιους τους χρήστες με βάση την εμπειρία χρήσης. Επιπροσθέτως επειδή το πρόγραμμα έχει υλοποιηθεί αποκλειστικά με χρήση τεχνολογιών ανοικτού κώδικα δεν υπάρχουν οικονομικοί περιορισμοί σε μία ενδεχόμενη κλιμάκωσή του. 113

115 Εξοικονόμηση πόρων Λιγότερο χαρτί (ιατρικός φάκελος/αρχείο, παραπεμπτικά, εξετάσεις). Επίσης για τον ίδιο λόγο είναι και ιδιαίτερα οικολογικό. Κέρδος χρόνου από τους ιατρούς που έχουν άμεση πρόσβαση στο ιατρικό ιστορικό. Επομένως διαθέτουν πιο πολύ χρόνο για εξέταση ασθενών. Απομακρυσμένη σύνδεση Κέντρων Υγείας στο κεντρικό νοσοκομείο για λήψη αποτελεσμάτων εξετάσεων, χωρίς ανάγκη μετακίνησης. Αποτελεσματική διαχείριση αποθήκης, αναλωσίμων. Το πρόγραμμα διατίθεται δωρεάν (δε χρειάζεται πληρωμή για την αγορά του). Η πρόσβαση στο πρόγραμμα μπορεί να γίνει και μέσω web interface οπότε δε χρειάζεται εγκατάσταση κάποιου προγράμματος με υπολογιστικές απαιτήσεις. Με αυτόν τον τρόπο μπορούν να αξιοποιηθούν υπάρχοντες παλαιοί υπολογιστές. Αποτελεσματική αξιοποίηση του υπάρχοντος προσωπικού πληροφορικής του χώρου υγείας και των γνώσεών τους. Προοπτικές εξέλιξης Η αρχιτεκτονική του συστήματος είναι αρθρωτή επομένως ευνοούνται μελλοντικές τροποποιήσεις & παραμετροποίηση. Μία πιθανή μελλοντική εξέλιξη είναι η διασύνδεση με το σχεδιαζόμενο σύστημα συνταγογράφησης. Επίσης με βάση τα δεδομένα που θα συγκεντρωθούν μπορεί να γίνει εξαγωγή δεικτών (Ημερήσιο κόστος νοσηλείας, Μέσο κόστος νοσηλείας ασθενών, Φαρμακευτική κατανάλωση συνολικά ή κατά τομέα ή κλινική, ποσοστό κάλυψης κλινών, Μέση διάρκεια νοσηλείας, Κόστος κλίνης). Με βάση τους δείκτες αυτούς στη συνέχεια η διοίκηση μπορεί να προγραμματίσει τους τρόπους βέλτιστης λειτουργίας και ελέγχου του κόστους. Λειτουργικά Χαρακτηριστικά Hospital: Ιδιαίτερη έμφαση στην πρωτοβάθμια φροντίδα υγείας Ενδιαφέρον για τα κοινωνικο-οικονομικά στοιχεία του ασθενούς (βιοτικό επίπεδο, μόρφωση κλπ) και τον τρόπο ζωής του. Διεθνή πρότυπα κωδικοποίησης Νόσων/Διαγνώσεων και ιατρικών διαδικασιών (ICD-10 στα Ελληνικά / ICD-10-PCS στα αγγλικά) Λύση για 100% ηλεκτρονική διαχείριση των ασθενών Διαχείριση ασθενών (δημιουργία, επισκέψεις / εισαγωγές) 114

116 Ιατρικό Ιστορικό ασθενών (εμβολιασμοί, κληρονομικές ασθένειες, αλλεργίες, φαρμακευτικές αγωγές, χειρουργικές επεμβάσεις) Ραντεβού Εκτιμήσεις (εισαγωγή, επίσκεψη, επείγοντα, τηλεφωνικές κλήσεις, περιοδική εξέταση) Διαχείριση Ιατρών Διαχείριση Εργαστηριακών Εξετάσεων με δυνατότητα «Ηλεκτρονικού παραπεμπτικού» εξετάσεων. Ενσωματώνει το Ελληνικό Εθνικό Συνταγολόγιο Σε συνδυασμό με το openerp διαχείριση αποθεμάτων και προμηθειών ιατρικών αναλωσίμων και φαρμάκων Διοικητική υποστήριξη Νοσοκομείου Σχεδιάστηκε με βάση τις ανάγκες των Ελληνικών Νοσοκομείων Ελεύθερο Λογισμικό με άδεια GPL. Τεχνικά Χαρακτηριστικά Hospital & openerp: -Γλώσσα προγραμματισμού: Python -Αποθήκευση δεδομένων: XML & postgresql -Περιβάλλον: Desktop Thin Application & Web based Επίσης ενσωματώνει όλα την απαραίτητη λειτουργικότητα για - Ασφάλεια: Υπάρχει ιεραρχημένη διαχείριση προνομίων ακολουθώντας το σύστημα ανάθεσης ρόλων και πλήρης ιχνηλασιμότητα (καταγράφεται κάθε ενέργεια των χρηστών). - Διεργασίες: Υποστηρίζεται η αποτελεσματική διαχείριση διεργασιών κάθε οργανισμού. Οι διάφορες εγγραφές (ασθενείς, εξετάσεις, διαγνώσεις) διέρχονται από διάφορες φάσεις, και ανατίθενται σε χρήστες. - Διαλειτουργικότητα: Το openerp παρέχει τα απαραίτητα web-services για πρόσβαση στα δεδομένα του. - Ώριμο περιβάλλον ανάπτυξης: Το openerp είναι ένα σύστημα μηχανογράφησης που έχει δοκιμαστεί σε πλήθος εγκαταστάσεων και δουλεύει με επιτυχία σε μεγάλους οργανισμούς όπως την Whirlpool, τα Γαλλικά Ταχυδρομεία κ.α. Ακολουθούν ορισμένα στιγμιότυπα από το ελεύθερο λογισμικό Hospital που φαίνεται η καταγραφή και η αναπαράσταση των δεδομένων. 115

117 116