Ολοκλήρωση λογισμικού σε Υπηρεσιοστρεφή Αρχιτεκτονική

Transcript

1 a ΕΛΛΗΝΙΚΗ ΔΗΜΟΚΡΑΤΙΑ ΤΕΧΝΟΛΟΓΙΚΟ ΕΚΠΑΙΔΕΥΤΙΚΟ ΙΔΡΥΜΑ ΙΟΝΙΩΝ ΝΗΣΩΝ ΠΑΡΑΡΤΗΜΑ ΛΕΥΚΑΔΑΣ ΤΜΗΜΑ ΕΦΑΡΜΟΓΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ ΣΤΗ ΔΙΟΙΚΗΣΗ ΚΑΙ ΣΤΗΝ ΟΙΚΟΝΟΜΙΑ Ολοκλήρωση λογισμικού σε Υπηρεσιοστρεφή Αρχιτεκτονική ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ Νιράκης Ευάγγελος ΕΠΙΒΛΕΠΩΝ: Παναγιώτης Σάτος Λευκάδα, 2012

2 Η σελίδα αυτή είναι σκόπιμα κενή.

3 Περιεχόμενα 1.Εισαγωγή Εισαγωγή Ορισμός Προβλήματος Δομή της εργασίας Αρχιτεκτονικές σχεδίασης CORBA και IDL Γενικά Ιστορία της CORBA Το μοντέλο αντικειμένου της CORBA Κατανομή αντικειμένων (Object Distribution) Αναφορές σε αντικείμενα (Object References) Προσαρμογείς Αντικειμένων (Object Adapters) Η Αρχιτεκτονική της CORBA Object Request Broker (ORB) Interface Definition Language (IDL) Λέξεις Κλειδιά (IDL Keywords) Internet InterORB Protocol (IIOP) Naming Service (NS) CORBA Clients & Servers Stubs & Skeletons CORBA services και CORBA facilities Java RMI Γενικά Στόχοι του RMI Αρχιτεκτονική RMI Stub/Skeleton Layer Remote Reference Layer Transport Layer Λειτουργία του RMI Service Oriented Architecture (SOA) Γενικά Βασικά Χαρακτηριστικά Υπηρεσίες (Services)... 32

4 3.2.3 Επιχειρησιακός Δίαυλος Υπηρεσιών (Enterprise Service Bus - ESB) Περιγραφή και Χαρακτηριστικά Συσχέτιση Δεδομένων (Data Mapping) Ευφυής Δρομολόγηση (Intelligent Routing) Ενασχόληση με Θέματα Ασφαλείας Ενασχόληση με Θέματα Αξιοπιστίας Διαχείριση Υπηρεσιών (Service Management) Επίβλεψη και Αρχειακή Καταγραφή (Monitoring and Logging) Επίβλεψη Επιχειρηματικής Δραστηριότητας (Business Activity Monitoring -ΒΑΜ) Υποστήριξη κατά την Υλοποίηση Υπηρεσιών (Service Implementation Support) Σχεδιαστικές Αρχιτεκτονικές Προσεγγίσεις Σύνδεση Σημείο- προς- Σημείο και Διαμεσολάβηση (Point-to-Point Connection versus Mediation) Αναχαιτιστές (Interceptors) Οδηγούμενο από πρωτόκολλο και Οδηγούμενο από API ESB (Protocol-Driven versus API-Driven ESB) Αποθήκη και Κατάλογος Υπηρεσιών (Service Repository - Service Registry) Χαλαρή Σύζευξη (Loose-Coupling) Αρχιτεκτονικά Πρότυπα με Βάση την SOA Αρχιτεκτονική (SOAbased Architectural Models) Λογικό - Επιχειρηματικό Μοντέλο (Logical - Business Architectural Model) Τεχνικό Αρχιτεκτονικό Μοντέλο (Technical Architectural Model) Συνδυασμός Αρχιτεκτονικών Μοντέλων (Mixed Architectural Model) Ασφάλεια (Security) Βασικά Χαρακτηριστικά Ετερογένεια και Ασφάλεια Κατανεμημένες Διαδικασίες και Επίπεδα Αφαιρετικότητας... 47

5 3.3 SOA Τεχνολογίες Διαδικτυακές Υπηρεσίες (Web Services) BPEL (Business Process Execution Language) Εισαγωγή Χαρακτηριστικά Σύνθεση Υπηρεσιών (Service Composition) Ενορχήστρωση και Χορογραφία Εκτελέσιμες και Αφαιρετικές Διαδικασίες (Executable and Abstract Processes) Πρωτόκολλο SOAP Γλώσσα Περιγραφής Υπηρεσιών Διαδικτύου WSDL Universal Description, Discovery and Integration (UDDI) Το μοντέλο χρήσης του UDDI Οι απαιτήσεις του καταλόγου UDDI Οι δομές δεδομένων του UDDΙ Γενική περιγραφή Η δομή δεδομένων businessentity Η δομή δεδομένων tmodel Προγραμματιστική διεπαφή του UDDI Γενική περιγραφή Μελέτη Περίπτωσης (Case Study) Σενάριο Προδιαγραφές συστήματος Βάση δεδομένων Πίνακας tdevice Πίνακας tgreenη Πίνακας tworker Πίνακας trecord Διάγραμμα βάσης δεδομένων Εφαρμογή Windows Form Σύνδεση με βάση δεδομένων Combo Boxes Κουμπία WCF Web Service Android Application Συμπερασματα... 93

6 6. Βιβλιογραφία... 94

7 1.Εισαγωγή 1.1 Εισαγωγή Κατά τη διάρκεια των τελευταίων χρόνων διαμορφώνεται ένα ιδιαίτερα πολυσύνθετο πλαίσιο επιχειρηματικών συναλλαγών στο οποίο εντάσσονται και λειτουργούν επιχειρήσεις και οργανισμοί με διαφορετικά συστήματα τεχνολογίας, πολιτικές και επιχειρηματικά μοντέλα. Στα πλαίσια αυτού του ετερογενούς περιβάλλοντος επιχειρηματικών δραστηριοτήτων εμφανίζεται για τις επιχειρήσεις η ανάγκη ανάπτυξης ενός συνόλου ενεργειών και ιδιοτήτων που θα τις καταστήσουν ανταγωνιστικές και θα τις βοηθήσουν να προσφέρουν μια ποικιλία καινοτόμων υπηρεσιών αποτελεσματικά, γρήγορα και σε ελεγχόμενα κόστη. Ορισμένες από τις ιδιότητες αυτές είναι η προσαρμοστικότητα στις μεταβολές των επιχειρηματικών μοντέλων, η έγκαιρη αντίδραση σε αυτές, η επαναχρησιμοποίηση των μονάδων λειτουργικότητας και η αποδέσμευση της επιχειρηματικής λογικής από την τεχνική υποδομή. Επίσης βασική επιδίωξη είναι η ολοκλήρωση των ετερογενών συστημάτων και προτύπων που εφαρμόζουν οι επιχειρήσεις. Η ολοκλήρωση επιτρέπει την ανάπτυξη ενός κοινού κώδικα επικοινωνίας μεταξύ των συνεργατών και ενοποιεί διαφορετικής φύσης δεδομένα και διαδικασίες. Τα Πληροφορικά Συστήματα που συγκεντρώνουν το σύνολο του λογισμικού, του υλικού και των δεδομένων ή των κανόνων τα οποία έχει στην ιδιοκτησία της μια επιχείρηση, μπορούν να οργανωθούν με τέτοιο τρόπο ώστε να επιτευχθούν τα καλύτερα αποτελέσματα ως προς τις διαστάσεις που αναφέρθηκαν προηγουμένως. Προς την κατεύθυνση ανανέωσης του πλαισίου των επιχειρηματικών συναλλαγών στην παρούσα πτυχιακή παρουσιάζονται και εξετάζονται περιπτώσεις αρχιτεκτονικών και εφαρμογών τους και τέλος δίνεται μια ερευνητική πρόταση εκτεταμένης Αρχιτεκτονικής Προσανατολισμένης σε Υπηρεσίες (Service Oriented Architecture- SOA). 1.2 Ορισμός Προβλήματος Η Υπηρεσιοστρεφής Αρχιτεκτονική (Service Oriented Architecture-SOA) είναι μία αρχιτεκτονική μέθοδος η οποία οδηγεί όλες τις περιπτώσεις δημιουργίας και χρήσης επιχειρηματικών διαδικασιών πακετάροντάς τις ως υπηρεσίες κατά τη διάρκεια του κύκλου ζωής τους καθώς επίσης ορίζοντας και παρέχοντας την υποδομή η οποία επιτρέπει διαφορετικές εφαρμογές να ανταλλάξουν δεδομένα και να συμμετάσχουν σε επιχειρηματικές διαδικασίες ανεξάρτητα από το λειτουργικό σύστημα και τις προγραμματιστικές γλώσσες που υποστηρίζουν αυτές τις εφαρμογές. Η υπηρεσιοστρεφής αρχιτεκτονική αναπαριστά ένα μοντέλο στο οποίο η λειτουργικότητα αποσυντίθεται σε μικρές, διακριτές μονάδες (υπηρεσίες) οι οποίες μπορούν να κατανεμηθούν πάνω από ένα δίκτυο και μπορούν να συνδυαστούν και να επαναχρησιμοποιηθούν για τη δημιουργία επιχειρηματικών εφαρμογών. Αυτές οι υπηρεσίες επικοινωνούν μεταξύ τους περνώντας δεδομένα από μία υπηρεσία στην άλλη ή συντονίζοντας μία δραστηριότητα μεταξύ μίας ή περισσοτέρων υπηρεσιών.

8 Συχνά αναφέρεται ως μία εξέλιξη του κατανεμημένου υπολογισμού και του δομημένου προγραμματισμού. Η υπηρεσιοστρεφής αρχιτεκτονική αντικαθιστά σταδιακά τις μονολιθικές αρχιτεκτονικές ως η βασική σχεδιαστική αρχή για τις νέες επιχειρηματικές εφαρμογές. Αυτή η διαδικασία οδηγείται εν μέρει από τα έμφυτα οφέλη της υπηρεσιοστρεφούς αρχιτεκτονικής για τις νέες εφαρμογές. Η χρήση της, ενισχύεται από τις απαιτήσεις των νέων εφαρμογών για επαναχρησιμοποίηση της επιχειρηματικής λογικής πάνω από πολλαπλά κανάλια πρόσβασης. Διαφορετικές κατηγορίες χρηστών, σε διαφορετικές περιπτώσεις και χρησιμοποιώντας διαφορετικές συσκευές, όλα μπορούν να απαιτήσουν πρόσβαση στο ίδιο σημαντικό σύνολο από επιχειρηματικές λειτουργίες. Επομένως, η μεταβίβαση σε εφαρμογές πολλαπλών πελατών και καναλιών ωθεί φυσικά το σχεδιασμό εφαρμογών με τη χρήση υπηρεσιοστρεφούς αρχιτεκτονική. Πολλές εφαρμογές λογισμικού της προαναφερθείσας κατηγορίας είναι κατανεμημένες και ετερογενείς. Η τάση για κατανεμημένο υπολογισμό προκύπτει από επιχειρήσεις και ανθρώπινες επιταγές (όπως η παγκοσμιοποίηση) και έχει ενισχυθεί από την ανάπτυξη αξιόπιστων δικτύων υψηλών ταχυτήτων και ενδιάμεσα λογισμικά (middleware) βασισμένα σε πρότυπα. Πολλά σύγχρονα πληροφοριακά συστήματα είναι επίσης ετερογενή: τα υποσυστήματα που τα αποτελούν στηρίζονται σε πολλές διαφορετικές πλατφόρμες. Η ετερογένεια προκύπτει για ποικίλους λόγους: φυσικοί περιορισμοί (βάρος, κόστος, ικανότητα μπαταριών, μέγεθος), συνθήκες στην αγορά (π.χ. ορισμένα συστατικά είναι διαθέσιμα μόνο σε ορισμένες πλατφόρμες), τεχνολογικές τάσεις (Java, C#, Perl, κ.λ.π.), και κληρονομικότητα (παλιότερα συστήματα). Ωστόσο, ο σημαντικότερος ίσως λόγος είναι το κόστος, αφού η επαναχρησιμοποίηση γενικότερα των υποδομών για νέες απαιτητικές εφαρμογές μειώνει δραματικά το κόστος και ταυτόχρονα διευρύνει τις υπολογιστικές ικανότητες των υπαρχόντων συστημάτων ανοίγοντας νέες προοπτικές. Το μόνο κόστος πλέον είναι αυτό της διασύνδεσης, της ανάπτυξης ενδιάμεσων συστημάτων και νέων εφαρμογών (ή προσαρμογής των υπαρχουσών). Τα κατανεμημένα ετερογενή (ΚΕ) συστήματα είναι πλέον πολύ κοινά, και είναι πολύ πιθανό να συνεχίσουν να αναπτύσσονται με αυτούς τους ρυθμούς. Όπως όλα τα συστήματα λογισμικού, τα ΚΕ συστήματα τίθενται συχνά υπό πίεση για να εξελιχθούν κατά τη διάρκεια της διάρκειας ζωής τους, καθώς οι σχετικές απαιτήσεις αλλάζουν. Δυστυχώς, τα ΚΕ συστήματα είναι εγγενώς δύσκολο να εξελιχθούν, για ποικίλους λόγους: χρησιμοποιούν διαφορετικές γλώσσες και πλατφόρμες υλικού/λογισμικού, οι διαδικασίες εγκατάστασης μπορούν να είναι αρκετά σύνθετες, ο συγχρονισμός, ο συναγωνισμός, και οι αποτυχίες αποτελούν δύσκολες προγραμματιστικές προκλήσεις και ο πηγαίος κώδικας μπορεί να μην είναι διαθέσιμος. Ειδικού ενδιαφέροντος είναι οι μη-λειτουργικές απαιτήσεις, όπως η ασφάλεια (συμπεριλαμβανομένου του ελέγχου πρόσβασης), η ποιότητα υπηρεσίας (QoS), ο έλεγχος (για την ανίχνευση παρείσφρησης), και οι διαχειριστικές λειτουργίες. Τέτοιες απαιτήσεις μπορούν συχνά μόνο να οριστικοποιηθούν αρκετά αργά, ίσως ακόμα και μετά από την εγκατάσταση και προσθέτουν πίεση στην εξέλιξη συστημάτων λογισμικού. Δυστυχώς, αυτές οι αλλαγές απαιτήσεων μπορούν σπάνια να εξεταστούν από απομονωμένες αλλαγές σε μερικά πολύ σχετικά τμήματα. Η εμπειρία δείχνει επαρκώς ότι η ανάπτυξη χαρακτηριστικών όπως η ασφάλεια είναι διεσπαρμένη μέσω ποικίλων διαφορετικών συστημάτων. Τα χαρακτηριστικά που απαιτούν αυτόν τον τύπο αποκεντροποιημένων υλοποιήσεων καλούνται θεμελιώδεις ανησυχίες (crosscutting concerns) στη βιβλιογραφία. Αυτό το φαινόμενο καθιστά τα μη λειτουργικά

9 χαρακτηριστικά ιδιαίτερα δύσκολο να εξελιχθούν, ακόμη και στα μη-κατανεμημένα συστήματα τα οποία υλοποιούνται χρησιμοποιώντας μια ενιαία γλώσσα. Έτσι σκοπός της εργασίας αυτής είναι η μελέτη ορισμένων αρχιτεκτονικών ολοκλήρωσης με σκοπό να αποδειχθεί γιατί είναι συμφέρον να γίνεται ολοκλήρωση λογισμικού με χρήση της υπηρεσιοστρεφούς αρχιτεκτονική. 1.3 Δομή της εργασίας Στη συνέχεια παρουσιάζεται συνοπτικά η διάρθρωση του κειμένου αυτής της πτυχιακής εργασίας. Αρχικά δίνονται οι περιλήψεις, το κείμενο ευχαριστιών και ο πίνακας περιεχόμενων και ξενόγλωσσων όρων. Στη συνέχεια, περνώντας στο κυρίως κείμενο της πτυχιακής, το 1ο κεφάλαιο αποτελεί την εισαγωγή. Σε αυτή διατυπώνεται το πρόβλημα και δίνεται ένα γενικό πλαίσιο που βοηθά στην κατανόηση των απαιτήσεων και των στόχων του προβλήματος. Στο ίδιο κεφάλαιο συμπεριλαμβάνεται η ενότητα διάρθρωσης του κειμένου της πτυχιακής. Το 2ο κεφάλαιο αποτελεί μια επισκόπηση διάφορων αρχιτεκτονικών ολοκλήρωσης όπως η Corba και η Java RMI. Αναλυτικότερα δίνεται ο ορισμός των αρχιτεκτονικών αυτών καθώς και κάποιες λεπτομέρειες σχετικά με τη φιλοσοφία τους και τις τεχνολογίες που χρησιμοποιούν. Στο 3ο κεφάλαιο ορίζεται και παρουσιάζεται πλήρως η Υπηρεσιοστρεφής Αρχιτεκτονική καθώς και οι τεχνολογίες που χρησιμοποιεί μαζί με τα πλεονεκτήματα που μας προσφέρει.. Το 4ο κεφάλαιο παρουσιάζει μια μελέτη περίπτωσης πάνω στην ολοκλήρωση ενός κατανεμημένου ετερογενούς συστήματος με τη χρήση της Υπηρεσιοστρεφούς Αρχιτεκτονικής. Συνεχίζοντας στο 5 ο κεφάλαιο βρίσκουμε τα συμπεράσματα της εργασίας αυτής καθώς και κάποια γενικότερα σχόλια πάνω στην εργασία, αποτελώντας τον επίλογο της πτυχιακής. Τέλος βρίσκεται η βιβλιογραφία η οποία χρησιμοποιήθηκε για την εκπόνηση της πτυχιακής αυτής εργασίας.

10 2Αρχιτεκτονικές σχεδίασης 2.1 CORBA και IDL Γενικά CORBA είναι το ακρωνύμιο για την Common Object Request Broker Architecture, μια αρχιτεκτονική που επιτρέπει την κατανομή και χρησιμοποίηση προγραμματιστικών αντικειμένων πάνω σε ένα δίκτυο. Στην ουσία η CORBA αποτελεί ένα διεθνές πρότυπο το οποίο περιγράφει την αρχιτεκτονική, τις διασυνδέσεις και τα πρωτόκολλα με τα οποία τα κατανεμημένα αντικείμενα μπορούν να αλληλεπιδρούν μεταξύ τους καθορίζοντας έτσι τον τρόπο με τον οποίο δύο εφαρμογές μπορούν να επικοινωνήσουν μεταξύ τους, ανεξάρτητα από τη θέση τους ή την γλώσσα προγραμματισμού στην οποία είναι γραμμένες. Το πρότυπο αυτό ορίστηκε από το Object Management Group (OMG), μια διεθνής συνεργασία 760 και πλέον εταιριών σκοπός της οποίας είναι «η εξασφάλιση ενός κοινού αρχιτεκτονικού πλαισίου εργασίας για αντκειμενοστρεφείς εφαρμογές βασισμένο σε ευρέως διαδεδομένες προδιαγραφές διασυνδέσεων».[28] Η CORBA αρχιτεκτονική στηρίζεται στο μοντέλο του αντικειμένου, το οποίο απορρέει από ένα θεωρητικό κεντρικό μοντέλο αντικειμένου ορισμένο από το OMG και μπορεί να βρεθεί στον δικτυακό τόπο Το μοντέλο αυτό είναι θεωρητικό με την έννοια ότι δεν πραγματοποιείται ευθέως από καμία συγκεκριμένη τεχνολογία αλλά δίνει τον τρόπο στις διάφορες εφαρμογές να υλοποιηθούν με μια προτυποποιημένη μέθοδο χρησιμοποιώντας βασικές δομές όπως τα αντικείμενα. Μια τέτοια υλοποίηση δίνει τη δυνατότητα σε ένα σύστημα βασισμένο σε CORBA να διαχωρίζει τους αιτούντες υπηρεσιών (clients) από τους παροχείς αυτών (servers) με μια καλά ορισμένη διασύνδεση.[36] Σχήμα 1 Αν προσπαθούσαμε να σχηματίσουμε μια γενική εικόνα για την CORBA θα βλέπαμε ότι αποτελεί μια συλλογή από αντικείμενα και εφαρμογές τα οποία συνεργάζονται αρμονικά μεταξύ τους. Μια προδιαγραφή-διασύνδεση γραμμένη με την Interface Definition Language (IDL) περιγράφει τα αντικείμενα τα οποία πρόκειται να

11 χρησιμοποιηθούν απομακρυσμένα ενώ ένας Object Request Broker (ORB) υλοποιεί την διασύνδεση μεταξύ απομακρυσμένου αντικειμένου και πελάτη-λογισμικού και χειρίζεται όλες τις αιτήσεις και απαντήσεις για υπηρεσίες αντικειμένων. Την επικοινωνία μεταξύ πελατών και εξυπηρετητών πάνω από το δίκτυο αναλαμβάνει το Internet InterORB Protocol (IIOP) το οποίο είναι υπεύθυνο για την διακίνηση των μηνυμάτων μεταξύ των ORBs. Η πολύπλοκη αυτή συνεργασία φαίνεται απλοποιημένα στο Σχήμα 2. Σχήμα 2 Στη συνέχεια θα εξετάσουμε με λεπτομέρεια τα βασικά αυτά συστατικά αφού πρώτα κάνουμε μια σύντομη αναδρομή στην εξέλιξη αυτής της πετυχημένης αρχιτεκτονικής Ιστορία της CORBA Αμέσως μετά την ίδρυση του OMG (1989), το 1990 παρουσιάστηκε και υιοθετήθηκε η πρώτη έκδοση της CORBA (CORBA 1.0). Σύντομα αυτή αντικαταστάθηκε από την CORBA 1.1, όπου οριζόταν η IDL καθώς και το API με το οποίο οι εφαρμογές θα επικοινωνούσαν με τον ORB, και στη συνέχεια από την CORBA 1.2. Οι πρώτες αυτές εκδόσεις αποτέλεσαν το πρώτο και σημαντικό βήμα προς την ολοκλήρωση των κατανεμημένων αντικειμένων, χωρίς όμως να συνιστούν μια πλήρη προδιαγραφή. Μπορεί να παρείχαν πρότυπα για την IDL και την πρόσβαση σε έναν ORB, δεν καθόριζαν όμως ένα πρότυπο για το πρωτόκολλο με το οποίο θα επικοινωνούσαν οι διάφοροι ORB μεταξύ τους. Έτσι ORBs διαφορετικών εταιριών δεν μπορούσαν να επικοινωνήσούν μεταξύ του, με αποτέλεσμα να περιορίζεται σημαντικά η ολοκλήρωση των κατανεμημένων αντικειμένων.[36] Η επίλυση των παραπάνω προβλημάτων ήρθε με την παρουσίαση της έκδοσης 2.0 (1994), όπου επιτέλους οριζόταν ένα πρωτόκολλο επικοινωνίας μεταξύ ORBs. Το πρωτόκολλο αυτό, γνωστό ως Internet InterORB Protocol (IIOP), εγγυάται πραγματική ολοκλήρωση και πρέπει να υλοποιείται από όλες τις εταιρίες που παρέχουν προϊόντα συμμορφωμένα με την έκδοση 2.0. Σήμερα η συνεχής εξέλιξη της CORBA έχει οδηγήσει στην έκδοση 3.0 στην οποία έχουν προστεθεί πολλά νέα στοιχεία, όπως ο Portable Object Adapter (POA), νέες

12 τεχνικές για το χειρισμό κλήσεων (Callback, Polling) και το πέρασμα αντικειμένων με τιμή (by value). Στην παράγραφο που ακολουθεί θα αναλύσουμε όλα τα βασικά συστατικά της και θα ρίξουμε μια βαθύτερη ματιά στους διάφορους μηχανισμούς της Το μοντέλο αντικειμένου της CORBA Κάθε αντικειμενοστραφής αρχιτεκτονική χαρακτηρίζεται από ένα μοντέλο αντικειμένου με το οποίο αναπαρίσταται η συμπεριφορά των αντικειμένων μέσα στο σύστημα. Στην περίπτωση της CORBA, μιας κατανεμημένης αρχιτεκτονικής, υπήρχε η ανάγκη για ένα μοντέλο διαφορετικό από τα συνηθισμένα π.χ. για C++ ή Java, απαίτηση που ικανοποιήθηκε με ένα μοντέλο το οποίο χαρακτηρίζεται από ημιδιαφανή (semi-transparent) κατανομή αντικειμένων, πέρασμα με αναφορά και χρήση προσαρμογέων αντικειμένων (object adapters) Κατανομή αντικειμένων (Object Distribution) Από τη μεριά του client, στην CORBA, η απομακρυσμένη κλήση μεθόδου αντιμετωπίζεται ακριβώς σαν τοπική, χάρη στη χρήση του στελέχους πελάτη (client stub). Έτσι μπορούμε να πούμε ότι η κατανεμημένη φύση της CORBA είναι αόρατηδιαφανής από τον client, εφ όσον αυτός δεν καταλαβαίνει ότι συνεργάζεται με απομακρυσμένο αντικείμενο. Στην πραγματικότητα όμως υπάρχει ένα χαρακτηριστικό που προδίδει αυτή τη φύση. Για την αντιμετώπιση τυχόν-και πολύ πιθανών-λαθών του δικτύου, η CORBA προσφέρει ένα σύνολο εξαιρέσεων συστήματος που προκαλούνται απ όλες τις απομακρυσμένες μεθόδους και οι οποίες επιστρέφουν σήματα για λάθη στο δίκτυο. Κατά τα άλλα οι απομακρυσμένες μέθοδοι δεν ξεχωρίζουν από τις τοπικές Αναφορές σε αντικείμενα (Object References) Στις κατανεμημένες εφαρμογές το πέρασμα των αντικειμένων γίνεται με δύο τρόπους: πέρασμα με αναφορά, και πέρασμα με τιμή. Στην πρώτη περίπτωση το αντικείμενο παραμένει εκεί που δημιουργήθηκε, ενώ μια αναφορά σε αυτό δίνεται στην ενδιαφερόμενη διαδικασία. Όλες τις λειτουργίες που προκαλεί η διαδικασία περατώνονται από το ίδιο τα αντικείμενο. Στην περίπτωση του περάσματος με τιμή δημιουργείται ένα αντίγραφο της κατάστασης του αντικειμένου και μεταφέρεται στην ενδιαφερόμενη διαδικασία. Όλες οι λειτουργίες εκτελούνται πλέον από το αντίγραφο. Ένα σημαντικό χαρακτηριστικό του μοντέλου που χρησιμοποιείται στην CORBA είναι ότι όλα τα αντικείμενα περνάνε με αναφορά. Οι μέθοδοι που καλούνται σε ένα αντικείμενο εκτελούνται πάντα από το τμήμα του συστήματος που έχει-δημιούργησε το αντικείμενο. Προφανώς αν ένα τμήμα προκαλέσει μια μεγάλη σειρά από κλήσεις σε απομακρυσμένες μεθόδους θα δαπανηθεί πολύ χρόνος κατά την επικοινωνία των δύο τμημάτων. Για αυτό το λόγο προτάθηκε ( και υιοθετήθηκε στην έκδοση 3.0) από το OMG η χρήση του περάσματος με τιμή. Η υλοποίηση αυτής της καινοτομίας (για την CORBA) έγινε με την προσθήκη ενός νέου κατασκευασμένου τύπου στην IDL που λέγεται valuetype, δομή που μοιάζει πολύ με τις κλάσεις στην Java.

13 Όταν ένας τύπος valuetype περνάει σε μια απομακρυσμένη λειτουργία δημιουργείται ένα αντίγραφο της τοπικά στον αιτούντα. Ο αρχικός τύπος και το αντίγραφο του μπορούν να αναγνωριστούν και επομένως οι λειτουργίες στον έναν δεν επηρεάζουν τον άλλο. Όλες οι κλήσεις σε μεθόδους γίνονται τοπικά, κατά συνέπεια δεν απαιτείται η χρήση του δικτύου για μετάδοση αιτήσεων και απαντήσεων Προσαρμογείς Αντικειμένων (Object Adapters) Οι προσαρμογείς αντικειμένων μεσολαβούν μεταξύ των αντικειμένων CORBA και των υλοποιήσεων των IDL διασυνδέσεων, των λεγόμενων servants και παρέχουν μια σειρά από υπηρεσίες όπως η δημιουργία των αντικειμένων CORBA και των αναφορών τους, δημιουργία αιτήσεων στους κατάλληλους servants που υλοποιούν το επιθυμητό αντικείμενο καθώς και ενεργοποίηση-απενεργοποίηση των αντικειμένων CORBA. Στην έκδοση 2.0 ο μόνος τυποποιημένος προσαρμογέας από το OMG ήταν ο Βασικός Προσαρμογέας Αντικειμένων (Basic Object Adapter-BOA), ο οποίος παρείχε στοιχειώδεις υπηρεσίες για την δημιουργία αντικειμένων. Η έλλειψη βασικών χαρακτηριστικών όμως οδήγησε στην ανάγκη της υιοθέτησης ενός νέου προσαρμογέα, του Φορητού Προσαρμογέα Αντικειμένων (Portable Object Adapter- POA), ο οποίος περιείχε νέα χαρακτηριστικά, φορητότητα μεταξύ ORBs και ευελιξία στην υλοποίηση εξυπηρετητών. Ο ρόλος των προσαρμογέων φαίνεται στο Σφάλμα! Το αρχείο προέλευσης της αναφοράς δεν βρέθηκε. όπου αναπαριστάται μια αίτηση πελάτη σε εξυπηρετητή. Σχήμα 3 Ο πελάτης δημιουργεί την αίτηση χρησιμοποιώντας μια αναφορά που έχει για το αντικείμενο που χρειάζεται. Η αίτηση παραλαμβάνεται από τον ORB, ο οποίος με τη σειρά του δημιουργεί νέα αίτηση στον προσαρμογέα (POA) που φιλοξενεί το αντικείμενο. Ο προσαρμογέας μεταφέρει την αίτηση στον servant και αυτός εκτελεί την εφαρμογή και επιστρέφει τα αποτελέσματα πίσω στον πελάτη μέσω του POA και του ORB. Στην περίπτωση που η εφαρμογή έχει περισσότερους του ενός προσαρμογείς, o ORB χρησιμοποιεί ένα κλειδί αντικειμένου (object key) για να αναγνωρίσει τον σωστό POA και να του μεταφέρει την αίτηση.[28] 2.2 Η Αρχιτεκτονική της CORBA

14 Όπως αναφέραμε και προηγουμένως κύριος σκοπός του OMG είναι να βοηθήσει τον προγραμματισμό με κατανεμημένα αντικείμενα. Για να το πετύχει αυτό προχώρησε στην δημιουργία της Object Management Architecture (ΟΜΑ), το γενικότερο πλαίσιο τμήμα του οποίου είναι και η CORBA. Ας δούμε αναλυτικότερα τα σημαντικότερα στοιχεία της αρχιτεκτονικής αυτής Object Request Broker (ORB) Στον πυρήνα της CORBA βρίσκεται ο ORB. Ο ORB είναι ένα στοιχείο λογισμικού το οποίο υλοποιεί την προδιαγραφή της CORBA και έχει σκοπό την διευκόλυνση της επικοινωνίας μεταξύ αντικειμένων. Αυτό το πετυχαίνει με την παροχή ενός αριθμού υπηρεσιών όπως ο εντοπισμός ενός αντικειμένου δεδομένης μιας αναφοράς σε αυτό, η συγκέντρωση των απομακρυσμένων παραμέτρων καθώς και η επιστροφή των αποτελεσμάτων από και προς απομακρυσμένες κλήσεις μεθόδων. Κάθε σύστημα που εμπλέκεται σε μια εφαρμογή CORBA πρέπει να εκτελεί έναν ORB, έτσι ώστε οι διαδικασίες που εκτελούνται σε αυτό να μπορούν να αλληλεπιδράσουν με αντικείμενα CORBA που βρίσκονται σε απομακρυσμένες διαδικασίες. Σχήμα 4 Μπορούμε να συνοψίσουμε τη λειτουργία και τις ενέργειες του ORB στις παρακάτω γραμμές: Δεδομένης μιας αναφοράς σε ένα αντικείμενο από ένα πελάτη, ο ORB εντοπίζει την αντίστοιχη υλοποίηση του αντικειμένου (σε κάποιον εξυπηρετητή) για λογαριασμό του πελάτη. Πρέπει να τονίσουμε ότι την αναφορά στο αντικείμενο οφείλει να του την παρέχει ο πελάτης. Ο ORB ελέγχει την ετοιμότητα του εξυπηρετητή για αιτήσεις. Στη μεριά του εξυπηρετητή ο αντίστοιχος ORB συγκεντρώνει τις παραμέτρους από το δίκτυο και τις προωθεί σε αυτόν. Γίνεται η επιστροφή των παραμέτρων με τον ίδιο τρόπο.

15 2.3 Interface Definition Language (IDL) Θεμελιώδη ρόλο στην αρχιτεκτονική CORBA κατέχει εξίσου και η IDL, η γλώσσα ορισμού διασυνδέσεων με την οποία καθορίζονται οι διεπαφές μεταξύ των αντικειμένων CORBA και η οποία εξασφαλίζει την ανεξαρτησία της CORBA από τις υπόλοιπες γλώσσες προγραμματισμού. Εδώ πρέπει να τονίσουμε ότι η IDL καθορίζει το πώς θα φαίνεται ένα αντικείμενο τόσο από την μεριά του client όσο και από την μεριά του server. Ορίζει τις ιδιότητες, τις κλάσεις προγόνους (parent classes), τις εξαιρέσεις (exceptions), τα συμβάντα που προκαλεί (typed events) και τις μεθόδους (methods) που υποστηρίζει ένα αντικείμενο. Δεν πραγματοποιεί υλοποίηση και δεν μπορεί να χρησιμοποιηθεί γι την δημιουργία εφαρμογών. Αφού οριστεί η διασύνδεση για κάποιο αντικείμενο υπάρχει η ελευθερία να πραγματοποιηθεί η υλοποίηση του χρησιμοποιώντας μια γλώσσα για την οποία υπάρχει αντιστοίχηση (mapping) όπως η C, η C++, η Java, η Smalltalk, η Lisp, και η Python. Στη συνέχεια το αντικείμενο αυτό μπορεί να κληθεί απομακρυσμένα από μια εφαρμογή γραμμένη σε μια γλώσσα διαφορετική από αυτή της υλοποίησης. Με άλλα λόγια ένας client γραμμένος σε Java μπορεί να επικοινωνεί με έναν server γραμμένο σε C++, ο οποίος με τη σειρά του είναι client σε ένα server γραμμένο σε Cobol. Επίσης δίνεται η δυνατότητα στον προγραμματιστή να χρησιμοποιήσει περισσότερες από μια γλώσσες για διαφορετικά τμήματα της εφαρμογής του. Έτσι μπορεί η υλοποίηση των client τμημάτων της εφαρμογής να γίνει με την Java ώστε να εξασφαλιστεί το «συγγραφή μια φορά, εκτέλεση οπουδήποτε» ( write once, run everywhere ), ενώ η υλοποίηση των server τμημάτων να γίνει με C++ ώστε να εξασφαλιστεί η υψηλή απόδοση.[35] Στην IDL υπάρχουν πέντε υψηλού επιπέδου οντότητες και παρατίθενται με ιεραρχική σειρά: Μονάδες (Modules) Διασυνδέσεις σε αντικείμενα (Interfaces to objects) Τύποι δεδομένων (Data Types) Σταθερές (Constants) Εξαιρέσεις (Exceptions) Στη συνέχεια θα δούμε πως η σύνταξη της IDL καθορίζει καθένα από αυτούς, αφού πρώτα καλύψουμε μερικά από τα βασικά της γλώσσας Λέξεις Κλειδιά (IDL Keywords) Ο Πίνακας 1 περιέχει όλες τις δεσμευμένες της IDL. Αυτές οι λέξεις είναι ευαίσθητες στον τύπο χαρακτήρα (case sensitive) και δεν μπορούν να χρησιμοποιηθούν για αναγνωριστικά (identifiers). Πίνακας 1. Λέξεις Κλειδιά της IDL any default in oneway struct wchar

16 attribute double inout out switch wstring boolean enum interface raises TRUE case exception long readonly typedef char FALSE module sequence unsigned const fixed Object short union context float octet string void Αναγνωριστικά (Identifiers) Τα αναγνωριστικά σε μια IDL προδιαγραφή μπορούν να αποτελούνται από χαρακτήρες του λατινικού αλφαβήτου (a-z, A-Z) και τους αριθμητικούς χαρακτήρες (1-9). Επίσης επιτρέπεται να περιέχουν την κάτω παύλα (underscore character). Παρόλα αυτά τα αναγνωριστικά πρέπει να αρχίζουν με γράμμα, ενώ περιορισμός στο μήκος τους δεν υπάρχει. Σχόλια (Comments) Στις προδιαγραφές της IDL καθορίζονται δύο τύποι σχολίων. Ο πρώτος ξεκινάει με διπλή κεκλιμένη γραμμή (slash) και τελειώνει στο τέλος της σειράς: // Αυτό είναι σχόλιο Ο δεύτερος αρχίζει με τους χαρακτήρες /* και τελειώνει με τους χαρακτήρες */. Ενδιάμεσα μπορεί να περιέχει απεριόριστο αριθμό γραμμών: /* * Ένα ακόμα σχόλιο */ Βασικοί τύποι δεδομένων (Basic Data Types) Η IDL υποτρίζει τους βασικούς τύπους δεδομένων όπως φαίνεται από τον Πίνακας 2. Η τρίτη στήλη του πίνακα περιέχει και τον αντίστοιχο τύπο στη Java. Πίνακας 2 Βασικοί τύποι δεδομένων IDL Type Specifier Required Size short 16 bits short long 32 bits int long long 64 bits long unsigned short 16 bits short unsigned long 32 bits int unsigned long long 64 bits long char 8 bits char wchar Implementation-dependent char Java Data Type string Unlimited java.lang.string

17 string<size> sizechars java.lang.string wstring Unlimited java.lang.string wstring<size> sizewchars java.lang.string boolean Implementation-dependent boolean octet 8 bits byte any float IEEE single-precision float double IEEE double-precision double long double IEEE double-extended Not defined fixed 31 decimal digits Not defined Κατασκευασμένοι τύποι (Constructed Types) Στην IDL υποστηρίζονται τρεις κατασκευασμένοι τύποι δεδομένων: typedefs, arrays, sequences, struct, union και enum. Αναλυτικά: Typedefs Ο τύπος typedef συσχετίζει ένα όνομα με κάποιον άλλο υπάρχοντα τύπο δεδομένων όπως βασικό τύπο δεδομένων, τύπος ορισμένος από τον χρήστη (struct,union,enum), διασύνδεση ή τύπος sequence: //IDL typedef type identifier; Arrays Η IDL προσφέρει πολυδιάστατους πίνακες, σταθερών διαστάσεων οι οποίες καθορίζονται κατά τη διάρκεια της μεταγλώττισης (compile-time). Συνεπώς αυτές πρέπει να καθορίζονται πλήρως: //IDL data type identifier[ ][ ][ ] ; Sequences Ο τύπος αυτός αποτελεί ένα μονοδιάστατο πίνακα με δύο χαρακτηριστικά:το μέγιστο μέγεθος- η οποία καθορίζεται compile-time, και το μήκος (τύπο δεδομένου) που χρειάζεται- το οποίο καθορίζεται στο χρόνο εκτέλεσης (run time): //IDL sequence <data-type, 2> identifier; //bounded vector Sequence <data-type> identifier; //unbounded vector Structures Κάθε τύπος structure εισάγεται με την λέξη κλειδί struct, ακολουθείται από ένα αναγνωριστικό και τη λίστα με τα μέλη του:

18 //IDL struct typename { data-member; data-member; }; Discriminated Unions Η IDL ορίζει τον τύπο union, το οποίο καταλαμβάνει χώρο ίσο με τον χώρο που χρειάζεται το μεγαλύτερο στοιχείο του. Μια ετικέτα πεδίου χρησιμοποιείται για να καθορίσει ποιο μέλος του union περιέχει τιμή: //IDL union type-name switch (discriminator-type) { case tag-value: [data-element;] case tag-value: [data-element;]... [default:] data-element; }; Enumerations Ο τύπος enumeration αποτελείται από μια διατεταγμένη λίστα αναγνωριστικών: //IDL enum type-name { element-name, element-name,... }; Διασυνδέσεις (Interfaces) Οι διασυνδέσεις αποτελούν κεντρικό κομμάτι της IDL. Μια διασύνδεση αποτελείται από μια επικεφαλίδα και ένα σώμα, και δίνει μια περιγραφή των λειτουργιών του αντικειμένου. Επίσης παρέχει όλες τις πληροφορίες που χρειάζονται ώστε να αναπτυχθεί μια εφαρμογή-client η οποία θα χρησιμοποιεί όλες τις κλάσεις που αναφέρονται στη διασύνδεση. Επί πλέον μια διασύνδεση καθορίζει τυπικά τις ιδιότητες και τις μεθόδους ενός αντικειμένου καθώς και τις παραμέτρους αυτών. //IDL interface identifier[inheritance-spec] { interface body }; Μονάδες (Modules) Οι μονάδες μας δίνουν ένα τρόπο να οργανώσουμε τις διασυνδέσεις και τους υπόλοιπες IDL ορισμούς σε λογικά τμήματα. Επίσης μας βοηθά στην ονοματοδοσία των διασυνδέσεων και αποτρέπει πιθανές συγκρούσεις. Οι μονάδες μπορούν να

19 περιέχουν ορισμούς διασυνδέσεων, σταθερές, οι κατασκευασμένους τύπους όπως typedefs, structs, unions, enumerations. //IDL module identifier { }; Εξαιρέσεις (Exceptions) Στην IDL ορίζονται εξαιρέσεις για τον εντοπισμό σημάτων λάθους (error signal) ή άλλων ασυνήθιστων καταστάσεων που μπορεί να προκληθούν κατά τη διάρκεια μιας απομακρυσμένης κλήσης. Οι εξαιρέσεις δηλώνονται με μοναδικό όνομα και μπορεί να ακολουθούνται από ένα σετ ιδιοτήτων: //IDL exception identifier { data-member; data-member;...}; Κάθε μέλος (data-member) στον ορισμό της εξαίρεσης είναι ένας τύπος δεδομένων ακολουθούμενος από ένα μοναδικό αναγνωριστικό και πληροφορεί τον χρήστη με επιπλέον πληροφορίες για το λάθος που συνέβη. Πέρα από αυτές που ορίζονται από το χρήστη, υπάρχει και ένα σετ προκαθορισμένων εξαιρέσεων (Πίνακας 3) οι οποίες μπορούν να προκληθούν απ όλες τις μεθόδους ακόμα και αν δεν αναφέρονται ρητά στους ορισμούς τους. Πίνακας 3 Τυποποιημένες εξαιρέσεις της CORBA Exception Name BAD_CONTEXT BAD_INV_ORDER BAD_OPERATION BAD_PARAM BAD_TYPECODE COMM_FAILURE DATA_CONVERSION FREE_MEM IMP_LIMIT INITIALIZE INTERNAL INTF_REPOS INV_FLAG INV_IDENT INV_OBJREF INVALID_TRANSACTION MARSHAL NO_IMPLEMENT NO_MEMORY NO_PERMISSION NO_RESOURCES Meaning Failure while accessing the context object. Some methods were called out of their expected order. An invalid method was called. An invalid argument was passed into a method. A bad typecode was used. A communication failure occurred. Error while converting data. Failed to free some memory. Some implementation limit was exceeded. The ORB initialization failed. An internal ORB error occurred. Error attempting to access interface repository. An invalid flag was given. Invalid identifier syntax was encountered. An invalid object reference was encountered. An invalid transaction was used. An error occurred while marshalling method arguments or results. The implementation for the method is not available. Failed to allocate dynamic memory needed to execute the request. Not allowed to execute the method. There were insufficient resources for the request.

20 NO_RESPONSE OBJ_ADAPTER OBJECT_NOT_EXIST PERSIST_STORE TRANSACTION_REQUIRED TRANSACTION_ROLLEDBACK TRANSIENT UNKNOWN No response received for request. The object adapter encountered an error. The referenced object does not exist on the server. An error occurred while accessing persistent storage. An operation requiring a transaction was called without one. A transactional operation didn't complete because its transaction was rolled back. A transient error occurred, but the method can be tried again. An error occurred that the ORB could not interpret. Μέθοδοι (Operations) Στην IDL οι μέθοδοι (λειτουργίες στη διάλεκτο της IDL) ορίζονται με τρόπο παρόμοιο με αυτό της C: // IDL [call-semantics] return-type identifier ([param, param,...]) [exception-clause] [context-clause]; Τα μόνα απαραίτητα για την δήλωση των λειτουργιών είναι ο τύπος επιστρεφόμενων δεδομένων και το αναγνωριστικό όνομα. Στην περίπτωση που γίνεται δήλωση παραμέτρων πρέπει να καθορίζεται και η κατεύθυνση της με τις ακόλουθες επιλογές: in: Η παράμετρος περνά από client στον server. out: Η παράμετρος περνά από server στον client. inout: Η παράμετρος περνά προς τις δύο κατευθύνσεις. 2.4 Internet InterORB Protocol (IIOP) Στην CORBA χρησιμοποιείται η ιδέα της αναφοράς αντικειμένου (Object Reference- OR) για την επικοινωνία μεταξύ αντικειμένων. Όταν ένα τμήμα μιας εφαρμογής θέλει να προσπελάσει ένα αντικείμενο CORBA, πρέπει πρώτα να αποκτήσει μια αναφορά (OR) σε αυτό. Το τμήμα έτσι γίνεται πελάτης (client) του αντικειμένου, και χρησιμοποιώντας την OR μπορεί πλέον να καλεί τις μεθόδους του εξυπηρετητή (server).[36] Η παραπάνω επικοινωνία στην CORBA, από την έκδοση 2.0 και μετά, επιτυγχάνεται με το πρωτόκολλο IIOP, μια προδιαγραφή για την μετάδοση αιτήσεων μεταξύ ORBs που εκτελούνται σε διαφορετικά σημεία του δικτύου. Το πρωτόκολλο αυτό είναι ανεξάρτητο από τη συγκεκριμένη υλοποίηση των ORBs που βρίσκονται στις άκρες της ζεύξης, οπότε ένας ORB π.χ. γραμμένος σε Java μπορεί να επικοινωνήσει με έναν ORB γραμμένο π.χ. σε C, εφ όσον και οι δύο συμφωνούν με τις τυποποιήσεις της

21 CORBA. Δεδομένης της τελευταίας συνθήκης, το IIOP αναλαμβάνει την μετάδοση των απαραίτητων μηνυμάτων μεταξύ ORBs, τα οποία μπορεί να είναι αιτήσεις μεθόδων, επιστροφές δεδομένων ή μηνύματα λάθους. Παράλληλα το IIOP χειρίζεται και τις διαφορετικότητες σε επίπεδο μηχανής των δυο ORB, όπως η σειρά των byte και η στοίχιση τους. Έτσι οι προγραμματιστές απαλλάσσονται από το χειρισμό ενός χαμηλού επιπέδου πρωτοκόλλου επικοινωνίας. Το Internet InterORB Protocol βασίζεται στο πολύ γνωστό και διαδεδομένο TCP/IP, το πρωτόκολλο που χρησιμοποιείται ευρέως στο Internet, κάτι που λειτούργησε ως καταλύτης για την επικράτηση του έναντι των υπόλοιπων αντίστοιχων πρωτοκόλλων. Παρ όλα αυτά υπάρχουν και άλλα τυποποιημένα πρωτόκολλα ορισμένα για διαφορετικά δικτυακά περιβάλλοντα. Τέτοια είναι το DCE Common InterORB Protocol (DCE-CIOP) το οποίο επιτρέπει στους ORBs να επικοινωνούν πάνω από DCE-RPC, ενώ παρατηρείται ενδιαφέρον και στη χρησιμοποίηση ATM ή SS Naming Service (NS) Η Naming Service είναι η πιο διαδεδομένη υπηρεσία της CORBA, αφού παρέχει τον κύριο τρόπο ώστε ένας client να βρει αντικείμενα στο δίκτυο. Αποτελεί μια δομή ονοματοδοσίας τύπου καταλόγου (directory) και θα μπορούσε να παρασταθεί με μια δενδρική δομή. Το δέντρο ξεκινά πάντα με έναν κόμβο-ρίζα (root node) και τα αντικείμενα τοποθετούνται για την ακρίβεια δένονται (binding)- στα φύλλα (leaves) με βάση το όνομα τους. Στο Σχήμα 5 φαίνεται ένα τέτοιο δέντρο. Κάθε κλαδί στο δέντρο καλείται περιβάλλον ονόματος (naming context), ενώ τα αντικείμενα στα φύλλα έχουν συγκεκριμένα ονόματα. Το πλήρες όνομα του αντικειμένου μέσα στον κατάλογο είναι η διατεταγμένη λίστα απ όλους τους κόμβους-πατέρες (parent nodes), αρχίζοντας από τη ρίζα μέχρι και τον κόμβο του αντικειμένου. Έτσι στο παράδειγμα μας το πλήρες όνομα του αντικειμένου.

22 Σχήμα 5 Η χρήση των αναφορών σε αντικείμενα για την αναγνώριση των αντικειμένων παρουσιάζει δύο σοβαρά προβλήματα: Οι αναφορές σε αντικείμενα είναι αδιαφανείς τύποι δεδομένων και η αναπαράσταση τους σε string είναι μια μεγάλη ακολουθία αριθμών. Όταν ένας εξυπηρετητής επανεκκινείται τα αντικείμενα του αποκτούν νέες αναφορές, κάτι για το οποίο οι πελάτες ίσως να μην έχουν καμία πληροφόρηση. Η Naming Service της CORBA λύνει αυτά τα προβλήματα παρέχοντας ένα επιπλέον επίπεδο αφαίρεσης (abstraction) στην ταυτοποίηση των αντικειμένων. Παρέχει αναγνώσιμα (από το χρήστη) αναγνωριστικά στα αντικείμενα: οι χρήστες δίνουν ονόματα παρόμοια με αυτά οργανωμένων αρχείων και τα αντικείμενα μπορούν να τοποθετούνται κάτω από το ίδιο όνομα ανεξάρτητα από την αναφορά που έχουν.[28] 2.6 CORBA Clients & Servers Παραδοσιακά σε μια εφαρμογή ο εξυπηρετητής (server) είναι το τμήμα που παρέχει υπηρεσίες στα υπόλοιπα τμήματα της εφαρμογής. Ο πελάτης (client) είναι το τμήμα που κάνει χρήση αυτών των υπηρεσιών. Στην CORBA ισχύουν οι ίδιοι κανόνες, αν και κατά διάρκεια μιας απομακρυσμένης κλήσης οι ρόλοι αυτοί μπορούν να αντιστραφούν διότι ένα αντικείμενο CORBA μπορεί να συμμετέχει σε πολλές διεργασίες ταυτόχρονα. Κάθε τμήμα μιας εφαρμογής CORBA που παρέχει μια υλοποίηση αντικειμένου θεωρείται σε τοπικό επίπεδο εξυπηρετητής. Συχνά τα τμήματα μιας εφαρμογής παρέχουν υπηρεσίες σε άλλα τμήματα, ενώ τα ίδια κάνουν χρήση υπηρεσιών που παρέχονται από άλλα τμήματα και οπότε χαρακτηρίζονται είτε εξυπηρετητές είτε πελάτες ανάλογα με την οπτική γωνία που τα εξετάσει κανείς. Υπάρχει επίσης η δυνατότητα δύο τμήματα να αποτελούν και εξυπηρετητές και πελάτες το ένα για το άλλο (Σφάλμα! Το αρχείο προέλευσης της αναφοράς δεν βρέθηκε.).

23 Σχήμα Stubs & Skeletons Κατά τη διαδικασία συγγραφής μιας εφαρμογής CORBA, ο προγραμματιστής αφού δημιουργήσει τη διασύνδεση ενός τμήματος με τη χρήση της IDL, επεξεργάζεται τα IDL αρχεία χρησιμοποιώντας κάποιον IDL μεταγλωττιστή. Ο τελευταίος δημιουργεί ένα σύνολο αρχείων που ονομάζονται στελέχη πελάτη (client stubs) και σκελετοί εξυπηρετητή (server skeletons). Αυτά τα τμήματα λειτουργούν σαν συνδετικός κρίκος μεταξύ των ορισμών των διασυνδέσεων της IDL (language independent) και του υλοποιημένου κώδικα (language specific).[35] Τα στελέχη πελάτη για κάθε διασύνδεση πρέπει να συνεπεξεργάζονται με τους πελάτες που τα χρησιμοποιούν αφού περιέχουν μια τεχνητή (dummy) υλοποίηση για τις μεθόδους που περιγράφονται. Έτσι τα στελέχη δεν παίζουν το ρόλο του εξυπηρετητή, αλλά επικοινωνούν με τον ORB για την συγκέντρωση (marshaling) και απόλυση (unmarshaling) των παραμέτρων. Από την άλλη μεριά οι σκελετοί παρέχουν το γενικό δομικό πλαίσιο πάνω στο οποίο χτίζεται ο εξυπηρετητής. Για κάθε μέθοδο που περιγράφεται στη διασύνδεση, ο μεταγλωττιστής δημιουργεί μια κενή μέθοδο μέσα στο σκελετό την οποία ο προγραμματιστής χρησιμοποιεί για την υλοποίηση που θα πραγματοποιήσει. Η διαδικασία κατασκευής μιας εφαρμογής CORBA παρουσιάζεται στο Σχήμα 7.

24 Σχήμα CORBA services και CORBA facilities Μέχρι τώρα γνωρίσαμε τα βασικά στοιχεία της αρχιτεκτονικής CORBA, τα οποία είναι αρκετά για να δημιουργήσουμε μια εφαρμογή: χρησιμοποιούμε την IDL για να ορίσουμε τις διασυνδέσεις των επιμέρους τμημάτων, υλοποιούμε τις διασυνδέσεις αυτές και κατασκευάζουμε τους πελάτες που θα χρησιμοποιήσουν αυτές τις υπηρεσίες. Παρ όλα αυτά η OMA (η γενικότερη αρχιτεκτονική που περιέχει την CORBA) παρέχει πολύ περισσότερα από απλές λειτουργίες των ORBs, τις λεγόμενες CORBAservices και CORBAfacilities. Αυτές οι δυνατότητες περιέχουν χειρισμό συμβάντων (event handling), ανταλλαγή πληροφοριών(data interchange), αδειοδότηση (licensing), αναμονή αντικειμένων (object persistence), ονοματοδοσία (naming), ασφάλεια (security), συναλλαγές (transactions), διαχείριση διασυνδέσεων (interface management) και πολλές άλλες. Οι διασυνδέσεις για την χρησιμοποίηση αυτών των δυνατοτήτων είναι τυποποιημένες από το OMG παρουσιάζοντας συμφωνία σε όλες τις πλατφόρμες, ενώ περιλαμβάνονται και στις προδιαγραφές της IDL οπότε μπορούν να χρησιμοποιηθούν σαν κοινά αντικείμενα CORBA.

25 2.7 Java RMI Γενικά Η Remote Method Invocation (RMI) είναι ένα βασικό API της Java (και βιβλιοθήκη κλάσεων) το οποίο αποτελεί μια εναλλακτική προσέγγιση για την ανάπτυξη κατανεμημένων εφαρμογών. Στην ουσία πρόκειται για μια τεχνολογία η οποία επιτρέπει στην Java Virtual Machine ενός υπολογιστή να καλεί μεθόδους αντικειμένων οι οποίες και εκτελούνται σε JVM άλλων απομακρυσμένων υπολογιστών (Σχήμα 8). [34] Σχήμα 8 Οι επιστρεφόμενες τιμές και οι παράμετροι μπορούν να μεταφερθούν και προς τις δύο κατευθύνσεις, κάνοντας την παραπάνω επικοινωνία πλήρως αμφίδρομή. Έτσι τόσο ο client, όσο και ο server μπορούν να εκτελέσουν απομακρυσμένες μεθόδους. Ακόμα πιο γενικά, δίνει την δυνατότητα σε κομμάτια του ίδιου προγράμματος να εκτελούνται στην τοπική JVM, ενώ τα υπόλοιπα τμήματα του να βρίσκονται σε απομακρυσμένους hosts. Ένα σημείο που γίνεται αμέσως αντιληπτό είναι ότι η επικοινωνία αυτή είναι εφικτή μόνο όταν τα αντικείμενα είναι υλοποιημένα σε Java και επομένως καθιστά την χρήση αυτής της γλώσσας απαραίτητη για την κατασκευή της κατανεμημένης εφαρμογής με αυτή την τεχνολογία Στόχοι του RMI Οι προδιαγραφές του RMI θέτουν σαν στόχους του πακέτου RMI τα παρακάτω: υποστήριξη απομακρυσμένων κλήσεων σε αντικείμενα τοποθετημένα σε διαφορετικές JVM υποστήριξη κλήσεων επιστροφής (callbacks) από server σε client

26 ενοποίηση του μοντέλου κατανεμημένων αντικειμένων με το μοντέλο αντικειμένων της Java, με τρόπο φυσικό, διατηρώντας τις ήδη υπάρχουσες έννοιες της Java. οι διαφορές μεταξύ των δύο παραπάνω μοντέλων πρέπει να είναι εμφανείς η ανάπτυξη αξιόπιστων κατανεμημένων εφαρμογών οφείλει να είναι όσο απλή γίνεται διατήρηση της ασφάλειας που παρέχεται από το περιβάλλον του χρόνου εκτέλεσης της Java (Java run-time environment) Επιπλέον το σύστημα του RMI επιδιώκει την ευελιξία και την επεκτασιμότητα: πολλαπλοί μηχανισμοί απομακρυσμένων κλήσεων όπως unicast και multicast υποστήριξη διαφόρων τρόπων μεταφοράςκατανεμημένο μάζεμα απορριμμάτων (garbage collection) Αρχιτεκτονική RMI Στα συστήματα RMI υπάρχουν τρία, πλήρως ανεξάρτητα, στρώματα: το στρώμα στελέχους/σκελετού (stub/skeleton layer), το στρώμα απομακρυσμένης διασύνδεσης (remote interface layer) και το στρώμα μεταφοράς (transport layer), όπως φαίνονται στο Σχήμα 9. Η ανεξαρτησία των στρωμάτων τους δίνει την δυνατότητα να αντικατασταθούν από εναλλακτικές υλοποιήσεις, χωρίς αυτό να δημιουργήσει τυχόν προβλήματα συμβατότητας στο σύστημα RMI.[28] Σχήμα 9

27 2.7.4 Stub/Skeleton Layer Αυτό το στρώμα αποτελεί τη σύνδεση μεταξύ της εφαρμογής και του υπόλοιπου RMI συστήματος. Τα στελέχη και οι σκελετοί είναι κλάσεις πληρεξούσιοι (proxy classes), οι οποίες δημιουργούνται κατά την ανάπτυξη της εφαρμογής όταν μεταγλωττίσουμε την διασύνδεση του αντικειμένου και την υλοποίηση του εξυπηρετητή με τον rmic, τον μεταγλωττιστή του RMI. Το στέλεχος (stub) αποτελεί το τμήμα του client και είναι υπεύθυνο για πολλές εργασίες όπως την εκκίνηση των απομακρυσμένων κλήσεων, την συγκέντρωση των παραμέτρων που θα σταλούν, την ενημέρωση του επόμενου στρώματος για την πραγματοποίηση της κλήσης, απόδοση των τιμών (ή εξαιρέσεων) και ενημέρωση του remote reference στρώματος για το τέλος της κλήσης. Από την άλλη, ο σκελετός είναι το τμήμα του server και είναι υπεύθυνο για την απόδοση των εισερχομένων παραμέτρων από τον client, την κλήση του επιθυμητού αντικειμένου και συγκέντρωση και επιστροφή των τιμών (ή εξαιρέσεων) πίσω στον client Remote Reference Layer Το στρώμα απομακρυσμένης αναφοράς είναι το στρώμα που μεσολαβεί μεταξύ των στελεχών/σκελετών και του στρώματος μεταφοράς. Κύρια του ευθύνη είναι υποστήριξη πολλαπλών απομακρυσμένων αναφορών ή πρωτόκολλα κλήσεων, ανεξάρτητα από τα στελέχη και τους σκελετούς. Τα πρωτόκολλα αυτά μπορούν να υποστηρίζουν επικοινωνία από σημείο σε σημείο (point-to-point) ή και αναφορά σε αντικείμενα αντίγραφα. Το σύστημα του RMI εξασφαλίζει ότι η κλήση σε απομακρυσμένο αντικείμενο το οποίο έχει πολλαπλά αντίγραφα θα προωθηθεί και στα υπόλοιπα αντίγραφά του Transport Layer Το χαμηλότερο από τα τρία στρώματα, το οποίο αναλαμβάνει τη μεταφορά των δημιουργημένων ροών δεδομένων στην σωστή διεύθυνση. Το στρώμα αυτό καθορίζει και χειρίζεται τις συνδέσεις με απομακρυσμένες διευθύνσεις, περιμένει για εισερχόμενες κλήσεις, κρατάει ένα πίνακα με τα διαθέσιμα απομακρυσμένα αντικείμενα, εντοπίζει την τοποθεσία του καλούντα για λογαριασμό του καλούμενου και παραδίδει την σύνδεση στον καλούντα. Το στρώμα μεταφοράς αποτελείται από τέσσερα τμήματα:τα αντικείμενα, τον χώρο μεταξύ τοπικών και απομακρυσμένων διευθύνσεων, την φυσική υποδοχή και το πρωτόκολλο μεταφοράς (Σχήμα 10).

28 Σχήμα 10 Τα RMI συστήματα χρησιμοποιούν γα τη μεταφορά ένα πρωτόκολλο βασισμένο στο TCP, αλλά εφόσον είναι δυνατή η πολλαπλή μεταφορά ανά διεύθυνση, είναι εφικτή η χρήση ενός πρωτοκόλλου βασισμένου το UDP. 2.8 Λειτουργία του RMI Όταν ένας client καλέσει κάποιο απομακρυσμένο αντικείμενο που βρίσκεται σε ένα server τότε αναλαμβάνουν δράση τα τρία στρώματα της αρχιτεκτονικής του RMI. Τα συστήματα που χρησιμοποιούν την RMI για την επικοινωνία τους αποτελούνται συνήθως από το κομμάτι του server, το οποίο παρέχει την υπηρεσία RMI και το κομμάτι του client, το οποίο γίνεται χρήστης αυτής της υπηρεσίας. Οι RMI servers πρέπει να καταχωρηθούν σε μια υπηρεσία αναζήτησης (lookup service), ώστε να μπορούν οι clients να τους εντοπίζουν. Συγκεκριμένα στην Java υπάρχει μια τέτοια υπηρεσία, η rmiregistry, η οποία εκτελείται ως ξεχωριστή διαδικασία και επιτρέπει στις εφαρμογές να καταχωρούν RMI υπηρεσίες ή να αποκτούν αναφορά σε μια δηλωμένη υπηρεσία. Από τη στιγμή που κάποιος server καταχωρηθεί εκεί, περιμένει πλέον για εισερχόμενες αιτήσεις. Οι RMI clients στέλνουν μηνύματα RMI για να καλέσουν κάποια απομακρυσμένη μέθοδο. Πριν όμως συμβεί κάτι τέτοιο, πρέπει πρώτα ο client να αποκτήσει μια αναφορά στο απομακρυσμένο αντικείμενο. Αυτό μπορεί να γίνει με την υπηρεσία αναζήτησης που προσφέρει το μητρώο του RMI. Η εφαρμογή του πελάτη ζητάει το όνομα μιας συγκεκριμένης υπηρεσίας και δέχεται ένα URL για τον απομακρυσμένο πόρο. Οι αναφορές σε απομακρυσμένα αντικείμενα συνήθως αναπαριστώνται από την RMI ως εξής: rmi://hostname:port/servicename όπου hostname μπορεί να είναι IP διεύθυνση ή όνομα server, port η τοποθεσία της υπηρεσίας στον συγκεκριμένο υπολογιστή και servicename η περιγραφή της υπηρεσίας.[34]

29 Αφού αποκτήσει την αναφορά, ο client μπορεί πλέον να αλληλεπιδράσει με την απομακρυσμένη υπηρεσία. Οι λεπτομέρειες που αφορούν το δίκτυο, όσον αφορά τις αιτήσεις, είναι τελείως διαφανείς για τον προγραμματιστή, ο οποίος έχει την εντύπωση ότι δουλεύει με τοπικά αντικείμενα. Αυτό είναι ένα από τα σημαντικά πλεονεκτήματα που προσφέρουν τα στελέχη και οι σκελετοί, τα οποία δρουν ως πληρεξούσιοι των αντικειμένων που αλληλεπιδρούν. Το στέλεχος υλοποιεί κάποια συγκεκριμένη διασύνδεση RMI, την οποία μπορεί να χρησιμοποιεί η εφαρμογή του client. Το στέλεχος δεν πραγματοποιεί τις απαραίτητες εργασίες το ίδιο, μόνο περνάει τις αιτήσεις στην επιθυμητή υπηρεσία και περιμένει για απάντηση την οποία επιστρέφει στην καλούσα μέθοδο. Στην μεριά του server, ο σκελετός είναι υπεύθυνος για την απάντηση στις εισερχόμενες αιτήσεις και τη μεταφορά τους στην υπηρεσία RMI. Όπως και το στέλεχος, έτσι και ο σκελετός δεν προσφέρει καμία υλοποίηση για τις παρεχόμενες υπηρεσίες. Μετά από τη δημιουργία των διασυνδέσεων, ο προγραμματιστής οφείλει να τις υλοποιήσει. Αυτή η υλοποίηση θα κληθεί από τον σκελετό, ο οποίος θα ενεργοποιήσει τις απαραίτητες μεθόδους και θα περάσει τα αποτελέσματα πίσω στο στέλεχος και κατά συνέπεια στον client. Η όλη διαδικασία φαίνεται στο σχήμα 11: Σχήμα 11 Καταλήγοντας βλέπουμε ότι η RMI είναι μια τεχνολογία κατανεμημένων συστημάτων, η οποία επιτρέπει την απομακρυσμένη κλήση αντικειμένων σε απομακρυσμένες Java Virtual Machines. Αυτός είναι συχνά ο απλούστερος τρόπος επικοινωνίας μεταξύ δύο εφαρμογών, ακόμα και από την απευθείας επικοινωνία μέσω sockets. Η αλληλεπίδραση με τα αντικείμενα γίνεται με μεθόδους ορισμένες σε μια διασύνδεση RMI. Μόλις μια αναφορά σε ένα απομακρυσμένο αντικείμενο γίνει γνωστή, αυτό μπορεί να χρησιμοποιηθεί σαν τοπικό αντικείμενο, γεγονός που απλοποιεί σημαντικά την δημιουργία εφαρμογών δικτύου. Τα παραπάνω έχουν βέβαια αναγκαία προϋπόθεση την χρήση της JAVA ως κοινή γλώσσα προγραμματισμού, ένας περιορισμός που δεν τίθεται από την αρχιτεκτονικές CORBA και SOA με την οποία θα ασχοληθούμε στο επόμενο κεφάλαιο.

30 3. Service Oriented Architecture (SOA) 3.1 Γενικά Έχει γίνει προφανές ότι το κλειδί για τη σύγχρονη διαχείριση των κατανεμημένων πληροφοριακών συστημάτων και παράλληλα για το σχεδιασμό των επιχειρηματικών διαδικασιών είναι η ευελιξία (flexibility). Η ευελιξία αποτελεί κυρίαρχο παράγοντα στον σύγχρονο αρχιτεκτονικό σχεδιασμό της υπολογιστικής υλικής υποδομής και του επιχειρησιακού λογισμικού για να αντιμετωπιστεί η απαίτηση που δημιουργούν οι συνεχώς μεταβαλλόμενες συνθήκες της παγκόσμιας αγοράς, με αποτέλεσμα να αναδεικνύεται σε σημαντική επιχειρηματική αξία (business value). Συγχρόνως, οι διαδικασίες και τα συστήματα γίνονται ολοένα και περισσότερο πολύπλοκα, με αποτέλεσμα η προηγούμενη ανάγκη για αυτοματοποίηση των διαδικασιών ενός μόνο συστήματος να δίνει τη θέση της στην ανάγκη για ολοκλήρωση και επικοινωνία μεταξύ ετερογενών υποσυστημάτων ενός πληροφοριακού κατανεμημένου συστήματος. Οπότε απαραίτητη κρίνεται η αυτονομία των συστημάτων με σκοπό να επιλύσουν προβλήματα ενοποίησης (integration) εφαρμογών, διαχείρισης συναλλαγών, θέματα ασφάλειας ενώ παράλληλα επιδιώκουν την συνεργασία διαφορετικών legacy συστημάτων και την επικοινωνία ανεξαρτήτως πρωτοκόλλων και τεχνολογικών υποδομών. Η σύγχρονη πρόκληση, όμως, της επιστήμης των Πληροφοριακών Συστημάτων περιλαμβάνει και τη συντηρησιμότητα (maintainability) και την επαναχρησιμοποίηση (reusability) πόρων και διαδικασιών προκειμένου να βελτιώνεται η ανταπόκριση του πληροφοριακού συστήματος στις μεταβολές και να αποφεύγεται η επιπλέον σπατάλη οικονομικών πόρων. Επομένως, είναι εμφανές ότι οι προϋπάρχοντες τρόποι αντιμετώπισης προβλημάτων κλιμάκωσης (scalability) και κατανομής - διασποράς (distribution) των επιχειρηματικών διαδικασιών με τη χρήση κεντροποιημένων λειτουργιών εναρμόνισης και ελέγχου, δεν μπορούν να δώσουν λύση ούτε να ανταπεξέλθουν στις σύγχρονες απαιτήσεις. Στα πλαίσια της σύγχρονης επιχειρησιακής ανάγκης για ευελιξία, αυτονομία και ικανότητα συντήρησης των επιχειρηματικών διαδικασιών και συναλλαγών προκειμένου να αποκτήσει η σύγχρονη επιχείρηση στρατηγικό πλεονέκτημα και να ανταπεξέλθει στις ανταγωνιστικές συνθήκες της παγκόσμιας αγοράς, κρίθηκε απαραίτητο να αναζητηθεί μια νέα αρχιτεκτονική προσέγγιση για την οργάνωση και επικοινωνία των πληροφοριακών συστημάτων - μια προσέγγιση που να αποδέχεται την ετερογένεια και να οδηγεί στην αποκεντροποίηση των διαδικασιών. Η Αρχιτεκτονική Προσανατολισμένη σε Υπηρεσίες, Service Oriented Architecture (SOA), είναι η προσέγγιση που καλείται να υλοποιήσει τις επιδιώξεις των επιχειρήσεων και να αντιμετωπίσει τις σύγχρονες προκλήσεις, θέτοντας στο κέντρο των επιχειρηματικών διαδικασιών και συναλλαγών τις υπηρεσίες (services). Στην ουσία, πρόκειται για μια αρχιτεκτονική φιλοσοφία. Μια φιλοσοφία που στοχεύει στην πραγματοποίηση και συντήρηση επιχειρηματικών διαδικασιών, ώστε να είναι δυνατή η αποδοχή και χρησιμοποίηση τους από πολύπλοκα κατανεμημένα υπολογιστικά συστήματα. Άλλωστε, είναι εμφανές ότι η Αρχιτεκτονική Προσανατολισμένη σε Υπηρεσίες αποδέχεται την ετερογένεια και την αποκεντροποίηση και τα καθιστά απαραίτητα και κυρίαρχα στοιχεία γύρω από τα οποία αναπτύσσει τις υπόλοιπες κατευθυντήριες γραμμές της.

31 Επομένως μπορούμε να καταλήξουμε ότι η Υπηρεσιοστραφής Αρχιτεκτονική αποτελείται από τρία βασικά στοιχεία [13]: Τις Υπηρεσίες (Services) που είναι αυτόνομες (self-contained) και καλά ορισμένες μονάδες επιχειρηματικής λειτουργικότητας. Την υλική υποδομή πάνω στην οποία θεμελιώνεται η Υπηρεσιοστραφής Αρχιτεκτονική. Πρόκειται για τον Ταμιευτήρα Υπηρεσιών (Service Repository) που αποθηκεύει πληροφορίες σχετικές με τις λειτουργίες και τα δεδομένα των Υπηρεσιών και τον ΕπιχειρησιακόΔίαυλοΥπηρεσιών (Enterprise Service Bus) που καθιστά δυνατή την υλοποίησητης έννοιας της ολοκλήρωσης και συμβάλλει στην ευφυή κατανομή και επικοινωνία των επιχειρηματικών δεδομένων και διαδικασιών μεταξύ πολλαπλών συστημάτων που χρησιμοποιούν διαφορετικές και ετερογενείς τεχνολογίες. Τη χαλαρή σύζευξη (loose-coupling) που αντιπροσωπεύει την έννοια της μικρής εξάρτησης μεταξύ των διαφορετικών συστημάτων και ασχολείται με τη μείωση του κινδύνου και των συνεπειών λόγω μεταβολών και ασυνεπειών των πολλαπλών υποστηρικτικών συστημάτων (backends). Με αυτόν τον τρόπο είναι δυνατό να επιτευχθεί o στόχος για ευελιξία, κλιμάκωση και ανοχή ασυνεπειών και λαθών. Σχήμα 12 Επίπεδα αρχιτεκτονικής προσανατολιζόμενης στις υπηρεσίες (SOA) Συνοψίζοντας, θα μπορούσαμε να δούμε τους διάφορους γενικούς ορισμούς της SOA αρχιτεκτονικής που έχουν προταθεί κατά καιρούς, ώστε να γίνουν εμφανή τα βασικά

32 χαρακτηριστικά της προτού αναλυθούν με λεπτομέρεια. Αρχίζουμε με τον ορισμό που δίνεται από τον οργανισμό OASIS [15]: «είναι ένα παράδειγμα οργάνωσης και χρήσης των κατανεμημένων δυνατοτήτων που μπορεί να βρίσκονται υπό τον έλεγχο διαφορετικών τομέων δικαιοδοσίας. Παρέχει ένα ενιαίο μέσο προσφοράς, ανεύρεσης, αλληλεπίδρασης και χρήσης των δυνατοτήτων με στόχο την επίτευξη των επιθυμητών αποτελεσμάτων που συμφωνούν με μετρήσιμες προϋποθέσεις και επιδιώξεις» (OASIS definition for SOA: A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. ). Γίνεται φανερό ότι στον ορισμό τονίζονται η έννοια της ετερογένειας και της διασποράς των κατανεμημένων συστημάτων ως ανάγκη για την υιοθέτηση της SOA αρχιτεκτονικής. Ένας εναλλακτικός ορισμός της SOA αρχιτεκτονικής δίνεται στο δικτυακό τόπο της Wikipedia, όπου τονίζεται η χρήση των Υπηρεσιών ως το μέσο επικοινωνίας και ανταλλαγής πόρων χωρίς να είναι γνωστή η υλοποίηση τους από τα συστήματα από τα οποία διέρχονται. Συγκεκριμένα : «ο όρος Αρχιτεκτονική Προσανατολισμένη σε Υπηρεσίες εκφράζει μια προοπτική αρχιτεκτονικής λογισμικού που ορίζει τη χρήση των Υπηρεσιών για να υποστηρίξει τις απαιτήσεις των χρηστών. Σε ένα περιβάλλον SOA, οι πόροι σε ένα δίκτυο είναι διαθέσιμοι με τη μορφή αυτόνομων Υπηρεσιών που μπορούν να προσπελαστούν χωρίς γνώση της τεχνολογίας υλοποίησης τους» (Wikipedia definition for SOA: In computing, the term of Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation ). [30] 3.2 Βασικά Χαρακτηριστικά Υπηρεσίες (Services) Οι Υπηρεσίες είναι καλά ορισμένες αυτόνομες μονάδες που περιέχουν επιχειρηματική λειτουργικότητα και αποτελούν το κυρίως μέσο επικοινωνίας και αναπαράστασης διαδικασιών και λειτουργιών μεταξύ των διαφορετικών κατανεμημένων πληροφοριακών συστημάτων [14]. Η υπηρεσία ως λειτουργική μονάδα αποτελείται από [25]: το συμβόλαιο (contract) που είναι μια ολοκληρωμένη περιγραφή -προδιαγραφή (specification) της Υπηρεσίας και περιγράφει τη λειτουργία, τη συμπεριφορά, τους περιορισμούς και τους όρους που διέπουν τη χρήση της. Αποτελεί ένα είδος παρουσίασης και συμφωνίας μεταξύ του προμηθευτή-παροχέα της Υπηρεσίας (Service Provider) με τον καταναλωτή της Υπηρεσίας (Service Consumer) και πρέπει να στηρίζεται σε μια πλήρως καθορισμένη διαπροσωπεία (interface). τη διαπροσωπεία(interface) που είναι η περιγραφή της υλοποίησης των βασικών λειτουργιών της Υπηρεσίας. την υλοποίηση(implementation) που είναι η προγραμματιστική πραγμάτωση (δηλαδή σε μορφή προγράμματος λογισμικού) της επιχειρηματικής λειτουργικότητας της Υπηρεσίας, όπου συμπεριλαμβάνονται τα δεδομένα και οι μέθοδοι που χρησημοποιούνται.

33 την επιχειρηματική λειτουργικότητα (business functionality) που περιγράφει την επιχειρηματική λογική που υλοποιεί (business logic) και περιέχεται στην υλοποίηση του προγραμματιστικού κώδικα. Παράλληλα αξίζει να αναφερθούμε στις επιπλέον ιδιότητες που διέπουν τις Υπηρεσίες ώστε να γίνει κατανοητό το πλαίσιο για το οποίο δημιουργήθηκε η ανάγκη χρησιμοποίησης τους από την SOA αρχιτεκτονική. Αυτονομία: Οι Υπηρεσίες είναι αυτόνομες (self-contained) επιχειρηματικές λειτουργικές μονάδες που σημαίνει ότι αποφεύγεται η μεταξύ τους εξάρτηση, ώστε να προωθείται το ζητούμενο της χαλαρής σύζευξης και της ανεξαρτησίας από την τεχνολογία υλοποίησης. Επαναχρησιμοποίηση (Reusability):Οι Υπηρεσίες πρέπει να είναι επαναχρησιμοποιήσιμες ώστε να αποφεύγοντα οι περιττές πολλαπλές υλοποιήσεις σχετικά με την ίδια επιχειρηματική λειτουργία και να μπορούν χρησιμοποιηθούν για να συνθέσουν άλλες Υπηρεσίες. Οι Υπηρεσίες είναι Stateless που σημαίνει ότι δεν πρέπει να εξαρτώνται από την κατάσταση που βρίσκονται χωρίς να διατηρούν δεδομένα για αυτήν. Οι Υπηρεσίες είναι Composable που σημαίνει ότι είναι δυνατό να συνθέσουν άλλες Υπηρεσίες με τη μεταξύ τους ενορχήστρωση. Οι Υπηρεσίες είναι Idempotent που σημαίνει ότι έχουν την ικανότητα να επαναλάβουν την ίδια λειτουργία σε περίπτωση που είναι άγνωστο αν έχει ολοκληρωθεί η προηγούμενη κλήση χωρίς να υπάρξει πρόβλημα στα δεδομένα. Οι Υπηρεσίες αποκρύπτουν την υλοποίηση τους και το λογικό υπόβαθρο που τις διέπει. Οι Υπηρεσίες ακολουθούν και προωθούν το ζητούμενο της ολοκλήρωσης λόγω της χαλαρής σύζευξης μεταξύ τους. (Interoperable) Οι Υπηρεσίες είναι ανεξάρτητες της τεχνολογίας που της χρησιμοποιεί (Vendor- Diverse), δηλαδή μπορούν να υλοποιηθούν από διαφορετικά συστήματα και προϊόντα λογισμικού. Σύμφωνα με την ιδέα του «Σχεδιασμού με βάση το Συμβόλαιο» ( Design by Contract ) Oι Υπηρεσίες χαρακτηρίζονται από την κατάσταση πριν και μετά τη σύναψη συμβολαίου (Pre- και Post-Conditions) που συμβάλλει στην προδιαγραφή της σημασιολογικής (semantic) συμπεριφοράς των Υπηρεσιών [6]. Οι pre-conditions καθορίζουν και σχετίζονται με τις υποχρεώσεις που ο καταναλωτής πρέπει να ικανοποιεί κατά την κλήση της Υπηρεσίας, ενώ οι post-conditions καθορίζουν τις προδιαγεγραμμένες ιδιότητες που πρέπει να ικανοποιεί το σύστημα μετά την επιτυχή εκτέλεση και σχετίζεται ως ένα βαθμό με την Ποιότητα της Υπηρεσίας (Quality of Service). Οι Υπηρεσίες είναι Coarse-Grained που σημαίνει ότι πρέπει να είναι δομημένες κατά τέτοιο τρόπο ώστε η λειτουργία τους να περιορίζεται στο χαμηλότερο απλό επίπεδο (δηλαδή να αποφεύγεται η πολυπλοκότητα και να αναλύεται

34 μέχρι το κατώτερο επίπεδο αυτονομίας). Σχήμα 13 Χαρακτηριστικά Υπηρεσιώv Όσον αφορά τα είδη των Υπηρεσιών που αναπτύσσουμε μπορούμε να κατηγοριοποιήσουμε τις Υπηρεσίες με βάση τα διάφορα επίπεδα χρησιμοποίησης τους στην SOA αρχιτεκτονική [2 9 18]. Σχήμα 14 Είδη Υπηρεσιών Επομένως, καταλήγουμε στις εξής κατηγορίες : Βασικές Υπηρεσίες που είναι εκείνες που παρέχουν βασικές επιχειρηματικές λειτουργίε και δεν μπορούν να διασπαστούν σε μικρότερες πολλαπλές λειτουργικές οντότητες. Οι υπηρεσίες αυτές παρέχουν το πρώτο θεμελιώδες επιχειρηματικό επίπεδο (business layer) που στη περίπτωση της SΟΑ αρχιτεκτονικής αντιστοιχεί στο λεγόμενο Fundamental SOA, όπου ο ρόλος των Βασικών Υπηρεσιών συνίσταται στο να δημιουργήσουν πρόσβαση προς ένα μόνο συγκεκριμένο backend. Οι Βασικές Υπηρεσίες διακρίνονται σε Υπηρεσίες Δεδομένων και Υπηρεσίες Λογικής. Στην πρώτη περίπτωση η χρήση τους περιορίζεται μόνο στην ανάγνωση και στην εγγραφή δεδομένων, ενώ στη δεύτερη περίπτωση αντιπροσωπεύουν βασικούς επιχειρηματικούς κανόνες (business rules).

35 Σχήμα 15 Fundamental SOA (Αρχιτεκτονική Βασικών Υπηρεσιών) Το δεύτερο στάδιο της επέκτασης αποτελούν οι Σύνθετες Υπηρεσίες (Composed Services) που συντίθεται με την ένωση Βασικών Υπηρεσιών. Οι Σύνθετες Υπηρεσίες λειτουργούν σε υψηλότερο επίπεδο από τις Βασικές και μπορούν να προσπελάσουν περισσότερα του ενός backends δημιουργώντας έτσι το δεύτερο επίπεδο της SΟΑ αρχιτεκτονικής που ονομάζεται Federated SOA. Σχήμα 16 Federated SOA (Αρχιτεκτονική Σύνθετων Υπηρεσιών) Το τρίτο στάδιο της επέκτασης αποτελούν οι Υπηρεσίες Διαδικασιών (Process Services) που συντίθεται με την ένωση Βασικών και Σύνθετων Υπηρεσιών. Από επιχειρηματική σκοπιά οι Process Services αντιπροσωπεύουν μακροχρόνιες δραστηριότητες και ροές δεδομένων (long- running) που προστίθενται ως τρίτο επιχειρηματικό επίπεδο στην SOA αρχιτεκτονική και ονομάζεται Process- Enabled SOA.

36 Σχήμα 17 Process-Enabled SOA (Αρχιτεκτονική Υπηρεσιών Διαδικασιών) Τέλος, λαμβάνοντας υπόψη το γεγονός ότι οι Υπηρεσίες είναι μονάδες λογισμικού, μπορούμε να ισχυριστούμε ότι ακολουθούν κατά τη διάρκεια της ύπαρξης τους τον συνήθη κύκλο ζωής κάθε υπό ανάπτυξη λογισμικού, που κατά κανόνα συνίσταται από ένα βασικό κορμό, όπου κυριαρχούν οι φάσεις του σχεδιασμού (design), της υλοποίησης (implementation), της ενοποίησης (integration) και της εισόδου στην παραγωγική διαδικασία (production). Συγχρόνως μπορούμε να επεκτείνουμε τον κύκλο αυτό προσθέτοντας τα στοιχεία της επανάληψης (iteration) κατά την υλοποίηση, ώστε να επιδιώκεται το καλύτερο δυνατό αποτέλεσμα μέσα από μεταβολές της επιχειρηματικής λογικής και της προγραμματιστικής υλοποίησης, και της ταυτοποίησης - αναγνώρισης (identification) των αναγκαίων Υπηρεσιών που αποτελεί ένα είδος αναγνώρισης και προ-ανάλυσης ώστε να επιτυγχάνεται ο καλύτερος δυνατός σχεδιασμός των επιχειρηματικών διαδικασιών χωρίς περιττές απόπειρες υλοποίησης Υπηρεσιών που τελικά δε θα χρησιμοποιηθούν.

37 Σχήμα 18 Κύκλος ζωής Υπηρεσιών Προχωρώντας στο επίπεδο της παραγωγής και της εκτέλεσης είναι απαραίτητο να προστεθεί και μια φάση κατά την οποία θα είναι δυνατή η αντιμετώπιση και διόρθωση σφαλμάτων και ασυνεπειών (bug fixing) και τέλος η δυνατότητα για πλήρη απόσυρση - αντικατάσταση της Υπηρεσίας. Προκύπτει, επομένως, ο παραπάνω κύκλος ζωής των Υπηρεσιών Επιχειρησιακός Δίαυλος Υπηρεσιών (Enterprise Service Bus - ESB) Περιγραφή και Χαρακτηριστικά Για να γίνει δυνατή η υλοποίηση της SOA αρχιτεκτονικής, απαιτείται μια μέθοδος κλήσης και διαχείρισης των Υπηρεσιών, ώστε να παραληφθούν από τον πραγματικό καταναλωτή που πρόκειται να τις χρησιμοποιήσει και να γίνει γενικά δυνατή η αξιόπιστη μεταφορά και μετατροπή των δεδομένων. Μια συγκεκριμένη υποδομή με καθορισμένα χαρακτηριστικά ικανά να αναδείξουν τη λειτουργικότητα και την πρωτοποριακή αντίληψη της SOA αρχιτεκτονικής είναι, λοιπόν, απαραίτητη για την μεταφορά και τη δρομολόγηση των Υπηρεσιών, ώστε να αποτελέσει τη ραχοκοκαλιά του αρχιτεκτονικού τοπίου. Τέτοια υποδομή αποδείχθηκε ο Επιχειρησιακός Δίαυλος Υπηρεσιών (Enterprise Service Bus, για συντομία ESB). Η μεταφορά Υπηρεσιών από τον Παροχέα στον Καταναλωτή της Υπηρεσίας μπορεί να φαίνεται εύκολη υπόθεση στην πραγματικότητα, όμως, αποτελεί μια πολύπλοκη διαδικασία που απαιτεί και εξαρτάται από τεχνικές και οργανωσιακές προσεγγίσεις με χαρακτηριστικά και ευθύνες που περιλαμβάνουν : την παροχή συνδεσιμότητας την μεταφορά και μετατροπή των δεδομένων την (ευφυή) δρομολόγηση την ενασχόληση με θέματα ασφαλείας

38 την ενασχόληση με θέματα αξιοπιστίας την διαχείριση των Υπηρεσιών την παρακολούθηση (monitoring) την καταγραφή (logging) των γεγονότων και των μηνυμάτων Οι συγκεκριμένες λειτουργίες στις περισσότερες περιπτώσεις είναι αναγκαίο να περιλαμβάνουν τη συμμετοχή διαφορετικών συστημάτων λογισμικού και πρωτοκόλλων μεταφοράς. Επομένως, γίνεται φανερό ότι ο κύριος ρόλος ενός ESB είναι να συμβάλλει στρατηγικά στην παροχή της δυνατότητας για ολοκλήρωση των εφαρμογών. Επειδή, λοιπόν, περιλαμβάνει την ενοποίηση διαφορετικών πλατφόρμων λογισμικού και γλωσσών προγραμματισμού, ένα θεμελιώδες μέρος του ρόλου αυτού είναι η μετατροπή δεδομένων. Όπως δηλώνεται στο [14] : «Η μετατροπή δεδομένων είναι κληρονομικά μέρος του διαύλου στην ανάπτυξη του ESB. Οι υπηρεσίες και οι μέθοδοι μετατροπής που εξειδικεύονται λόγω των αναγκών για αυτόνομες εφαρμογές που συνδέονται στον δίαυλο, μπορούν και πρέπει να βρίσκονται οπουδήποτε και να είναι προσβάσιμες από οπουδήποτε στον δίαυλο. Επειδή η μετατροπή δεδομένων είναι τόσο αναπόσπαστο κομμάτι του ESB, ο Δίαυλος Υπηρεσιών μπορεί να γίνει αντιληπτός» Η συνήθης προσέγγιση είναι η εισαγωγή και η υιοθέτηση ενός συγκεκριμένου πλαισίου -(format) που να απεικονίζονται (map) όλα τα διαφορετικά APIs και πλατφόρμες λογισμικού. Όπως θα γίνει γνωστό παρακάτω το συγκεκριμένο πλαίσιο για τις Διαδικτυακές Υπηρεσίες είναι συνήθως το πρωτόκολλο SOAP. Μια άλλη θεμελιώδης λειτουργία του Διαύλου Υπηρεσιών είναι η δρομολόγηση των Υπηρεσιών, ώστε να είναι δυνατή η ορθή μεταφορά των Υπηρεσιών από τον Παροχέα στον Καταναλωτή. Τα υπόλοιπα χαρακτηριστικά και ευθύνες ενός ESB είναι συνήθως επέκταση της κύριας λειτουργίας που είναι η παροχή ολοκλήρωσης και συζητούνται παρακάτω λεπτομερώς Συσχέτιση Δεδομένων (Data Mapping) Λόγω της ανάγκης για χαλαρή σύζευξη, οδηγούμαστε σε μια κατάσταση όπου είναι απαραίτητο να υπάρχουν και να ορίζονται συγκεκριμένοι τύποι δεδομένων σχηματίζοντας ένα κοινά αποδεκτό μοντέλο δεδομένων για όλα τα διαφορετικά APIs. Επομένως, είναι αναγκαίο να εμφανίζεται ένα επίπεδο απεικόνισης (mapping layer) στην πλευρά του καταναλωτή, ώστε να απεικονίζονται τα δεδομένα του παροχέα στους δικούς του τύπους δεδομένων. Εναλλακτικά, υπάρχουν και άλλες μέθοδοι απεικόνισης μέσω του καθορισμού proxies που απεικονίζουν τα δεδομένα μέσα στο πρωτόκολλο μεταφοράς ή μέσω ενός ενδιάμεσου στρώματος - επιπέδου κατά τη μετατροπή ανάμεσα από την καθορισμένη πλατφόρμα λογισμικού στο συγκεκριμένο πρωτόκολλο μεταφοράς.

39 Ευφυής Δρομολόγηση (Intelligent Routing) Από επιχειρηματική σκοπιά και ανάγκη, μέσω του Δίαυλου Υπηρεσιών μπορεί να δοθεί η δυνατότητα ευφυούς δρομολόγησης των δεδομένων και των Υπηρεσιών με την εφαρμογή της μεθόδου των προτεραιοτήτων, όπου σε κάθε μήνυμα δίνεται και η ανάλογη προτεραιότητα εκτέλεσης. Βέβαια, γίνεται κατανοητό ότι για να γίνει πραγματικότητα η διαχείριση του περιεχομένου των μηνυμάτων και να επιτευχθεί η αναγκαία σήμανση προτεραιότητας, απαιτείται η σημασιολογική γνώση και κατανόηση από τον Δίαυλο Υπηρεσιών τμημάτων της δομής και της λογικής των Υπηρεσιών Ενασχόληση με Θέματα Ασφαλείας Στα περισσότερα αρχιτεκτονικά τοπία της SOA αρχιτεκτονικής, είναι αναγκαία η διαχείριση και η αντιμετώπιση των θεμάτων ασφαλείας που ανακύπτουν. Θέματα σχετικά με την ασφάλεια στηνsoa αρχιτεκτονική θα συζητηθούν σε μεταγενέστερο κεφάλαιο Ενασχόληση με Θέματα Αξιοπιστίας Διαφορετικά πρωτόκολλα προσφέρουν διαφορ ετικές μορφές αξιοπιστίας. Δεν είναι όμως αναγκαίο να διασφαλίζουν την αξιόπιστη μεταφορά μηνυμάτων και την παράδοση τους στον σωστό παραλήπτη. Πράγματι, το HTTP πρωτόκολλο που είναι το πρωτόκολλο που υποστηρίζουν οι Διαδικτυακές Υπηρεσίες (που αποτελούν απαραίτητο στοιχείο της SOΑ αρχιτεκτονικής και θα συζητηθεί παρακάτω) δεν εξασφαλίζει από την φύση του την ορθή παράδοση. Συνεπώς, ένας Δίαυλος Υπηρεσιών είναι αναγκαίο να καθορίζει τα πλαίσια αξιοπιστίας και διαχείρισης θεμάτων αξιοπιστίας. Ο τρόπος με τον οποίο σφάλματακαι τεχνικά λάθη αντιμετωπίζονται μπορεί να επηρεαστεί από το πρωτόκολλο πουχρησιμοποιεί το ESB, αλλά είναι το ίδιο το ESB που πρέπει να προσθέσει μηχανισμούς για να μεταβάλλει τη συγκεκριμένη συμπεριφορά Διαχείριση Υπηρεσιών (Service Management) Καθώς το αρχιτεκτονικό τοπίο της SOA αρχιτεκτονικής μεγαλώνει και αυξάνεται σε μέγεθος, εμφανίζεται το πρόβλημα διαχείρισης των Υπηρεσιών. Αυτό το πρόβλημα μπορεί να είναι επιχειρηματικό ζήτημα ώστε να επιτευχθεί η δυνατότητα για εύκολη αναζήτηση και επαναχρησιμοποίηση των Υπηρεσιών ή μπορεί να υπάρχει η τεχνική απαίτηση για την ανάπτυξη και εκτέλεση μιας υποδομής διαχείρισης των Υπηρεσιών Επίβλεψη και Αρχειακή Καταγραφή (Monitoring and Logging) Προκειμένου να επιτευχθεί ο στόχος της αξιοπιστίας και της διόρθωσης των σφαλμάτων είναι αναγκαίο να υφίσταται κάποιο είδος επιτήρησης και

40 παρακολούθησης των Υπηρεσιών και της ανταλλαγής μηνυμάτων που πραγματοποιούνται μέσω του ESB. Επομένως, ο Δίαυλος Υπηρεσιών πρέπει να παρέχει τη δυνατότητα της καταγραφής τω ν ενεργειών που συμβαίνουν και της παρακολούθησης των Υπηρεσιών και την απόδοση του κατανεμημένου συστήματος. Προς τη συγκεκριμένη κατεύθυνση πρέπει να υιοθετηθούν έννοιες και αντιλήψεις σχετικές με ταυτοποίηση και αναγνωριστικά συσχετίσεων με τη χρήση υπολογιστικών εργαλείων που υποστηρίζουν το monitoring και το debugging κατανεμημένων συστημάτων Επίβλεψη Επιχειρηματικής Δραστηριότητας (Business Activity Monitoring -ΒΑΜ) Ιδιαίτερη σημασία από επιχειρηματική σκοπιά, έχει η προσέγγιση ανάπτυξης της δυνατότητας του Διαύλου Υπηρεσιών να επιβλέπει και να παρακολουθεί τις επιχειρηματικές διαδικασίες. Η ιδέα βασίζεται στο γεγονός ότι το ESB είναι δυνατό να παρέχει τη δυνατότητα να παρακολουθείται η ανταλλαγή μηνυμάτων κατά τέτοιο τρόπο ώστε να ενημερώνει για την κατάσταση των επιχειρηματικών δραστηριοτήτων δυναμικά (on the fly) και να επιφέρει άμεση αντίδραση σε περίπτωση μεταβολών. Με άλλα λόγια, η ιδέα του BAM αποτελεί ένα είδος εργαλείου για την συλλογή άμεσων πληροφοριών πάνω στις οποίες μπορεί να στηριχτεί το ESB για την μεταβολή των διαδικασιών. Επιτυγχάνεται στηριζόμενο σε τρεις βασικές τεχνολογικές αρχές [7]: Συλλέγει Δεδομένα σε πραγματικό χρόνο: Με την τοποθέτηση εντός της επιχειρηματικής διαδικασίας της BPEL αισθητήρων που να ενεργοποιούνται κάθε φορά που εκτελείται μια συγκεκριμένη δραστηριότητα ή ένα γεγονός και να συλλέγουν τα δεδομένα που εισέρχονται. Αναλύει τις λειτουργίες και το περιεχόμενο: Εμφανίζει την ικανότητα να συσχετίσει τα διάφορα γεγονότα και να συνδυάσει τη δράση τους ώστε να αναπτύξει αντικείμενα δεδομένων με επιχειρηματικό νόημα και αξία. Δημιουργεί Interface για επιχειρηματικούς χρήστες: Με αυτό τον τρόπο είναι δυνατή η παρακολούθηση και η δυναμικη μεταβολή μέσω επιχειρηματικών κανόνων που είναι προσιτοί από επιχειρηματικούς αναλυτές Υποστήριξη κατά την Υλοποίηση Υπηρεσιών (Service Implementation Support) Τέλος,υπάρχει η δυνατότητα να συνδέεται κα να υποστηρίζει το ESB τη την ενορχήστρωση και τη σύνθεση των Υπηρεσιών. Έχει προταθεί να περιλαμβάνεται ενσωματωμένο στο ESB και τεχνολογία παραγωγής διαδικασιών ή ροών δεδομένων (processor workflow engine) ώστε να υπάρχει η δυνατότητα γραφικής αναπαράστασης κατά την παρακολούθηση των Υπηρεσιών και τοπικής δημιουργίας διαδικασιών που να συνυπάρχουν μέσα σε ένα μεγαλύτερο δίκτυο ενοποίησης.

41 Σχεδιαστικές Αρχιτεκτονικές Προσεγγίσεις Η επιλογή της σχεδιαστικής προσέγγισης που θα χρησ ιμοποιηθεί κατά την υλοποίηση το υ Διαύλου Υπηρεσιών εξαρτάται από διάφορους παράγοντες και διαφέρει ως προς τις δικαιοδοσίες και τις ευθύνες που μπορεί να μεταφέρει το ESB στους παροχείς και στους καταναλωτές. Από τη μία πλευρά, υπάρχει η δυνατότητα για απλό καθορισμό ενός πρωτοκόλλου επικοινωνίας και μεταφοράς των δεδομένων μεταφέροντας την ευθύνη της μετατροπής και καθολικής απεικόνισης των δεδομένων και την ανάγκη για δρομολόγηση στους συνεργαζόμενους φορείς. Από την άλλη, υπάρχει η επιλογή ύπαρξης εργαλείων και τεχνολογιών στο ESB που να ενεργούν κεντρικά ή όχι και να είναι υπεύθυνα για το μεγαλύτερο μέρος καθορισμού των παραμέτρων επικοινωνίας και συνδεσιμότητας μεταξύ των εμπλεκόμενων φορέων. Παρακάτω παρέχεται μια επισκόπηση των αρχιτεκτονικών προσεγγίσεων και επιχειρείται σύγκριση των διαφορετικών σχεδιαστικών τεχνικών Σύνδεση Σημείο- προς- Σημείο και Διαμεσολάβηση (Point-to- Point Connection versus Mediation) Κατά τον σχεδιασμό του Διαύλου Υπηρεσιών προκύπτει το ερώτημα για το επίπεδο της αφαιρετικότητας (abstraction) όσον αφορά τις διευθύνσεις των φυσικών συνδέσεων. Σχήμα 19 Σημείο προς Σημείο Σύνδεση (Point-to-Point Connection) Στην περίπτωση που ο καταναλωτής πρέπει να γνωρίζει την ακριβή διεύθυνση (endpoint) για την επικοινωνία του παροχέα Υπηρεσιών, η σύνδεση ονομάζεται σημείο-με-σημείο σύνδεση (point-to-point connection) και εμφανίζει το πρόβλημα πιθανής αποτυχίας της κλήσης στην περίπτωση που ο φυσικός αποδέκτης δεν είναι διαθέσιμος.στην περίπτωση που καταναλωτής δεν απαιτείται να έχει γνώση της φυσικής διεύθυνσης του παροχέα, αναγνωρίζει την προσφερόμενη Υπηρεσία από μία ετικέτα ή ένα συμβολικό όνομα που τη χαρακτηρίζει και στη συνέχεια αντιστοιχίζεται και δρομολογείται από το ESB στην κατάλληλη διεύθυνση. Η ετικέτα συνήθως περιέχει το όνομα της Υπηρεσίας και υπάρχει η περίπτωση να περιλαμβάνει και

42 επιπρόσθετες πληροφορίες και ιδιότητες που επιδρούν στη διαδικασία της δρομολόγησης. Για παράδειγμα, ο Δίαυλος Υπηρεσιών μπορεί να διαχειρίζεται προτεραιότητες ή να ακολουθεί διαφορετική πολιτική για κάθε διαφορετικό καταναλωτή. Στην περίπτωση αυτή δρα ως μεσίτης (broker) ή μεσολαβητής (mediator), γεγονός που οδηγεί σε υποδομή χαλαρής σύζευξης. Σχήμα 20 Διαμεσολάβηση (Mediation) Το πλεονέκτημα της έμμεσης προσέγγισης είναι ότι το ESB έχει τη δυνατότητα να αντιμετωπίσει δυναμικές μεταβολές στην αρχιτεκτονική της SOA προσέγγισης. Επομένως ενδεχόμενο φαινόμενο αποτυχίας στη σύνδεση δεν επηρεάζει την ομαλή λειτουργία της δρομολόγησης, καθώς η κλήση διαβιβάζεται σε ένα από τα υπόλοιπα συστήματα παροχής. Για να διαμορφωθεί η άμεση προσέγγιση και να καταστεί αποτελεσματική, το ESB είναι αναγκαίο να διαχειριστεί και να προχωρήσει στην επέκταση της πληροφορίας κατά τη στιγμή της έναρξης (startup time) ή κατά τον χρόνο της εκτέλεσης (runtime) επιτρέποντας στους παροχείς να εγγραφούν (register) όταν είναι διαθέσιμοι. Πάντως, όπως θα φανεί και στην επόμενη ενότητα, είναι δυνατή η έμμεση κλήση Υπηρεσιών και στην περίπτωση του point-to-point πρωτοκόλλου Αναχαιτιστές (Interceptors) Για να καταστεί δυνατή η υποστήριξη έμμεσων κλήσεων Υπηρεσιών στην περίπτωση point-to-point πρωτοκόλλου, γίνεται χρήση ενδιάμεσων εργαλείων που ονομάζονται proxies ή interceptors («αναχαιτιστές»). Στην απλή περίπτωση γίνεται αντικατάσταση της φυσικής διεύθυνσης παροχής της Υπηρεσίας με μια μονάδα λογισμικού που λειτουργεί ως load balancer («εξισορροπιστής φορτίων») για να εκτελέσει την δρομολόγηση της κλήσης σε διαφορετική γνωστή διεύθυνση ενός παροχέα.

43 Σχήμα 21 Αναχαιτιστής (Interceptor) Σε μια πολυπλοκότερη π ροσέγγιση, το ESB παρέχει έναν proxy ή έναν interceptor για κάθε παροχέα και για κάθε καταναλωτή. Σε αυτή την περίπτωση, ο καταναλωτής επικοινωνεί με point-to-point τρόπο μόνο με τον interceptor που του αντιστοιχεί Οδηγούμενο από πρωτόκολλο και Οδηγούμενο από API ESB (Protocol-Driven versus API-Driven ESB) Εν συνεχεία προχωράμε σε ένα είδος κατηγοριοποίησης και σύγκρισης σε ότι αφορά το σημείο από το οποίο αρχίζουν οι ευθύνες του ESB από την οπτική γωνία των καταναλωτών και των παροχέων των Υπηρεσιών. Με την οδηγούμενη από το πρωτόκολλο (protocol-driven) προσέγγιση, το ESB καθορίζει ένα πρωτόκολλο και οι παροχείς και οι καταναλωτές στέλνουν και λαμβάνουν μηνύματα σύμφωνα με το συγκεκριμένο πρωτόκολλο (πρόσεγγιση που ακολουθεί η χρήση των ΔιαδικτυακώνΥπηρεσιών). Με την οδηγούμενη από το API (Application Programming Interface) προσέγγιση, το ESB καθορίζει APIs σχετικά με κάποια πλατφόρμα λογισμικού και οι παροχείς και οι καταναλωτές χρησιμοποιούν τα συγκεκριμένα APIs για την υλοποίηση και την κλήση των Υπηρεσιών. Η διαφορά ως προς την προσέγγιση που θα χρησιμοποιηθεί διαδραματίζει ιδιαίτερα σημαντικό ρόλο κατά την διαδικασία της ανάπτυξης του Διαύλου Υπηρεσιών. Αυτό συμβαίνει διότι στην πρώτη περίπτωση το ESB καθορίζει μόνο το πρωτόκολλο και η απεικόνιση και δρομολόγηση δεδομένων και κλήσεων είναι αποκλειστικά ευθύνη τωδιαφορετικών καταναλωτών και παροχέων, καθένας από τους οποίους επιλέγει ο ίδιος τα εργαλεία και την τεχνολογία που θα αναπτύξει και θα χρησιμοποιήσει γιατην προσαρμογή στο δεδομένο πρωτόκολλου. Στην δεύτερη περίπτωση που το ESB είναι υπεύθυνο για τα APIs, το πρόβλημα της απεικόνισης των κλήσεων και της υλοποίησης των Υπηρεσιών σε καλά ορισμένα μηνύματα για την αποστολή στον Δίαυλο Υπηρεσιών είναι λειτουργία και ευθύνη του ESB.

44 Αποθήκη και Κατάλογος Υπηρεσιών (Service Repository - Service Registry) Η Αποθήκη Υπηρεσιών παρέχει πληροφορίες και διαχειρίζεται τις Υπηρεσίες από επιχειρηματική σκοπιά. Με άλλα λόγια, διαχειρίζεται τα στοιχεία που αποτελούν τις Υπηρεσίες, δηλαδή τη διαπροσωπεία τους, τα συμβόλαια, τις μεταξύ τους εξαρτήσεις, τους περιορισμούς, με αποτέλεσμα να συνεισφέρει στην αναγνώριση, ταυτοποίηση, ανάπτυξη και σχεδιασμό Υπηρεσιών. Οι πληροφορίες που παρέχει ένας Ταμιευτήρας Υπηρεσιών πρέπει να είναι ανεξάρτητες από τεχνικές λεπτομέρειες για την υλοποίηση και την υλική υποδομή των Υπηρεσιών. Από τεχνική σκοπιά, η καταγραφή των Υπηρεσιών πραγματοποιείται στον Κατάλογο Υπηρεσιών (Service Registry), όπου προσφέρονται τεχνικές πληροφορίες σχετικές με τις διαπροσωπείες των Υπηρεσιών απαραίτητες για τη χρήση τους και ικανές να χρησιμοποιηθούν για την ορθή δρομολόγηση των κλήσεων στα διαφορετικά συστήματα που παρέχουν τι ςαντίστοιχες Υπηρεσίες. Ο Κατάλογος είναι δυνατό να είναι μέρος του ESB. Η Αποθήκη Υπηρεσιών και ο Κατάλογος Υπηρεσιών είναι απαραίτητα στοιχεία του τοπίου της SOA αρχιτεκτονικής. Υπάρχει, μάλιστα, η δυνατότητα να χρησιμοποιείται ένα σύστημα και για τις δύο λειτουργίες. Μόνο που στη συγκεκριμένη περίπτωση υπάρχει ο κίνδυνος να δημιουργηθεί εξάρτηση της Αποθήκης από την υλική υποδομή που δημιουργεί πρόβλημα σε περίπτωση μελλοντικής μεταβολής της υποδομής Χαλαρή Σύζευξη (Loose-Coupling) Έχει αναφερθεί εκτενώς σε προηγούμενο κεφάλαιο η έννοια της χαλαρής σύζευξης. Αυτό που αξίζει να αναφερθεί είναι ότι αποτελεί θεμελιώδες ιδέα της SOA αρχιτεκτονικής και πρέπει να χρησιμοποιηθεί προσεκτικά κατά τον σχεδιασμό ενός πληροφοριακού συστήματος με βάση τη συγκεκριμένη αρχιτεκτονική προκειμένου να αποφευχθεί η μεγάλη πολυπλοκότητα που οδηγεί σε μειωμένους χρόνους απόκρισης και λειτουργίας Αρχιτεκτονικά Πρότυπα με Βάση την SOA Αρχιτεκτονική (SOA-based Architectural Models) Ανάλογα με την οπτική γωνία στην οποία εστιάζουμε, το διάγραμμα ενός αρχιτεκτονικού συστήματος βασισμένου στην SOA αντίληψη μπορεί να παρουσιαστεί με βάση την επιχειρηματική, τεχνικήή λογική σκοπιά Λογικό - Επιχειρηματικό Μοντέλο (Logical - Business Architectural Model) Σύμφωνα με το προτεινόμενο σχήμα που φαίνεται παραπάνω, στο λογικό αρχιτεκτονικό μοντέλο υπάρχουν διαφορετικά πεδία(domains) που διαδραματίζουν ένα συγκεκριμένο ρόλο και εμφανίζουν συγκεκριμένες ευθύνες. Ένα πεδίο (domain) είναι

45 οτιδήποτε μπορεί να αναγνωριστεί ως οργανωσιακή (organizational) φυσική οντότητα με συγκεκριμένη επιχειρηματική δομή και ξεκάθαρη οργανωτική ιδιότητα (π.χ. μπορεί να είναι μια επιχειρηματική μονάδα, μια εταιρεία, ένα εταιρικό τμήμα ή μια ομάδα). Το εσωτερικό κομμάτι της εφαρμογής (backend) αντιπροσωπεύει το τεχνικό μέρος που κρύβεται πίσω από κάθε πεδίο (domain) και περιλαμβάνει τα πληροφοριακά υποσυστήματα και τις εφαρμογές λογισμικού που βρίσκονται υπό την ευθύνη του συγκεκριμένου τμήματος. Καθώς ανεβαίνουμε ιεραρχικά το μοντέλο συναντάμε τα διάφορα είδη Υπηρεσιών με την ιεραρχία που έχουμε περιγράψει, για να καταλήξουμε τελικά στο εξωτερικό κομμάτι της εφαρμογής (frontend) που αποτελεί τη μονάδα που βρίσκεται σε διαδραστική σχέση με τον χρήστη και ξεκινά μια επιχειρηματική διαδικασία και ολοκληρώνει την εκτέλεσης συλλέγοντας τα αποτελέσματα. Χαρακτηριστικά μπορούμε να αναφέρουμε ότι ως frontend μπορεί να λειτουργήσει ένα portal,μια διαδικτυακή εφαρμογή, μια B2B εφαρμογή Τεχνικό Αρχιτεκτονικό Μοντέλο (Technical Architectural Model) Στο τεχνικό αρχιτεκτονικό μοντέλο γίνεται εμφανές ότι κυριαρχεί η τεχνική σκοπιά με τον Δίαυλο Υπηρεσιών να βρίσκεται στο κέντρο για να συντονίζει, να ελέγχει και να συνδέει τα διαφορετικά υποσυστήματα. Άξιο παρατηρήσεως είναι το γεγονός ότι οι υψηλού επιπέδου Υπηρεσίες (Process Services και Logic Services) δεν παρέχονται από τα πεδία (domains) αλλά είναι αποτέλεσμα ειδικών τεχνολογικών εργαλείων Συνδυασμός Αρχιτεκτονικών Μοντέλων (Mixed Architectural Model) Σε ένα ενδιάμεσο αρχιτεκτονικό μοντέλο με επιχειρηματική και τεχνική σκοπιά μπορούμε να παρατηρήσουμε ότι : οι Βασικές Υπηρεσίες που περιέχουν επιχειρηματική λογική μπορούν να υλοποιηθούν μέσα από μια μηχανή κανόνων (rules engine) δίνοντας την κατάλληλη ευελιξία,. οι Υπηρεσίες Διαδικασιών (Process Services) μπορούν να υλοποιηθούν και να διαχειριστούν από ένα εργαλείο BPM (Business Process Management) και οι κλήσεις των Υπηρεσιών φαίνονται ότι δρομολογούνται μέσα από τον Δίαυλο Υπηρεσιών Ασφάλεια (Security) Βασικά Χαρακτηριστικά Σε ένα κατανεμημένο πληροφοριακό σύστημα, όπως αυτά που εξετάζουμε, η ύπαρξη επαρκών μέτρων ασφάλειας θεωρείται απαραίτητη προκειμένου να εξασφαλιστεί η εύρυθμη λειτουργία. Άλλωστε, η προσβολή του συστήματος από οποιοδήποτε είδος σφάλματος είναι δυνατό να έχει σημαντικές οικονομικές συνέπειες για μια επιχείρηση δεδομένης τηςστρατηγικήςσημασίαςτωνσυστημάτων για την εξασφάλιση ανταγωνιστικού πλεονεκτήματος στην αγορά. Το θέμα της ασφάλειας έχει μια σειρά

46 προεκτάσεων που απαιτούν την προσοχή μας και εντάσσονται κυρίως στις παρακάτω κατηγορίες:[27] Επικύρωση (Authentication): Με την επικύρωση πραγματοποιείται επαλήθευση της ταυτότητας της φυσική οντότητας που απαιτεί είσοδο στο Πληροφοριακό σύστημα και αναφέρεται στην επαλήθευση του χρήστη ή της φυσικής συσκευής ή του εξωτερικού πελάτη που πρόκειται να καλέσει μια Υπηρεσία. Έγκριση-Εξακρίβωση (Authorization): Με την έγκριση καθορίζεται το είδος της ταυτότητας του χρήστη (σε όποια μορφή βρίσκεται) που καλεί την Υπηρεσία και εξακριβώνεται αν πράγματι έχει τη δυνατότητα κλήσης της και παρακολούθησης των αποτελεσμάτων. Εμπιστευτικότητα (Confidentiality): Σημαντική παράμετρος της ασφάλειας αποτελεί ο καθορισμός της αξιοπιστίας των δεδομένων κατά τη μεταφορά και την αποθήκευση τους. Όσον αφορά τις Υπηρεσίες, αυτό μεταφράζεται στην διαβεβαίωση - διασφάλιση ότι κανείς πέρα από τον χρήστη της Υπηρεσίας δεν έχει πρόσβαση στα δεδομένα κατά τη μεταφορά τους. Ακεραιότητα (Integrity): Το κλειδί στο θέμα της ακεραιότητας είναι η διασφάλιση και η εγγύηση ότι τα δεδομένα δεν μπορούν να διαχειριστούν και να πλαστογραφιθούν κατά τέτοιο τρόπο ώστε να είναι τα δεδομένα εντελώς επισφαλή και λανθασμένα ή ακόμα χειρότερα, τα αναγνωριστικά (credentials) της επικύρωσης και της εξακρίβωσης να είναι εντελώς ψευδή και κατά συνέπεια να μπορούν να αποκτήσουν πρόσβαση στα δεδομένα των Υπηρεσιών. Διαθεσιμότητα (Availability): Η ασφάλεια πρέπει να διασφαλίζει από περιπτώσεις όπου τα δεδομένα παραμένουν ακέραια και δεν διαφθείρονται, αλλά το σύστημα μεταβάλλεται κατά τέτοιο τρόπο ώστε να γίνεται αδρανές και να μην λειτουργεί. Για την αντιμετώπιση των παραπάνω θεμάτων ασφαλείας στην SOA αρχιτεκτονική χρησιμοποιούνται οι ίδιες προσεγγίσεις με προηγούμενες αρχιτεκτονικές κατανεμημένων συστημάτων. Στην περίπτωση της επικύρωσης και της έγκρισηςεξακρίβωσης, υπάρχει η ανάγκη για την υιοθέτηση αναγνωριστικών χρήστη (User IDs) και κωδικών (passwords), ενώ για την περίπτωση της ακεραιότητας και της εμπιστευτικότητας τεχνολογίες όπως κρυπτογράφηση (encryption) και ψηφιακές υπογραφές (digital signatures) μπορούν να χρησημοποιηθούν. Συγκεκριμένα, από πρακτική άποψη, η αντιμετώπιση θεμάτων ακεραιότητας και εμπιστευτικότητας μπορεί να πραγματοποιηθεί στο επίπεδο της μεταφοράς (Transport-layer Security) ή στο επίπεδο των μηνυμάτων (Message-layer security). Στο στρώμα της μεταφοράς χρησιμοποιείται το πρωτόκολλο του συστήματος υποδομής για την εισαγωγή θεμάτων ασφαλείας. Στο στρώμα των μηνυμάτων, από την άλλη πλευρά, η ασφάλεια εισάγεται στο σώμα των μηνυμάτων που ανταλλάσσονται. Τέλος, θέματα ασφαλείας εισάγονται μέσα από τη χρήση των τεχνολογιών της XML και των Διαδικτυακών Υπηρεσιών που ακολουθούν συγκεκριμένες προδιαγραφές ασφάλειας μέσα από καθορισμένα πρωτόκολλα μεταφοράς μηνυμάτων.

47 Ετερογένεια και Ασφάλεια Η SOA αρχιτεκτονική ασχολείται με επιχειρηματικές διαδικασίες που κατανέμονται μεταξύ διαφορετικών ετερογενών συστημάτων. Οι πολιτικές ασφαλείας για κάθε ένα σύστημα διαφέρουν μεταξύ τους, οπότε γίνεται αντιληπτό ότι δημιουργείται η πρόκληση για την εισαγωγή μιας γενικής ιδέας ασφάλειας πάνω από τα διαφορετικά επίπεδα ασφαλείας των διαφόρων συστημάτων Κατανεμημένες Διαδικασίες και Επίπεδα Αφαιρετικότητας Το σημαντικότερο πρόβλημα στην περίπτωση της SOA αρχιτεκτονικής είναι ότι οδηγεί σε μεγάλο αριθμό διαφορετικών επιπέδων αφαιρετικότητας. Στην περίπτωση, λοιπόν, που κάθε Υπηρεσία αποκρύπτει την επιχειρηματική λειτουργικότητα ενός κατώτερου στρώματος Υπηρεσιών, δημιουργείται και το αναγκαίο αρνητικό στοιχείο της απόκρυψης του περιεχομένου της ταυτότητας του χρήστη από την υφιστάμενη διαδικασία. Σε συνδυασμό με τα θέματα ασφαλείας που εισάγει και η ανάγκη για ετερογένεια των διαφορετικών εσωτερικών τμημάτων των εφαρμογών (backends), γίνεται αντιληπτό ότι δημιουργείται πρόβλημα εξακρίβωσης και επικύρωσης στοιχείων και αναγνωριστικών, ενώ συγχρόνως λόγω της παράλληλης εφαρμογής διαφορετικών επιπέδων ασφαλείας ανάλογα με το ρόλο του συμμετέχοντα στη διαδικασία εμφανίζεται η ανάγκη για διασφάλιση της εμπιστευτικότητας των δεδομένων μεταξύ πολλαπλών κόμβων και συνδέσεων. Για την αντιμετώπιση της ασαφούς κατάστασης των αναγνωριστικών ανάμεσα σε πολλαπλά frontends και backends, ιδανικά δημιουργείται η ανάγκη για γνώση και διαχείριση των ίδιων ταυτοτήτων και των ρόλων και των χαρακτηριστικών (profiles) με τα οποία σχετίζονται τόσο από τα frontends όσο και από τα backends για κάθε ένα χρήστη. Όσον αφορά το πρόβλημα της εμπιστευτικότητας και της ακεραιότητας των δεδομένων που κατανέμονται μεταξύ των διαφορετικών συστημάτων, προκειμένου να αποφευχθεί η διαστρέβλωση και η υποκλοπή τους είναι αναγκαία η ύπαρξη ασφαλεία ς σε επίπεδο μηνυμάτων (message-layer security) ώστε να μην επηρεάζεται από οποιοδήποτε υποσύστημα κι αν προσπελαστεί. [26] 3.3 SOA Τεχνολογίες Προκειμένου να θεμελιωθεί το οικοδόμημα της Υπηρεσιοστραφούς Αρχιτεκτονικής κ αι να γίνει πραγματικότητα η τεχνική και προγραμματιστική υλοποίηση της ήταν απαραίτητος ο ερχομός και η τελειοποίηση τεχνολογιών και τεχνολογικών εργαλείων βασισμένων σε πρότυπα δια δικτυακής επικοινωνίας (XML-based, HTTP-based) και επιχειρηματικού σχεδιασμού που διευκόλυναν τον σχεδιασμό των επιχειρηματικών διαδικασιών και την επικοινωνία και μεταφορά πληροφοριών μεταξύ ετερογενών συστημάτων. Στη συνέχεια αναλύονται με λεπτομέρεια οι συγκεκριμένες τεχνολογίες Διαδικτυακές Υπηρεσίες (Web Services) Οι Διαδικτυακές Υπηρεσίες αποτελούν την τελευταία τεχνολογία για την επικοινωνία

48 μεταξύ κατανεμημένων συστημάτων (distributed technology) και έχουν επικρατήσει ως η περισσότερη αποδεκτή τεχνολογία για να επιτευχθεί και να γίνει πραγματικότητα η SOA αρχιτεκτονική. Έχουν γίνει η κοινά αποδεκτή και περισσότερο χρησιμοποιήσιμη τεχνολογία για την πραγμάτωση και υλοποίηση της έννοιας της ολοκλήρωσης και της ενοποίησης εφαρμογών και πληροφοριακών συστημάτων. Οι Διαδικτυακές Υπηρεσίες παρέχουν τα τεχνολογικά θεμέλια για την επίτευξη τη ολοκλήρωσης μεταξύ εφαρμογών που χρησιμοποιούν διαφορετικά ετερογενή λειτουργικά συστήματα, πλατφόρμες λογισμικού και γλώσσες προγραμματισμού. Από τεχνικής σκοπιάς στηρίζονται και υλοποιούνται σε γλώσσα XML. Ενώ, λοιπόν, η XML έχει επικρατήσει ως το de facto πρότυπο ενοποίησης σε επίπεδο δεδομένων, οι Διαδικτυακές Υπηρεσίες έχουν επικρατήσει ως de facto πρότυπο σε επίπεδο Υπηρεσιών μεταξύ των επιχειρήσεων. Από τεχνολογική σκοπιά, οι Διαδικτυακές Υπηρεσίες είναι ένα είδος κατανεμημένης αρχιτεκτονικής. Το προγραμματιστικό παράδειγμα (paradigm) της κατανεμημένης αρχιτεκτονικής ξεκίνησε με το DCE (Distributed Computing Environment), το RPC (Remote Procedure Call) και τα συστήματα που ήταν προσανατολισμένα στην ανταλλαγή μηνυμάτων (Message-Oriented Middleware όπως τα MQ Series, MSMQ). Στη συνέχεια ακολούθησαν τα κατανεμημένα αντικείμενα και οι ανάλογοι Μεσίτες που ονομάζονταν ORBs (Object Request Brokers), όπως η CORBA αρχιτεκτονική (Common Object Request Broker Architecture), το μοντέλο DCOM (Distributed Component Object Model) και το RMI (Remote Method Invocation) για να καταλήξουμε στα λεγόμενα component models, όπως τα EJB (Enterprise Java Beans), COM+(Component Object Model),.NET Enterprise Services και το μοντέλο CCM (CORBA Component Model). Η διαφορά που οδήγησαν στην υιοθέτηση των Διαδικτυακών Υπηρεσιών έναντι των προηγούμενων μοντέλων που αναφέρθηκαν ήταν η καθολική αποδοχή που είχαν από τις εταιρείες λογισμικού λόγω της εφαρμογής σε κάθε τεχνολογία λογισμικού. O [18] αναφέρει συγκεκριμένα ότι «Η σύγχρονη SOA αρχιτεκτονική αντιπροσωπεύει μια αρχιτεκτονική που προωθεί τον προσανατολισμό στις Υπηρεσίες και αποτελείται από υπηρεσίες που υλοποιούνται ως Διαδικτυακές Υπηρεσίες». Και ο [12] είχε προβλέψει ότι «το 2006 πάνω από το 60% των $527 δις που δαπανούν οι εταιρίες πληροφορικής θα στηριχτεί στην εκμετάλλευση των δυνατοτήτων του πρότυπου και της τεχνολογίας των Διαδικτυακών Υπηρεσιών». Επομένως, αποτελούν την πρώτη τεχνολογία που ικανοποιεί την υπόσχεση για καθολική ολοκλήρωση μεταξύ εφαρμογών που εκτελούνται σε διαφορετικά συστήματα. Οι βασικές προδιαγραφές στις οποίες στηρίζονται οι Διαδικτυακές Υπηρεσίες είναι το πρωτόκολλο SOAP (Simple Object Oriented Protocol), η WSDL (Web Services Description Language) και το UDDI (Universal Description, Discovery and Integration). Οι παραπάνω τεχνολογίες στηρίζονται εξ ολοκλήρου στην γλώσσα XML, καθιστώντας τα μηνύματα και την περιγραφή των Διαδικτυακών Υπηρεσιών αναγνώσιμα από άνθρωπο (human readable) χωρίς τεχνολογικές γνώσεις λογισμικού. Από αρχιτεκτονική σκοπιά, οι Διαδικτυακές Υπηρεσίες μπορούν να λειτουργήσουν έχοντας οποιοδήποτε ρόλο και εισάγουν σημαντικές αλλαγές σε σχέση με τις προηγούμενες τεχνολογίες, με αποτέλεσμα να επικρατήσουν ως το σύγχρονο πρότυπο για τους παρακάτω λόγους : Οι Διαδικτυακές Υπηρεσίες υποστηρίζουν τη δυνατότητα χαλαρής σύζευξης μέσω λειτουργιών που ανταλλάσουν μόνο δεδομένα, γεγονός που διαφέρει από τα μοντέλα Component και κατανεμημένων αντικειμένων, όπου εκτός των δεδομένων ανταλλάσσεται και η συμπεριφορά. Οι λειτουργίες στην περίπτωση των Διαδικτυακών Υπηρεσιών βασίζεται

49 στην ανταλλαγή μηνυμάτων σε XML μορφή που αποτελούνται από ένα δομημένο σύνολο εισόδων, εξόδων και μηνυμάτων λάθους. Ο συνδυασμός των μηνυμάτων καθορίζει τον τύπο της λειτουργίας (μονόδρομη ή one-way, αίτημα/απόκριση ή request/response, μόνο απόκριση ή solicit response ή ανακοίνωση ή notification) που διαφέρει από προηγούμενες τεχνολογίες. Οι Διαδικτυακές Υπηρεσίες είναι stateless, δηλαδή δεν ακολουθούν το παράδειγμα των αντικειμένων. Οι Διαδικτυακές Υπηρεσίες παρέχουν υποστήριξη και στην περίπτωση ασύγχρονων (όπου δεν είναι αναγκαία η άμεση απόκριση προκειμένου να συνεχιστεί η εκτέλεση της λειτουργίας) και στην περίπτωση σύγχρονων (όπου απαιτείται άμεση απόκριση προκειμένου να συνεχιστεί η εκτέλεση της λειτουργίας) αλληλεπιδράσεων. Οι Διαδικτυακές Υπηρεσίες εισάγουν την έννοια και την ιδέα των endpoints και των intermediaries (μεσάζοντες), με αποτέλεσμα να αναπτύσσονται νέες προσεγγίσεις κατά τη διαχείριση μηνυμάτων. Οι Διαδικτυακές Υπηρεσίες χρησιμοποιούν πρότυπα διαδικτυακά πρωτόκολλα (standard internet protocols) όπως το HTTP (Hyper Text Transfer Protocol), το SMTP (Simpl Transfer Protocol), το FTP (File Transfer Protocol) και το MIME(Multipurpose Internet Mail Extentions) Επομένως, η συνδεσιμότητα μέσα από κλασικές διαδικτυακές συνδέσεις, ακόμα και μέσα από εκείνες που προφυλάσσονται από firewalls, είναι λιγότερο προβληματική σε σχέση με προηγούμενες προσεγγίσεις που είχαν επικρατήσει. Τέλος, αξίζει να αναφέρουμε τις tεχνικές προδιαγραφές που εισάγουν οι Διαδικτυακές Υπηρεσίες για νααντιμετωπίσουν θέματα ασφαλείας, συναλλαγών και ανταλλαγής μηνυμάτων. Συγκεκριμένα περιγράφουμε τις κυριότερες από αυτές που είναι οι εξής : WS-Security [24]: Είναι υπεύθυνο και διευθύνει θέματα (authentication) και ασφάλειας σε επίπεδο ανταλλαγής μηνυμάτων, ενώ συγχρόνως επιτρέπει την ασφαλή επικοινωνία μέσω της τεχνολογίας των Διαδικτυακών Υπηρεσιών. WS-Coordination [20]: Καθορίζει ένα πλαίσιο συντονισμού (Coordination Framework) για τις συναλλαγές μέσω Διαδικτυακών Υπηρεσιών και είναι το θεμέλιο πάνω στο οποίο στηρίχθηκε η ανάπτυξη των WS-Atomic Transaction και WS-Business Activity. Transaction Specification (WS Atomic Transaction και WSBusinessActivity[19]: Καθορίζει και παρέχει υποστήριξη για τις συναλλαγές μεταξύ κατανεμημένων συστημάτων μέσω των Διαδικτυακών Υπηρεσιών. Το AtomicTransaction καθορίζει το πλαίσιο συναλλαγών για μικρό χρονικό διάστημα και τις ACID συναλλαγές, ενώ το BusinessActivity καθορίζει κατανεμημένες επιχειρηματικές συναλλαγές μεγαλύτερης διάρκειας. WS-Reliable Messaging: Παρέχει υποστήριξη για αξιόπιστη και συνεπή επικοινωνία και παράδοση μηνυμάτων μεταξύ των Διαδικτυακών Υπηρεσιών (Web Services) πάνω από διάφορα πρωτόκολλα μεταφοράς και επικοινωνίας. WS-Addressing:Καθορίζει το συντονισμό και τη δρομολόγηση των μηνυμάτων. WS-Inspection: Παρέχει υποστήριξη για δυναμική ανακάλυψη εγγράφων που

50 περιγράφουν τη λειτουργία των Υπηρεσιών. WS-Policy: Καθορίζει τον τρόπο με τον οποίο οι διάφορες πολιτικές ανακηρύσσονται και ανταλλάζονται μεταξύ των συνεργαζόμενων Διαδικτυακών Υπηρεσιών (Web Services). WS-Eventing [21]: Ορίζει ένα μοντέλο στηριζόμενο στην ύπαρξη συμβάντων (event model) για ασύγχρονη και σύγχρονη επικοινωνία. Οι συγκεκριμένες προδιαγραφές αποτελούν το λεγόμενο «τεχνολογικό υπόβαθρο των Διαδικτυακών Υπηρεσιών» (Web Services Technology Stack) και είναι απαραίτητες για την πλήρη και ασφαλή χρήση των Διαδικτυακών Υπηρεσιών σε επιχειρησιακές εφαρμογές. Λόγω της ευελιξίας, της εφαρμογής της ολοκλήρωσης και των υπόλοιπων χαρακτηριστικών που εμφανίζουν οι Διαδικτυακές Υπηρεσίες (Web Services) θεωρούνται ως η καταλληλότερη τεχνολογία για να έκθεση της λειτουργικότητας των επιχειρηματικών διαδικασιών ως Υπηρεσίες και επομένως αποτελούν την καταλληλότερη τεχνολογία για την πραγμάτωση της SOA αρχιτεκτονικής. Εξαιτίας της ευρείας υποστήριξης που έχουν από τους κατασκευαστές λογισμικού, οι Διαδικτυακές Υπηρεσίες παρέχουν τη δυνατότητα να χρησιμοποιηθεί η ίδια τεχνολογία για να αναπαρασταθούν Υπηρεσίες που η υλοποίηση τους περιλαμβάνει εφαρμογές, οι οποίες εκτείνονται από εφαρμογές legacy συστημάτων μέχρι τις σύγχρονες multi-tier (πολύ-επίπεδες) εφαρμογές Διαχείριση Επιχειρηματικών Διαδικασιών BPM (Business Process Management) Η διαχείριση επιχειρηματικών διαδικασιών ή business process management αποτελεί ένα σημαντικό σύγχρονο πεδίο έρευνας τόσο από πρακτική σκοπιά λόγω της επιχειρηματικής χρησιμότητας που παρουσιάζει στο σχεδιασμό των επιχειρησιακών διαδικασιών και εφαρμογών, όσο και ως εργαλείο ανάπτυξης και σχεδίασης λογισμικού για την ανάπτυξη επιχειρηματικών εφαρμογών. Η διαχείριση επιχειρηματικών διαδικασιών στηρίζεται στην παρατήρηση ότι κάθε προϊόν ή υπηρεσία που παρέχει κάθε επιχείρηση στην αγορά είναι αποτέλεσμα μιας σειράς εκτέλεσης επιμέρους δραστηριοτήτων [5]. Οι επιχειρηματικές διαδικασίες αποτελούν το εργαλείο-κλειδί για την οργάνωση των παραπάνω επιμέρους δραστηριοτήτων και τη βελτίωση της κατανόησης των σχέσεων μεταξύ τους. Η σύγχρονη επιχείρηση προκειμένου να επιτύχει τους στρατηγικούς της στόχους, είναι αναγκαίο να οργανώσει και να οδηγήσει τους επιχειρηματικούς και υπολογιστικούς της πόρους σε συνεργασία, γεγονός στο οποίο αποφασιστική συμβολή έχουν οι επιχειρηματικές διαδικασίες. Η ευρύτατη εξάπλωση της τεχνολογίας των ενδοδικτύων (intranets) και του διαδικτύου (internet) καθιστά τον ανταγωνισμό ιδιαίτερα απαιτητικό και την ανάγκη για άμεση προσαρμογή στις επιταγές της αγοράς το σύγχρονο ζητούμενο, με αποτέλεσμα οι παραδοσιακοί κύκλοι παραγωγής προϊόντων να μην επαρκούν να περιγράψουν το πλαίσιο της δυναμικότητας των σύγχρονων καταστάσεων της οικονομίας. Γίνεται, λοιπόν, φανερό ότι η διαχείριση επιχειρηματικών διαδικασιών έρχεται για να περιορίσει το χάσμα μεταξύ της οργανωσιακής επιχειρησιακής πλευράς και των πληροφοριακών συστημάτων στα οποία

51 στηρίζεται σε μεγάλο βαθμό η επιτυχία των σύγχρονων επιχειρήσεων. Επομένως, ως διαχείριση επιχειρηματικών διαδικασιών μπορεί να οριστεί ένα σύνολο από δραστηριότητες που εκτελούνται σε συντονισμό και συνεργασία στα πλαίσια ενός τεχνικού και οργανωσιακού περιβάλλοντος. Οι συγκεκριμένες δραστηριότητες από κοινού πραγματοποιούν έναν επιχειρηματικ στόχο. Η διαχείριση επιχειρηματικών διαδικασιών περιλαμβάνει ιδέες, μεθόδους και τεχνικές που χρησιμοποιούνται για το σχεδιασμό, τη διαχείριση, τη διαμόρφωση και την ανάλυση τω ν επιχειρηματικών διαδικασιών. Κυρίαρχο ρόλο στη διαχείριση των επιχειρηματικών διαδικασιών διαδραματίζει η χρήση μεθόδων μοντελοποίησης των επιχειρηματικών διαδικασιών (business process modeling)που στηρίζονται στην ανάπτυξη γραφικών εργαλείων και σημειογραφίας των βασικών παραγόντων που συνθέτουν τις επιχειρηματικές διαδικασίες. Παράλληλα, η διαχείριση των επιχειρηματικών διαδικασιών στηρίζεται στην ανάπτυξη και την κατάστρωση ροών δεδομένων και στην εφαρμογή μεθόδων διαχείρισης διαγραμμάτων ροής εργασιών (workflow management). Προϊόντα που έχουν αναπτυχθεί στα πλαίσια της τεχνικής του BPM είναι: IBM swebsphere, HP s HP Process Manager, BEA s WebLogic, και Vitria s BusinessWare, JBoss jbpm, Microsoft BizTalk (περιοριζόμενο μόνο σε εφαρμογές Microsoft Windows and.net servers). [29] BPEL (Business Process Execution Language) Εισαγωγή Ως επιχειρηματική διαδικασία έχει αναφερθεί ότι ορίζεται μια διαδικασία που σχεδιάζει μια επιχείρηση και αποτελεί μέρος ενός μεγαλύτερου επιχειρηματικού σκοπού προκειμένου να διευκολύνει και να καθορίσει τη ροή δεδομένων και τη λήψη αποφάσεων. Ουσιαστικά, αποτελεί μια σειρά από ατομικές αυτόνομες δραστηριότητες με κάθε δραστηριότητα να εκτελείται με καθορισμένη σειρά. Η αυτοματοποίηση των επιχειρηματικών διαδικασιών έχει υιοθετηθεί ως απαραίτητο στοιχείο της οργάνωσης των σύγχρονων επιχειρήσεων και επομένως, η απαίτηση για μια πρότυπη θεμελίωση με τη μέθοδο μιας εξειδικευμένης προγραμματιστικής γλώσσας για τη σύνθεση των δραστηριοτήτων φαντάζει ως σημαντικό ζητούμενο. Προς τη συγκεκριμένη κατεύθυνση και υπό το πλαίσιο της υιοθέτησης της SOA αρχιτεκτονική ως τη σύγχρονη σχεδιαστικής λύση για την προώθηση της ευελιξίας στις επιχειρηματικές διαδικασίες, αναδύθηκε η BPEL ως η κυρίαρχη πρότυπη γλώσσα σύνθεσης υπηρεσιών μέσα από έναν καλά ορισμένο τρόπο και μεθοδολογία. Ο πρωταρχικός στόχος, λοιπόν, της BPEL είναι η προτυποποίηση της διαδικασίας αυτοματοποίησης μεταξύ των Διαδικτυακών Υπηρεσιών. Συνεπώς είναι εμφανές ότι με τη συμβολή της BPEL δίνεται η δυνατότητα να οριστούν επιχειρηματικές διαδικασίες που κάνουν χρήση των Υπηρεσιών για τη σύνθεση μεγαλύτερων διαδικασιών και επιχειρηματικές διαδικασίες που εξωτερικεύουν τη λειτουργικότητα τους ως Υπηρεσίες. Εντός των επιχειρήσεων, η BPEL χρησιμοποιείται για την τυποποίηση και την ολοκλήρωση επιχειρησιακών εφαρμογών και για την επέκταση της ενοποίησης σε προηγουμένως απομονωμένα συστήματα. Μεταξύ των επιχειρήσεων, η BPEL επιτρέπει ευκολότερη και περισσότερο αποτελεσματική ολοκλήρωση και ενοποίηση με τους επιχειρηματικούς συνεργάτες. Η BPEL υποκινεί τις επιχειρήσεις να καθορίσουν περαιτέρω τις διαδικασίες τους, με αποτέλεσμα να οδηγηθούν στην βελτιστοποίηση των επιχειρηματικώ διαδικασιών και της επιχειρησιακής οργάνωσης, στον

52 επανασχεδιασμό των λειτουργιών τους (reengineering) και στην επιλογή των καταλληλότερων κάθε φορά διαδικασιών. Η BPEL αποτελεί τεχνολογία κλειδί σε επιχειρησιακ ά περιβάλλοντα όπου η επιχειρηματική λειτουργικότητα εκφράζεται ή εκτίθενται ως Διαδικτυακές Υπηρεσίες Χαρακτηριστικά Με την BPEL μπορούμε να ορίσουμε τόσο απλές όσο και πολύπλοκες διαδικασίες. Ως προγραμματιστική γλώσσα εμφανίζει χαρακτηριστικά κοινά με τις παραδοσιακές γλώσσες προγραμματισμού παρέχον τας στοιχεία όπως βρόχους, κόμβους αποφάσεων, διακλαδώσεις, μεταβλητές που επιτρέπουν τον ορισμό επιχειρηματικών διαδικασιών με αλγοριθμικό τρόπο. Η BPEL είναι μια τυποποιημένη γλώσσα που εστιάζει στον ορισμό επιχειρηματικών διαδικασία με τη χρήση σημαντικών στοιχείων που σχετίζονται με την επίκληση των Διαδικτυακών Υπηρεσιών. Η BPEL επιτρέπει τη ν κλήση των λειτουργιών των Διαδικτυακών Υπηρεσιών είτε με ασύγχρονο είτε με σύγχρονο τρόπο. Επίσης, επιτρέπει την κλήση λειτουργιών είτε σε σειρά είτε παράλληλα, ενώ δίνεται η δυνατότητα διαχείρισης σφαλμάτων με εύχρηστο και καλά τεκμηριωμένο τρόπο. Παράλληλα, η BPEL στηρίζεται σε XML μορφή κώδικα και παρέχει υποστήριξη για μεγάλης διάρκειας διαδικασίες και αποζημίωση των δραστηριοτήτων σε περίπτωση ασυνεπειών. Ενδεικτικά, αναφέρουμε τα παρακάτω χαρακτηριστικά που προσφέρει η BPEL: Περιγραφή της λογικής των επιχειρηματικών διαδικασιών μέσα από την σύνθεση των Υπηρεσιών. Σύνθεση μεγαλύτερων επιχειρηματικών διαδικασιών από μικρότερες διαδικασίες και Υπηρεσίες. Κλήση και διαχείριση τόσο σύγχρονων όσο και ασύγχρονων λειτουργιών των Υπηρεσιών. Κλήση των λειτουργιών των Υπηρεσιών τόσο σε σειρά όσο και παράλληλα Επιλεκτική αποζημίωση και ακύρωση ολοκληρωμένων δραστηριοτήτων σε περίπτωση προγραμματιστικών σφαλμάτων. Συντήρηση πολλαπλών και χρονοβόρων σε διάρκεια εκτέλεσης δραστηριοτήτων συναλλαγών. Διαχείριση γεγονότων σχετιζόμενων τόσο με την αναμονή ύπαρξης μηνύματος πυροδότησης όσο και με την ύπαρξη χρονομέτρου που υπολογίζει απαιτούμενους χρόνους παρέλευσης. Δόμηση των επιχειρηματικών διαδικασιών σε διαφορετικά επίπεδα αφαιρετικότητας και φάσματος. Παράλληλη εκτέλεση δραστηριοτήτων και καθορισμός του τρόπου με τον οποίο συγχρονίζονται και συγχέουν τη λειτουργία τους. Προγραμματισμός των δραστηριοτήτων με βάση τον χρόνο εκτέλεσης και καθορισμό της σειράς εκτέλεσης τους. Συσχέτιση των αιτημάτων (requests) εντός των επιχειρηματικών διαδικασιών. Δρομολόγηση εισερχόμενων μηνυμάτων στα κατάλληλες διαδικασίες και δραστηριότητες. Διατήρηση διαδικασιών που έχουν διακοπεί λόγω σφάλματος ως το σημείο που ορθής εκτέλεσης, ώστε να περιοριστεί η άσκοπη ενασχόληση με περιττές εργασίες που δεν παρουσιάζουν σφάλματα.

53 Σύνθεση Υπηρεσιών (Service Composition) Στην SOA αρχιτεκτονική, προκειμένου να πετύχουμε το βέλτιστο δυνατό αποτέλεσμα στην οργάνωση και το ν σχεδιασμό των επιχειρηματικών διαδικασιών και να οδηγηθούμε στην επαναχρησιμοποίηση των Υπηρεσιών, δημιουργείται η ανάγκη για τη σύνθεση Υπηρεσιών από ήδη υπάρχουσες Υπηρεσίες. Συνεπώς για την περιγραφή και την πραγματοποίηση πολύπλοκων επιχειρηματικών λειτουργιών και ανάλογα με τις απαιτήσεις και το σχεδιαστικό πρότυπο που πρόκειται να ακολουθηθεί, υπάρχει η δυνατότητα σύνθεσης των Υπηρεσιών με βάση δύο βασικές προσεγγίσεις οργάνωσης της ροής των συναλλαγών που θα αναλυθούν εκτενώς σε επόμενη ενότητα και αναφέρονται ως [18]: Ενορχήστρωση Χορογραφία Σε μια προσπάθεια ορισμού της έννοιας της σύνθεσης Υπηρεσιών, έχει προταθεί μεγάλος αριθμός διαφορετικών προσεγγίσεων [ ] χωρίς να υπάρχει ένας ικανοποιητικός ορισμός που να καλύπτει πλήρως το εύρος των επιχειρηματικών διαδικασιών. Η καλύτερη προσέγγιση για το σχεδιασμό μιας επιχειρηματικής διαδικασίας είναι η ανάλυση του ρόλου της και ο περιορισμός της προσοχής στο επίπεδο της επιχείρησης ως σύνολο. Πρέπει να αναλυθεί με βάση διάφορες όψεις της επιχειρηματικής δραστηριότητας, όπως με βάση την ανταλλαγή των δεδομένων, το διαχωρισμό των βασικών λειτουργικών μονάδων, την οργάνωση της ροής και την [3] γίνεται διαχωρισμός μεταξύ της διαχείρισης των αναγκαίων πόρων [1]. Στο λειτουργικής, της οργανωσιακής και της πληροφοριακής οπτικής γωνίας των επιχειρηματικών διαδικασιών. Στο [4] υιοθετείται το πρότυπο και πλαίσιο ανάλυσης της επιχειρηματικής διαδικασίας που προτείνεται στο [11] και διακρίνει τα βασικά στοιχεία της επιχειρηματικής διαδικασίας με βάση τις όψεις του π ώς, γιατί, πότε, ποιός, τι και που, με αποτέλεσμα να αποδομείται η επιχειρηματική διαδικασία στα βασικά χαρακτηριστικά της βάσει των απαντήσεων στις παραπάνω ερωτήσεις. Τελικά, μπορούμε να αναγνωρίσουμε τα παρακάτω βασικά χαρακτηριστικά των επιχειρηματικών διαδικασιών : Δραστηριότητα (Activity): Μια δραστηριότητα αντιπροσωπεύει μια καλά ορισμένη επιχειρησιακή λειτουργία και αποτελεί μέρος της όψης του πώς. Πρόκειται για το στοιχείο της επιχειρηματικής διαδικασίας που υπαγορεύει τον τρόπο υλοποίησης και κλήσης μιας δράσης-ενέργειας. Συνθήκη (Condition): Η συμπεριφορά της επιχειρηματικής διαδικασίας ελέγχεται και οδηγείται από την επιχειρηματική λογική και τους κανόνες. Επομένως η συνθήκη είναι το χαρακτηριστικό της επιχειρηματικής διαδικασίας που αποτιμάται και ελέγχεται, ώστε να αποφασιστεί η ροή ελέγχου της διαδικασίας. Αντιστοιχεί στην όψη του γιατί.

54 Σχήμα 22 Σύνθεση Υπηρεσιών Γεγονός-Συμβάν (Event): Τα γεγονότα κατά τη σύνθεση των Υπηρεσιών αντιστοιχούν σε πραγματικά επιχειρησιακά συμβάντα που πραγματοποιούνται και μεταβάλλουν ή καθορίζουν τη ροή της επιχειρηματικής διαδικασίας. Αποτελούν μέρος της όψης του πότε, γιατί υπαγορεύουν το χρονικό σημείο πυροδότησης ενός γεγονότος. Ροή (Flow): Η ροή εκφράζει και αυτή την όψη του πώς και χρησιμοποιείται για να καταδείξει την οργάνωση και την ενορχήστρως των συμμετεχόντων δραστηριοτήτων. Πρόκειται για τους συνήθεις τύπους - πρότυπα επιλογής ροής, δηλαδή σειριακή - ακολουθιακή ροή, παράλληλη ροή, ροή με βάση συνθήκη, επαναληπτική ροή και συνδυασμός των παραπάνω. Μήνυμα (Message): Μηνύματα χρησιμοποιούνται προκειμένου να επιτύχουμε την ανταλλαγή πληροφοριών μεταξύ των διαφορετικών συναλλασσόμενων. Τα μηνύματα αντιπροσωπεύουν την όψη του τι, καθώς εκφράζουν το είδος των δεδομένων και τις εξαρτήσεις και αλληλεπιδράσεις που υφίστανται. Παροχέας (Provider): Οι συμμετέχοντες - άνθρωποι και υπολογιστικοί πόροι που αποτελούν μέλη της επιχειρηματικής διαδικασίας απεικονίζονται με τη μορφή του παροχέα. Ο παροχέας ανήκει την όψη του ποιος και που και πρόκειται για μια συμπαγή Υπηρεσία. Ρόλος (Role): Οι ρόλοι αποτελούν τμήμα της όψης του ποιός και καθορίζουν την αναμενόμενη συμπεριφορά των συμμετεχόντων στην επιχειρηματική διαδικασία με ένα αφαιρετικό τρόπο Ενορχήστρωση και Χορογραφία Στην περίπτωση οργάνωσης της ροής των επιχειρηματικών διαδικασιών με βάση το πρότυπο της ενορχήστρωσης, μια κεντρική διαδικασία αναλαμβάνει τον συνολικό έλεγχο και τη διαχείριση των υπηρεσιών που λαμβάνουν μέρος, και συντονίζει την εκτέλεση των διαφορετικών λειτουργιών της κάθε υπηρεσίας. Πρόκειται, με άλλα λόγια, για μια προσέγγιση όπου η ολοκλήρωση των εφαρμογών επιτυγχάνεται βάσει μιας κεντρικά ελεγχόμενης ροής εργασιών (workflow). Οι Διαδικτυακές Υπηρεσίες που συμμετέχουν δε γνωρίζουν ότι είναι μέλη μιας επιχειρηματικής διαδικασίας και ότι αποτελούν αναπόσπαστο τμήμα της ροής μιας υψηλότερου επιπέδου

55 υπηρεσίας. Μ όνο η υπηρεσία που δρα ως κεντρικός διαχειριστής και συντονιστής γνωρίζει τη συμμετοχή και το ρόλο που διαδραματίζει για την πραγμάτωση της επιχειρηματικής διαδικασίας, κατά τέτοιο τρόπο ώστε η ενορχήστρωση να οργανώνεται και να μορφοποιείται γύρω από αυτήν με σαφή καθορισμό των λειτουργιών και της σειράς με την οποία πρόκειται να κληθούν οι Διαδικτυακές Υπηρεσίες. Σχήμα 23 Ενορχήστρωση Η προσέγγιση της ενορχήστρωσης προσφέρει ένα περιβάλλον ενοποίησης με διάφορες εφαρμογές ενός οργανισμού έστω κα ι αν αυτές βασίζονται σε διαφορετικές πλατφόρμες. Τέλος, υπάρχει η δυνατότητα μεταβολής ή επέκτασης της λογικής της ροής εργασίας, διευκολύνεται η συγχώνευση των επιχειρηματικών διαδικασιών και εξωτερικεύεται η συμπεριφορά της διαδικασίας ως υπηρεσία με καθορισμένο περιεχόμενο. Στην περίπτωση οργάνωσης τ ης ροής των επιχειρηματικών διαδικασιών με βάση το πρότυπο της χορογραφίας, δεν υπάρχει κεντρική διαδικασία που να αναλαμβάνει τον έλεγχο της ροής εκτέλεσης των υπηρεσιών, αλλά κάθε υπηρεσία είναι υπεύθυνη από μόνη της να προσδιορίσει και να εκτελέσει το περιεχόμενο της και να συντονίσει τη λειτουργία της με βάση τη ροή της διαδικασίας. Με άλλα λόγια, κάθε συμμετέχων παράγοντας της επιχειρηματικής διαδικασίας γνωρίζει με ακρίβεια τη στιγμή που θα εκτελέσει τη λειτουργία της και τους διαφορετικούς παράγοντες με τους οποίους αλληλεπιδρά. Μια τυπική προσέγγιση που εμφανίζει τον χαρακτήρα της χορογραφίας, αποτελεί η υλοποίηση αλυσίδας διαδικασιών με ακολουθιακή πορεία και καθορισμένη σειρά εκτέλεσης.

56 Σχήμα 24 Χορογραφία Η προσέγγιση της χορογραφίας αποτελεί μια προσπάθεια συνεργασίας που επικεντρώνεται στην ανταλλαγή μηνυμάτων μεταξύ επιχειρηματικών διαδικασιών, για την εκτέλεση των οποίων έχει συμφωνηθεί η ροή εργασίας που θα ακολουθηθεί και έχει εγκατασταθεί ένα πλαίσιο συνεργασίας μεταξύ των υπηρεσιών που συμμετέχουν. Υπό ιδανικές συνθήκες, η μέθοδος της χορογραφίας μπορεί να εφαρμοστεί σε δημόσιο και διεπιχειρησιακό επίπεδο, όπου οι οργανισμοί θα μπορούσαν να συμφωνήσουν πάνω στη δομή των εσωτερικών διεργασιών τους προκειμένου να διαλειτουργήσουν και να επιτύχουν αυτή την επιδίωξή τους βασιζόμενες σε αυτοματοποιημένες λύσεις. Ειδικότερα στη σημερινή εποχή όπου οι απαιτήσεις ολοκλήρωσης είναι ιδιαίτερα αυξημένες μια πληθώρα υπηρεσιών διαφορετικών επιχειρήσεων ζητούν τρόπο συνεργασίας. Ένα αντιπροσωπευτικό παράδειγμα προτύπου που επιδιώκει την οργάνωση της ανταλλαγής πληροφοριών μεταξύ πολλαπλών οργανισμώνείναι το WS-CDL[22 23]. Από την οπτική της σύνθεσης Διαδικτυακών Υπηρεσιών για την εκτέλεση επιχειρηματικών διαδικασιών, η προσέγγιση της ενορχήστρωσης, ως περισσότερο ευέλικτο σχήμα οργάνωσης της ροής εκτέλεσης, παρουσιάζει πλεονεκτήματα έναντι της χορογραφίας που συνοψίζονται στα εξής : Είναι γνωστός ο παράγοντας που είναι υπεύθυνος για το συντονισμό και την εκτέλεση ολόκληρης της επιχειρηματικής διαδικασίας. Υπάρχει η δυνατότητα εναλλαγής και εναλλακτικής μετατροπής της ροής σε περίπτωση σφάλματος. Υπάρχει η δυνατότητα συγχώνευσης και ενσωμάτωσης υπηρεσιών χωρίς να γνωρίζουν ότι αποτελούν τμήμα επιχειρηματικής διαδικασίας Εκτελέσιμες και Αφαιρετικές Διαδικασίες (Executable and Abstract Processes) Με τη βοήθεια της BPEL, μπορούμε να διακρίνουμε τις επιχειρηματικές διαδικασίες σε δύο κατηγορίες :

57 Στις επιχειρηματικές διαδικασίες, στις οποίες μπορούμε να καθορίσουμε με ακρίβεια τις λεπτομέρειες σχεδιασμού και υλοποίησης τους και ονομάζονται εκτελέσιμες επιχειρηματικές διαδικασίες (executable business processes). Οι εκτελέσιμες επιχειρηματικές διαδικασίες ακολουθούν το πρότυπο της ενορχήστρωσης. Στις επιχειρηματικές διαδικασίες, στις οποίες μπορούμε να καθορίσουμε και να παρακολουθήσουμε την ανταλλαγή των μηνυμάτων που πραγματοποιείται μεταξύ των συνεργαζόμενων παραγόντων και ονομάζονται αφαιρετικές επιχειρηματικές διαδικασίες. Οι αφαιρετικές επιχειρηματικές διαδικασίες ακολουθούν το πρότυπο της χορογραφίας και δεν περιλαμβάνουν εσωτερικές λεπτομέρειες υλοποίησης, ενώ συγχρόνως είναι αδύνατο να εκτελεστούν. Οι εκτελέσιμες επιχειρηματικές διαδικασίες είναι διαδικασίες που συνθέτουν και συνδυάζουν ένα σύνολο υπαρχουσών υπηρεσιών, ενώ παράλληλα καθορίζουν τον ακριβή αλγόριθμο υλοποίησης και εξάρτησης των δραστηριοτήτων και ανταλλαγής των μηνυμάτων εισόδου και εξόδου. Για την εκτέλεση τους χρησιμοποιούνται μηχανές BPEL (BPEL engines). Η χρησιμότητα τους είναι προφανής και έγκειται στο γεγονός ότι αποτελούν την άμεση απάντηση στο πρόβλημα της αυτοματοποίησης των επιχειρηματικών διαδικασιών μέσα από προγραμματιστικές μεθόδους λογισμικού με απλό και ευθύ προσανατολισμό. Οι εκτελέσιμες διαδικασίες συμπληρώνουν το χάσμα μεταξύ της προδιαγραφής της διαδικασίας και του προγραμματιστικού κώδικα που είναι υπεύθυνος για την εκτέλεση τους. Κατά τον καθορισμό των εκτελέσιμων επιχειρηματικών διαδικασιών, ουσιαστικά καθορίζουμε μια καινούργια διαδικτυακή Υπηρεσία που αποτελεί σύνθεση υπαρχουσών Υπηρεσιών. Η διεπαφή (interface) της νέας διαδικτυακής Υπηρεσίας χρησιμοποιεί ένα σύνολο από θύρες (ports) μέσω των οποίων παρέχει τις λειτουργίες της στις υπόλοιπες Διαδικτυακές Υπηρεσίες. Όσον αφορά τις αφαιρετικές επιχειρηματικές διαδικασίες, έχει αναφερθεί ήδη ότι δεν είναι εκτελέσιμες, οπότε περιορίζονται σε απλή καταγραφή και προδιαγραφή των μηνυμάτων που ανταλλάσσονται μεταξύ των συμμετεχόντων μελών. Τα μηνύματα περιγράφουν τη συμπεριφορά του μέλους που συμμετέχει και είναι τα μόνα παρατηρήσιμα στοιχεία της Υπηρεσίας. Επομένως, γίνεται φανερό ότι οι αφαιρετικές επιχειρηματικές διαδικασίες δεν εμφανίζουν ιδιαίτερη χρησιμότητα. Παρόλα αυτά καθορίζονται για τρεις λόγους : Για να περιγράψουν τη συμπεριφορά μιας Υπηρεσίας χωρίς να είναι γνωστό με ακρίβεια το σύνολο των επιχειρηματικών διαδικασιών στις οποίες συμμετάσχει. Για να καθοριστούν τα πρωτόκολλα συνεργασίας μεταξύ των πολλαπλών παραγόντων που συμμετέχουν και να περιγραφεί με ακρίβεια η εξωτερική συμπεριφορά του κάθε συμμετέχοντα. Για να αποτελέσουν τα πρότυπα με βάση τα οποία είναι δυνατόν να σχεδιαστούν οι εκτελέσιμες επιχειρηματικές διαδικασίες.

58 3.4 Πρωτόκολλο SOAP Στα τέλη της δεκαετίας του 90, και συγκεκριμένα το 1997, μεγάλες εταιρείες, όπως η Microsoft, άρχισαν να διερευνούν κατά πόσο ο κατανεμημένος υπολογισμός μπορεί να βασιστεί στη γλώσσα XML. Ο σκοπός της έρευνας αυτής ήταν να γίνει εφικτή η επικοινωνία μεταξύ των εφαρμογών μέσω απομακρυσμένων κλήσεων διαδικασιών (Remote Procedure Calls RPCs), χρησιμοποιώντας απλά πρωτόκολλα δικτύου, όπως το HTTP[66]. Το 1999 έκανε την εμφάνισή του το SOAP, ένας RPC [31] μηχανισμός βασισμένος σε XML. Το 2000 ο οργανισμός W3C ασχολείται με την ιδέα αυτή και ύστερα από αρκετές αλλαγές, βελτιώσεις και τροποποιήσεις 2 ολόκληρων χρόνων, το 2003 δηλαδή, το SOAP με την έκδοση 1.2 γίνεται η προτεινόμενη προδιαγραφή πρωτόκολλο για τις υπηρεσίες διαδικτύου. Στον πυρήνα του, το SOAP, είναι μια προδιαγραφή για ένα απλό αλλά ταυτόχρονα ευέλικτο XML πρωτόκολλο δεύτερης γενιάς. Το σημαντικό είναι ότι καθώς η έρευνα ξεκίνησε από τον κατανεμημένο υπολογισμό, το SOAP είναι το πλέον κατάλληλο πρωτόκολλο αφού ειδικεύεται σε τέτοια περιβάλλοντα. Το SOAP παρέχει τα κάτωθι χαρακτηριστικά και μηχανισμούς: Μηχανισμός για τον ορισμό της πληροφορίας στην επικοινωνία Στο SOAP, όλη η πληροφορία είναι καταχωρημένη σε ένα ξεκάθαρο και ταυτοποιήσιμο SOAP μήνυμα (SOAP message). Αυτό γίνεται μέσω ενός SOAP φακέλου (SOAP envelope), που περικλείει όλες τις απαραίτητες πληροφορίες. Ένα μήνυμα SOAP, μπορεί να έχει σώμα (body), το οποίο περιέχει πληροφορία σε XML δομή. Επίσης, μπορεί να διαθέτει έναν αριθμό από επικεφαλίδες (headers), οι οποίες ενσωματώνουν επιπλέον πληροφορίες έξω από το σώμα του μηνύματος. Διεργασιακό μοντέλο Αυτό το μοντέλο ορίζει ένα σύνολο κανόνων βάσει των οποίων γίνονται οι διαπραγματεύσεις μεταξύ των SOAP μηνυμάτων και του λογισμικού. Διακρίνεται από την απλότητά του. Μηχανισμός για αντιμετώπιση σφαλμάτων Το SOAP παρέχει το μηχανισμό αυτό με τη μορφή των SOAP faults, τα οποία όταν χρησιμοποιούνται μπορεί να προσδιοριστεί η πηγή που προκάλεσε το σφάλμα. Επιπλέον, παρέχουν τη δυνατότητα ανταλλαγής διαγνωστικών πληροφοριών μεταξύ των μελών της επικοινωνίας. Μοντέλο επεκτασιμότητας Το μοντέλο αυτό χρησιμοποιεί SOAP επικεφαλίδες για την υλοποίηση προεκτάσεων πάνω στο SOAP. Οι επικεφαλίδες περιέχουν κομμάτια από δεδομένα με δυνατότητα επέκτασης, τα οποία ταξιδεύουν μαζί με το μήνυμα και μπορούν να γίνουν στόχος για επέκταση σε συγκεκριμένους κόμβους του δικτύου. Ευέλικτος μηχανισμός για αναπαράσταση δεδομένων Ο μηχανισμός αυτός επιτρέπει στα δεδομένα σε οποιαδήποτε σειριακή μορφή κι αν βρίσκονται να αναπαρασταθούν σε XML μορφή. Σύμβαση για αναπαράσταση των RPCs και των απαντήσεών τους σαν SOAP μηνύματα Οι απομακρυσμένες κλήσεις διαδικασιών είναι αρκετά διαδεδομένες στον κατανεμημένο προγραμματισμό/ υπολογισμό και μπορούν να αναπαρασταθούν καλά μέσω του μηχανισμού αυτού σαν SOAP μηνύματα. Πρωτόκολλο εγκαθίδρυσης σύνδεσης Το πρωτόκολλο αυτό ορίζει μια αρχιτεκτονική για την οικοδόμηση συνδέσεων επικοινωνίας ώστε να είναι εφικτή η ανταλλαγή SOAP μηνυμάτων πάνω σε μέσα μεταφοράς και επικοινωνιακά κανάλια. Χρησιμοποιείται το HTTP πρωτόκολλο, καθώς είναι το πιο διαδεδομένο και ευρέως χρησιμοποιούμενο στο διαδίκτυο.

59 Όσον αφορά στα μηνύματα SOAP, εφόσον το πρωτόκολλο είναι βασισμένο στην XML, είναι αναμενόμενο τα μηνύματα να έχουν μια τέτοια μορφή και ουσιαστικά να μην είναι τίποτε άλλο, παρά XML έγγραφα. Το στοιχείο-ρίζα του μηνύματος είναι το soapenv:envelope, το οποίο περικλείει το στοιχείο soapenv:body, που περιέχει πληροφορία σχετιζόμενη με το σκοπό του μηνύματος. Το στοιχείο soapenv:body με τη σειρά του μπορεί να περιέχει άλλα στοιχεία, τα οποία να σχετίζονται ή να αναπαριστούν την απομακρυσμένη κλήση διαδικασίας που πρόκειται να εκτελεστεί. Το όνομα της μεθόδου που θα κληθεί και το όνομα του στοιχείου αυτού περιέχονται μέσα στο σώμα του μηνύματος. Τα μηνύματα αυτά στέλνονται μέσω πρωτοκόλλου HTTP [33].με τη μέθοδο POST. Η απάντηση σε ένα τέτοιο μήνυμα, που και πάλι μεταφέρεται μέσω HTTP είναι και αυτή ένα SOAP μήνυμα. Το μήνυμα της απάντησης περικλείεται κι αυτό από το συστατικό soapenv:envelope, που περιέχει το soapenv:body, το οποίο ενσωματώνει και τη βασική πληροφορία του μηνύματος, στην οποία συγκαταλέγεται και μια κωδικοποιημένη αναπαράσταση του αποτελέσματος της απομακρυσμένης κλήσης που πραγματοποιήθηκε. Το SOAP παρέχει, όπως ήδη αναφέρθηκε, τη δυνατότητα σε ένα μήνυμα να συμπεριλαμβάνονται στοιχεία επικεφαλίδες. Ο ρόλος τους είναι και ο σημαντικότερος λόγος που χρησιμοποιούμε τα μηνύματα SOAP και όχι απλά XML έγγραφα. Τα στοιχεία αυτά (headers) έχουν την ιδιότητα να αναπαριστούν ένα επιπρόσθετο και επεκτάσιμο είδος πληροφορίας το οποίο μεταφέρεται μαζί με το υπόλοιπο μήνυμα, χωρίς να τροποποιείται ο κυρίως πυρήνας του μηνύματος. Για να γίνει κατανοητό αυτό ας δούμε ένα παράδειγμα της αληθινής ζωής ακριβώς αντίστοιχο με την ιδέα των SOAP μηνυμάτων. Ας υποθέσουμε ότι θέλουμε να στείλουμε ένα έγγραφο αλλά και κάποιες επιπρόσθετες πληροφορίες χωρίς όμως να θέλουμε να μαρκάρουμε το έγγραφο με αυτές. Τοποθετούμε, λοιπόν, το έγγραφο στο φάκελο και στη συνέχεια προσθέτουμε μία ή δύο σελίδες χαρτί, οι οποίες περιγράφουν την επιπλέον πληροφορία που θέλαμε να στείλουμε. Η αντιστοιχία του παραδείγματος αυτού με το πρωτόκολλο που περιγράφουμε είναι ότι ο φάκελος είναι το στοιχείο soapenv:envelope, το έγγραφο που θέλουμε να στείλουμε είναι το στοιχείο soapenv:body και οι σελίδες με την επιπλέον πληροφορία είναι τα στοιχεία επικεφαλίδες (headers). Η χρήση των επικεφαλίδων για την προσθήκη λειτουργικότητας σε ένα μήνυμα SOAP είναι γνωστή και σαν κατακόρυφη επέκταση, γιατί τα στοιχεία αυτά τοποθετούνται στην κορυφή του μηνύματος πριν το σώμα του. Για λόγους ασφάλειας σε περιπτώσεις επεκτασιμότητας χρησιμοποιώντας στοιχεία επικεφαλίδες, η προδιαγραφή του SOAP ορίζει τη μεταβλητή mustunderstand. Όταν η τιμή της είναι αληθής, τότε ο παραλήπτης του μηνύματος πρέπει να συμφωνήσει ότι αποδέχεται όλους τους όρους της επικεφαλίδας του μηνύματος προκειμένου να συνεχιστεί η επεξεργασία του. Στην περίπτωση που η τιμή της μεταβλητής αυτή είναι ψευδής, τότε η επικεφαλίδα έχει προαιρετικό ρόλο και η επεξεργασία του μηνύματος μπορεί να γίνει και από παραλήπτες που αγνοούν τις προδιαγραφές που θέτει η επικεφαλίδα.

60 Αντίστοιχα με την κατακόρυφη επεκτασιμότητα, υπάρχει και η οριζόντια, η οποία έχει να κάνει με την αντιστοίχηση διαφορετικών κομματιών του μηνύματος με διαφορετικούς παραλήπτες. Αυτό επιτυγχάνεται μέσω των μεσολαβητών SOAP (SOAP intermediaries). Αυτές οι εφαρμογές μπορούν να επεξεργάζονται μέρη του μηνύματος SOAP καθώς αυτό ταξιδεύει προς τον τελικό του προορισμό. Οι μεσολαβητές μπορούν να αποδέχονται και να προωθούν μηνύματα καθώς κάνουν και κάποιο είδος επεξεργασίας. Σε γενικές γραμμές, στον αληθινό κόσμο σπάνια ξεκινά ένα μήνυμα από κάποια τοποθεσία και φθάνει απευθείας στον προορισμό του. Για παράδειγμα ας πάρουμε το ηλεκτρονικό ταχυδρομείο. Όταν στέλνουμε ένα μήνυμα αυτό θα περάσει από διάφορους εξυπηρέτες και δρομολογητές προτού «εντοπίσει» τον προορισμό του. Αυτός είναι ένας από τους κυριότερους λόγους που χρειάζονται οι μεσολαβητές στα μηνύματα SOAP, καθώς επίσης χάρη σε αυτούς μπορούμε να έχουμε υπηρεσίες προστιθέμενης αξίας σε κατανεμημένα συστήματα. Έχοντας περιγράψει αρκετά το SOAP, φτάνουμε στα εξής βήματα που τελικά πρέπει να πραγματοποιηθούν από έναν παραλήπτη ή ένα μεσολαβητή κάποιου μηνύματος SOAP: Πρέπει να κατανοηθεί το σύνολο των κανόνων που περιέχει το μήνυμα που παραλείφθηκε. Τα στοιχεία επικεφαλίδες κυρίως μπορεί να περιέχουν τέτοιο πληροφορία. Πρέπει να προσδιοριστούν όλα τα σύνολα που ορίζουν τα στοιχεία επικεφαλίδες με προσοχή. Αν κάποιο σημείο δεν είναι κατανοητό και αυτό έχει να κάνει με τη μεταβλητή mustunderstand τότε πρέπει να συνταχθεί ένα μήνυμα λάθους (SOAP fault). Σε τέτοιο περίπτωση η περαιτέρω επεξεργασία του μηνύματος πρέπει να σταματήσει. Λάθη που έχουν να κάνουν με το σώμα του μηνύματος δεν εντοπίζονται σε αυτό το βήμα. Ακολουθεί επεξεργασία των επικεφαλίδων. Σε περίπτωση που το μήνυμα βρίσκεται στον τελικό παραλήπτη και όχι σε κάποιον ενδιάμεσο, τότε γίνεται και η επεξεργασία του σώματος του μηνύματος. Στην περίπτωση που το μήνυμα βρίσκεται σε κάποιον ενδιάμεσο μεσολαβητή και δεν υπάρχει κάποιο πρόβλημα με την έννοια ότι δεν υπήρξε ανάγκη να συνταχθεί κάποιο μήνυμα λάθους τότε η πορεία του μηνύματος συνεχίζεται με την προώθησή του στον επόμενο κόμβο, όπου ακολουθείται η ίδια διαδικασία. Ουσιαστικά οι μεταβλητή mustunderstand έχει σα ρόλο να μας δίνει την ευκαιρία να ορίζουμε τι ακριβώς διαδικασίες θα γίνονται σε κάθε κόμβο από τον οποίο περνάει το μήνυμα μέχρι να φτάσει στον τελικό του προορισμό. Όσον αφορά στα μηνύματα λάθους, αυτά είναι απλά μηνύματα SOAP, τα οποία περιέχουν ένα απλό στοιχείο μέσα στο soapenv:body, το soapenv:fault. Η παρουσία αυτού του στοιχείου σηματοδοτεί ότι κάπου υπήρξε κάποιο λάθος. Το μήνυμα λάθους έχει κάποια συγκεκριμένη και καλά ορισμένη δομή ώστε να παρέχει πληροφορία σχετική με το λάθος που συνέβη. Το στοιχείο env:code περιέχει όλη την απαραίτητη κωδικοποιημένη πληροφορία για το σκοπό αυτό. Από τις πληροφορίες αυτές μπορούμε να διαπιστώσουμε εάν το λάθος προέκυψε λόγω λανθασμένης ή ελλιπούς πληροφορίας από τον αποστολέα, ή λόγω κάποιου λάθους που συνέβη κατά την επεξεργασία του από κάποιον παραλήπτη. Επίσης το λάθος μπορεί να σχετίζεται με την σχέση κάποιου μεσολαβητή με την τιμή της μεταβλητής mustunderstand. Τέλος,

61 ο λόγος προελεύσεώς του μπορεί να είναι οι μη συμβατές εκδόσεις του πρωτοκόλλου που χρησιμοποιούνταν από κόμβο σε κόμβο. Τα μηνύματα λάθους, ως κανονικά SOAP μηνύματα που είναι, μπορούν να επεκτείνονται με την παρουσία στοιχείων επικεφαλίδων, τα οποία μπορεί να περιέχουν επιπλέον πληροφορία για την ανίχνευση του λάθους και να συμβάλλουν στη συντήρηση των υπηρεσιών πάνω στο δίκτυο. Ένα εργαλείο για την πραγματοποίηση SOAP συναλλαγών είναι ο Apache Axis [32], μια μηχανή SOAP ανοιχτού λογισμικού. 3.5 Γλώσσα Περιγραφής Υπηρεσιών Διαδικτύου WSDL Μέχρι εδώ έχουμε μιλήσει για το SOAP. Έχουμε εξηγήσει ότι είναι βασισμένο στην XML και ότι μέσω αυτού του πρωτοκόλλου μπορούν να γίνουν αιτήσεις για απομακρυσμένες κλήσεις διαδικασιών από κάποιον πελάτη σε κάποιον εξυπηρέτη. Από τη μεριά του πελάτη όμως υπάρχουν δυσκολίες στη σύνταξη του μηνύματος SOAP, καθώς ο πελάτης δε μπορεί να ξέρει τι ακριβώς μήνυμα να στείλει. Το SOAP καθορίζει κάποιους κανόνες και προσφέρει μια συγκεκριμένη φόρμα για τα μηνύματα, αλλά πρέπει να βρεθεί κάποιος άλλος τρόπος ώστε ο πελάτης να είναι σε θέση να γνωρίζει τι μήνυμα να στείλει στον εξυπηρέτη του παροχέα της υπηρεσίας. Επίσης, ο πελάτης πρέπει να γνωρίζει αρκετές λεπτομέρειες προτού στείλει το μήνυμα. Πρέπει να γνωρίζει καταρχάς που ακριβώς να το στείλει, ή ποιες μεθόδους θέλει να καλέσει από την υπηρεσία, ή ποια πρωτόκολλα επικοινωνίας υποστηρίζονται από τον παροχέα της υπηρεσίας. Προκειμένου να γνωρίζει ο πελάτης όλες τις απαραίτητες πληροφορίες για την κλήση μιας υπηρεσίας διαδικτύου, πρέπει να έχει στην κατοχή του μια περιγραφή αυτής. Για να γίνει η όλη διαδικασία ακόμη πιο εύκολη και πιο τυποποιημένη χρειάζεται ένας καθορισμένος μηχανισμός για την περιγραφή των υπηρεσιών διαδικτύου. Αυτός ο μηχανισμός θα παρέχει πληροφορίες για ακριβώς αυτά που χρειάζεται να ξέρει ο χρήστης που θέλει να καλέσει την υπηρεσία. Επιπρόσθετα, χάρη σε αυτόν το μηχανισμό είναι δυνατή η ανάπτυξη εφαρμογών που θα βοηθούν τους προγραμματιστές στην ανάπτυξη των υπηρεσιών μέσω των περιγραφών τους. Όπως έχει αναφερθεί και σε προηγούμενη ενότητα, ο ρόλος της υπηρεσίας καταλόγου (Service Registry) σε μια SOA αρχιτεκτονική είναι πολύ σημαντικός. Ο πελάτης, προκειμένου να ανακαλύψει την υπηρεσία που τον ενδιαφέρει, ψάχνει πρώτα στον κατάλογο αυτό. Το αποτέλεσμα της αναζήτησης δεν είναι τίποτε άλλο από την περιγραφή της υπηρεσίας που ζήτησε. Ο παροχέας της υπηρεσίας διαδικτύου, λοιπόν, δημοσιεύει την περιγραφή της υπηρεσίας του γι αυτό το λόγο. Για να ξέρει ο κάθε πιθανός πελάτης πώς να εγκαθιδρύσει επικοινωνιακή σύνδεση μαζί του και πως ακριβώς να καλέσει την υπηρεσία που του παρέχει. Μια καλή περιγραφή μιας υπηρεσίας διαδικτύου πρέπει να αποτελείται από δύο μέρη: Τη λειτουργική περιγραφή Η περιγραφή αυτή περιγράφει ποιες ακριβώς λειτουργίες είναι διαθέσιμες από την υπηρεσία διαδικτύου και ποια είναι η απαιτούμενη σύνταξη που θα πρέπει να έχει το SOAP μήνυμα προκειμένου να γίνει με επιτυχία η κλήση. Επίσης, πληροφορίες σχετικές με την τοποθεσία της υπηρεσίας είναι διαθέσιμες ώστε ο χρήστης να έχει το ακριβές URL στο οποίο θα γίνει η κλήση. Είναι χρέος της περιγραφής αυτής να δώσει όλες τις απαραίτητες πληροφορίες στον πελάτη ώστε να καλέσει την υπηρεσία.

62 Τη μη-λειτουργική περιγραφή Η λειτουργική περιγραφή είναι πολύ σημαντική, αφού χωρίς αυτή δεν είναι δυνατόν να επιτευχθεί η κλήση της υπηρεσίας. Η μη-λειτουργική περιγραφή όμως είναι εξίσου σημαντική. Όπως υποδηλώνει και το όνομά της, προσφέρει πληροφορίες που σχετίζονται με μη λειτουργικές απαιτήσεις της υπηρεσίας. Τέτοιες πληροφορίες μπορεί να περιγράφουν το λόγο που κάποιος πελάτης να επιθυμεί να καλέσει την υπηρεσία. Επίσης, μπορεί να περιγράφουν τον παροχέα της υπηρεσίας με αρκετή λεπτομέρεια. Μπορεί να προσφέρουν προσωπικά του στοιχεία και τηλέφωνα επικοινωνίας. Τέλος, πληροφορίες για την ασφάλεια γύρω από την υπηρεσία και την πολιτική του παροχέα μπορεί να είναι διαθέσιμες μέσω της μη λειτουργικής περιγραφής της υπηρεσίας. Η ευρέως χρησιμοποιούμενη και καθιερωμένη γλώσσα περιγραφής υπηρεσιών διαδικτύου είναι η WSDL (Web Services Description Language). Είναι μια γλώσσα βασισμένη στην XML και περιγράφει τρεις σημαντικές ιδιότητες της υπηρεσίας: Τι κάνει η υπηρεσία Εδώ περιγράφονται οι μέθοδοι της υπηρεσίας, οι παράμετροί της και τα αποτελέσματα που επιστρέφει. Πώς γίνεται η πρόσβαση στην υπηρεσία Εδώ παρέχονται όλες οι απαραίτητες πληροφορίες για τη σύνταξη των SOAP μηνυμάτων που θα ανταλλαγούν, καθώς και τα πρωτόκολλα που υποστηρίζονται από τον παροχέα. Που βρίσκεται η υπηρεσία Εδώ παρέχονται πληροφορίες για τη δικτυακή διεύθυνση της υπηρεσίας. Συνήθως είναι ένα URL. Όπως κάθε καλά ορισμένη γλώσσα βασισμένη σε XML, έτσι και η WSDL ορίζει κάποια βασικά στοιχεία που συναντώνται σε ένα WSDL έγγραφο. Τα κυριότερα από αυτά είναι: porttype Είναι ένας αφαιρετικός ορισμός της διασύνδεσης της υπηρεσίας διαδικτύου. Ουσιαστικά, σκοπός του είναι η περιγραφή αυτής της διασύνδεσης. Όπως γίνεται σε έναν κώδικα Java, που η διασύνδεση αποτελείται μόνο από τις υπογραφές των μεθόδων, έτσι κι εδώ ο ορισμός του porttype είναι η συλλογή των λειτουργιών που παρέχει η υπηρεσία διαδικτύου. Ένα τέτοιο στοιχείο μπορεί να έχει ένα απλό όνομα, το οποίο πιθανόν να σχετίζεται με τη λειτουργία που προσφέρει η υπηρεσία. Εάν ένα έγγραφο WSDL περιέχει πολλά τέτοια στοιχεία, τότε το κάθε ένα οφείλει να έχει διαφορετικό όνομα. Message Καθορίζει τη μορφή του μηνύματος, καθώς και το σύνολο των παραμέτρων που σχετίζονται με τις μεθόδους της υπηρεσίας. Το στοιχείο αυτό μπορεί να αποσυντεθεί σε πολλά μέρη, που ονομάζονται parts. Κάθε στοιχείο message μέσα σε ένα WSDL έγγραφο πρέπει να έχει ένα μοναδικό όνομα ώστε να ξεχωρίζει από τα υπόλοιπα. Ουσιαστικά, τα στοιχεία αυτά δεν παρουσιάζουν ιδιαίτερο ενδιαφέρον αφού δεν είναι τίποτε άλλο από μια συλλογή από parts και κάθε part έχει ένα όνομα, που συνήθως αντικατοπτρίζει την πληροφορία που περιέχεται στο part. Types Ορίζει τη συλλογή όλων των τύπων δεδομένων που χρησιμοποιούνται από την υπηρεσία διαδικτύου. Το εξ ορισμού σύστημα των τύπων δεδομένων στην WSDL είναι το XML σχήμα (XML Schema XSD). Το σχήμα αυτό μπορεί να χρησιμοποιηθεί για να περιγράψει όλους τους τύπους δεδομένων που μπορεί να χρησιμοποιηθούν στα διάφορα μηνύματα που ανταλλάσσονται για την κλήση της υπηρεσίας. Το στοιχείο types είναι ένα μέρος για το WSDL έγγραφο στο οποίο ο χρήστης ορίζει τύπους δεδομένων που θα χρησιμοποιηθούν σε άλλα στοιχεία του εγγράφου.

63 Binding Περιέχει λεπτομέρειες για το πώς τα στοιχεία σε μια αφαιρετική δομή (όπως το porttype) μπορούν να μετασχηματισθούν σε μια συμπαγή αναπαράσταση των δεδομένων και πρωτοκόλλων που θα χρησιμοποιηθούν για την επικοινωνία μεταξύ του πελάτη και της υπηρεσίας. Ουσιαστικά είναι το στοιχείο που θα πει στον πελάτη πώς ακριβώς να μορφοποιήσει το μήνυμα που θα στείλει για την κλήση της υπηρεσίας. Κάθε στοιχείο porttype μπορεί να έχει ένα ή περισσότερα στοιχεία binding συσχετισμένα με αυτό. Για ένα συγκεκριμένο στοιχείο porttype, ένα στοιχείο binding περιγράφει τον τρόπο που πρέπει να γίνει η κλήση των μεθόδων της υπηρεσίας χρησιμοποιώντας κάποιο καθορισμένο πρωτόκολλο, όπως το SOAP, πάνω σε κάποιο επίσης καθορισμένο πρωτόκολλο μεταφοράς, όπως το HTTP. Το όνομα του binding πρέπει να είναι μοναδικό καθώς πολλά τέτοια στοιχεία μπορεί να υπάρχουν σε ένα WSDL έγγραφο. Port Περιγράφει πως ακριβώς εκφράζεται ένα binding σε μια φυσική θύρα του δικτύου. Ο ρόλος της είναι πολύ απλός αφού δεν κάνει τίποτε άλλο από μια απλή αντιστοιχία. Τα στοιχεία αυτά, όπως και τα προηγούμενα, οφείλουν να φέρουν ένα όνομα, μοναδικό μέσα στο WSDL έγγραφο. Συνήθως, τα στοιχεία αυτά υποδεικνύουν το URL στο οποίο πρέπει να σταλούν τα μηνύματα SOAP ώστε να γίνει η κλήση της υπηρεσίας. Τα στοιχεία αυτά δε συναντούνται μόνα τους μέσα στο έγγραφο της περιγραφής της υπηρεσίας. Είναι στοιχεία παιδιά του συστατικού service. Service Ένα τέτοιο στοιχείο είναι μια συλλογή από ports. Το στοιχείο αυτό μπορεί να έχει ένα μοναδικό όνομα μέσα στο έγγραφο. Παρόλο που ο ρόλος του δεν έχει ιδιαίτερη σημασία, είναι καλό τα στοιχεία port να ομαδοποιούνται κάτω από ένα στοιχείο service. Συνήθως όμως ένα μόνο στοιχείο port συναντάται και έτσι καταλήγουμε στο να έχουμε ένα στοιχείο service, που να περιέχει ένα στοιχείο port. Το σχήμα που ακολουθεί απεικονίζει τις συσχετίσεις μεταξύ των συστατικών της WSDL. Σχήμα 10 Το πληροφοριακό μοντέλο της WSDL

64 Η δομή ενός WSDL εγγράφου ξεκινά με ένα στοιχείο ορισμών, το οποίο καλείται definitions. Το στοιχείο αυτό περιέχει όλα τα υπόλοιπα στοιχεία που μπορεί να συναντηθούν μέσα στο έγγραφο, δηλαδή μπορεί να περιέχει: Κανένα ή οσαδήποτε στοιχεία τεκμηρίωσης. Τα στοιχεία αυτά καλούνται documentation elements και χρησιμοποιούνται για να παρέχουν χρήσιμες πληροφορίες κατανοητές από τον άνθρωπο γύρω από την υπηρεσία διαδικτύου. Κανένα ή οσαδήποτε στοιχεία εισαγωγών. Τα στοιχεία αυτά καλούνται import elements. Τα στοιχεία δίνουν τη δυνατότητα επαναχρησιμοποίησης ήδη υπαρχόντων WSDL εγγράφων επιτρέποντας σε διάφορα στοιχεία να έχουν αναφορές σε άλλα ήδη υπάρχοντα που βρίσκονται σε διαφορετικό έγγραφο σε διαφορετικό αρχείο. Προαιρετικά ένα στοιχείο types. Κανένα ή οσαδήποτε στοιχεία message. Κανένα ή οσαδήποτε στοιχεία porttype. Συνήθως μόνο ένα συναντάται. Κανένα ή οσαδήποτε στοιχεία binding. Συνήθως μόνο ένα συναντάται, το οποίο έχει να κάνει με το στοιχείο porttype. Κανένα ή οσαδήποτε στοιχεία service. Και πάλι συνήθως μόνο ένα είναι αρκετό. Τέλος, η έκδοση που χρησιμοποιείται ευρέως είναι η 1.1 της WSDL. Σημαντικές βελτιώσεις αναμένονται στην έκδοση 2.0, στην οποία υπάρχει ο ισχυρισμός ότι θα υποστηρίζει κάποιου είδους σημασιολογικής πληροφορίας σε μικρό βαθμό. 3.6 Universal Description, Discovery and Integration (UDDI) Στις αρχές του 2000, και καθώς η ιδέα των υπηρεσιών ιστού άρχισε να κερδίζει έδαφος μέσα στην κοινότητα, έγινε σαφές ότι η καταχώρηση σε καταλόγους των υπηρεσιών ιστού ήταν κάτι απαραίτητο για να μπορέσει να εφαρμοστεί πρακτικά η ιδέα. Επιπλέον, λόγο της γενικότερης στροφής προς τα ανοικτά πρότυπα, οτιδήποτε εκτός από έναν πρότυπο μηχανισμό αλληλεπίδρασης και αναζήτησης δε θα μπορούσε να γίνει αποδεκτό. Ένα τέτοιο πρότυπο καταλόγου, θα έπρεπε να υποστηριχθεί και από τις περισσότερες, αν όχι από όλες τις μεγάλες εταιρίες παροχής λογισμικού, και να υιοθετηθεί από τις διάφορες βιομηχανίες. Έτσι η πρωτοβουλία του UDDI, που ήταν το αποτέλεσμα πολλών μηνών συνεργασίας μεταξύ αντιπροσώπων από τις Ariba, IBM, και Microsoft, που ξεκίνησε την άνοιξη του 2000, γεννήθηκε και ανακοινώθηκε επίσημα στις 6 Σεπτεμβρίου Η υποστήριξη για το UDDI επεκτάθηκε και πέρα από τις τρεις εταιρίες που συμμετείχαν αρχικά και αυτή τη στιγμή, το έργο UDDI περιλαμβάνει μια κοινότητα που αριθμεί πάνω από 310 εταιρίες. Ο σκοπός του UDDI είναι να διευκολύνει την ανακάλυψη υπηρεσιών και κατά το χρόνο σχεδίασης, και δυναμικά κατά το χρόνο εκτέλεσης. Συνεπώς το UDDI λειτουργεί ως ένα κοινό άμεσα συνδεδεμένο κατάλογο (και των αντιστοίχων υπηρεσιών), το οποίο λειτούργησε για πρώτη φορά στις 2 Μαΐου Ο κατάλογος αυτός, συνήθως αναφέρεται ως κατάλογος επιχειρήσεων UDDI (UDDI Business Registry). Ο κατάλογος αυτός, στην πραγματικότητα αποτελείται από 2 πανομοιότυπους καταλόγους, που διατηρούνται αυτή τη στιγμή από δύο εταιρίες (IBM και Microsoft), οι οποίοι και αποκαλούνται οι διαχειριστές του UDDI.

65 Για να γίνει κάποιος διαχειριστής ενός τέτοιου καταλόγου, πρέπει να ακολουθήσει αυστηρές συμφωνίες για την αντιγραφή των δεδομένων, το απόρρητο των δεδομένων και τις διάφορες πολιτικές. Από την οπτική μιας καταχωρημένης επιχείρησης αλλά και από την οπτική του απλού χρήστη, η απαίτηση είναι να μην υπάρχει διαφορά ανάμεσα στα διαφορετικά αντίγραφα του καταλόγου. Οι επιχειρήσεις μπορούν να κάνουν εγγραφή σε οποιονδήποτε διαχειριστή UDDI, και τα δεδομένα τους θα αντιγραφούν σε όλα τα άλλα αντίγραφα του καταλόγου στους άλλους διαχειριστές. Επομένως, οι χρήστες μπορούν να αναζητήσουν στον κατάλογο οποιουδήποτε διαχειριστή για να βρουν τις επιχειρήσεις που αναζητούν, άσχετα με το διαχειριστή που έχει επιλέξει η συγκεκριμένη επιχείρηση για να εγγραφεί. Υπάρχουν όμως κάποια λεπτά θέματα που έχουν σχέση με την απόφαση σχετικά με το ποιον διαχειριστή να χρησιμοποιήσει μια επιχείρηση για να εγγραφεί. Για παράδειγμα, κάποιοι διαχειριστές μπορεί να ζητούν επιπρόσθετες προαιρετικές πληροφορίες που δεν απαιτούνται από το UDDI. Αυτή η πληροφορία δεν αντιγράφεται στα αντίγραφα του καταλόγου στους άλλους διαχειριστές. Επιπλέον, αυτό που πρέπει να σημειωθεί είναι ότι από τη στιγμή που μια επιχείρηση επιλέξει κάποιο διαχειριστή για να εγγραφεί, η οποιαδήποτε ενημέρωση και τροποποίηση των στοιχείων θα πρέπει να γίνει από τον ίδιο διαχειριστή. Αυτό πρέπει να γίνεται έτσι δεδομένου ότι ο κάθε διαχειριστής ακολουθεί διαφορετικές πολιτικές πιστοποίησης και ασφάλειας, και επομένως η πληροφορία πιστοποίησης δεν είναι εύκολο να αντιγραφεί στους άλλους διαχειριστές. Το UDDI είναι κάτι παραπάνω από ένα κατάλογο επιχειρήσεων και υπηρεσιών. Ορίζει ένα σύνολο από δομές δεδομένων και προδιαγραφές ΑΡΙ, για την προγραμματική αναζήτηση και καταχώρηση εταιριών, υπηρεσιών, δεσμών, και ειδών υπηρεσιών. Στα τυπικά σενάρια υπηρεσιών διαδικτύου, οι παροχείς υπηρεσιών διαδικτύου θα θελήσουν να δημοσιεύσουν τις περιγραφές των εταιριών και των υπηρεσιών τους σε ένα κατάλογο, και όσοι αναζητούν υπηρεσίες, είτε κατά τη σχεδίαση, είτε κατά την εκτέλεση, θα θελήσουν να αναζητήσουν στον κατάλογο περιγραφές υπηρεσιών. Οι προδιαγραφές ΑΡΙ του UDDI παρέχουν γι αυτό το λόγο ένα σύνολο από προγραμματιστικές διεπαφές (ΑΡΙ) δημοσίευσης για την καταχώρηση υπηρεσιών, και αντίστοιχες διεπαφές ερωτήσεων ΑΡΙ για την εύρεση υπηρεσιών. Επιπλέον από την παροχή μιας προγραμματιστικής διεπαφής, οι διαχειριστές του καταλόγου UDDI, παρέχουν ένα σύστημα αλληλεπίδρασης με το χρήστη, βασισμένο στο διαδίκτυο, για την καταχώρηση, διαχείριση, ανεύρεση εταιριών και υπηρεσιών μέσα στον κατάλογο Το μοντέλο χρήσης του UDDI Σε αυτήν την ενότητα θα εξεταστούν αρχικά οι τυπικές απαιτήσεις για ένα κατάλογο μεταδεδομένων, ορίζοντας κάποια τυπικά στοιχεία δεδομένων και κάποιες λειτουργίες. Τέλος, θα γίνει μια γενική περιγραφή των δομών δεδομένων και των ΑΡΙ του UDDI, συσχετίζοντάς τα με τις αρχικές απαιτήσεις.

66 Οι απαιτήσεις του καταλόγου UDDI Οι κατάλογοι γενικά, είτε είναι φτιαγμένα για στοιχεία λογισμικού, για υπηρεσίες, είτε για κάποιο άλλο σκοπό, έχουν κάποιες βασικές απαιτήσεις: Ένα σύνολο από προδιαγραφές δομών δεδομένων για τα μεταδεδομένα που θα αποθηκευθούν στον κατάλογο. Ένα σύνολο από προδιαγραφές λειτουργιών Δημιουργίας, Ανάγνωσης, Ενημέρωσης, Διαγραφής (CRUD Create, Read, Update, Delete) για την αποθήκευση, διαγραφή, και ερώτηση των δεδομένων του καταλόγου. Οι συνήθεις απαιτήσεις για τα μεταδεδομένα είναι: Ιδιοκτησία και περιεχόμενο, δηλαδή ότι κάποιος πρέπει να είναι ο ιδιοκτήτης των δεδομένων που δημοσιεύει, καθώς και όλων των δεδομένων που περιέχονται σε αυτά, εκτός εάν δηλωθεί διαφορετικά. Κατηγοριοποίηση, δηλαδή τα δεδομένα μπορούν να είναι ταξινομημένα σε μια ή περισσότερες κατηγορίες, για να διευκολύνουν την οργάνωση και την αναζήτηση. Οι συνήθεις απαιτήσεις για τις λειτουργίες του καταλόγου είναι: Η πιστοποίηση για διαδικασίες που αλλάζουν δεδομένα και για δημόσιους καταλόγους. Η ελεύθερη πρόσβαση για λειτουργίες ερώτησης και ανάγνωσης. Το τμήμα του καταλόγου UDDI, διαθέτει ένα μοντέλο πληροφορίας που αντιπροσωπεύει τις προδιαγραφές των δομών δεδομένων, και μια προγραμματιστική διεπαφή για τις προδιαγραφές των λειτουργιών. Το μοντέλο πληροφοριών του UDDI σχεδιάστηκε με τέτοιο τρόπο ώστε να είναι ευέλικτο και επεκτάσιμο, επιτρέποντας έτσι και τη χρήση οποιουδήποτε μοντέλου περιγραφής υπηρεσιών που θα επιθυμούσε να ορίσει κάποιος χρήστης. Επειδή οι προδιαγραφές του UDDI είναι μια διαδικασία συνεχούς βελτίωσης και επέκτασης, στη συνέχεια θα περιγραφούν οι προδιαγραφές της έκδοσης 1.0 του UDDI. Οι μελλοντικές εκδόσεις το μόνο που θα κάνουν είναι να προσθέσουν περαιτέρω λειτουργικότητες πάνω στην τρέχουσα έκδοση, και να αντιμετωπίσουν προβλήματα που ανακύπτουν σε θέματα αντιγραφής, εκδόσεων και ασφάλειας Οι δομές δεδομένων του UDDΙ Γενική περιγραφή Οι προδιαγραφές της έκδοσης 1.0 του UDDI, επιτρέπουν σε οντότητες όπως εταιρίες και οργανισμοί να καταχωρούν δημόσια πληροφορία για αυτούς και πληροφορίες για τις υπηρεσίες που παρέχουν. Επιπλέον επιτρέπει σε οντότητες όπως επιχειρήσεις, ομάδες προτύπων, και ομάδες βιομηχανιών, να καταχωρούν πληροφορίες για τα είδη υπηρεσιών που έχουν ορίσει, περιγραφές προτύπων και εννοιών, και να αναφέρονται σε αυτά με αναγνωριστικά ονόματα που τους έχουν ορίσει. Κατά συνέπεια, το UDDI φαίνεται σαν να προσφέρει δυο διαφορετικούς καταλόγους: έναν επαγγελματικό, και ένα κατάλογο τύπου αναφοράς. Σε απόλυτη αντιστοιχία, το UDDI έχει στον πυρήνα του δυο βασικές ριζικές δομές δεδομένων, τις businessentity και tmodel.

67 Σχήμα 11 Μοντέλο πληροφορίας του UDDI Η δομή δεδομένων businessentity Η πληροφορία της οντότητας της επιχείρησης διαχωρίζεται θεμελιωδώς σε μέρη που είναι γνωστά με τους όρους Λευκές, Κίτρινες, και Πράσινες σελίδες: Οι Λευκές σελίδες περιέχουν γενικές πληροφορίες επικοινωνίας με την οντότητα. Οι Κίτρινες σελίδες περιέχουν πληροφορίες ταξινόμησης για τους τύπους και την τοποθεσία των υπηρεσιών που προσφέρει η οντότητα. ΟΙ Πράσινες σελίδες περιέχουν πληροφορίες για τις τον τρόπο με τον οποίο μπορεί κάποιος να έχει πρόσβαση στις υπηρεσίες που προσφέρονται. Είναι απαραίτητο να σημειωθεί ότι αυτό είναι απλά ένα θεμελιώδες μοντέλο, και πως το UDDI δεν καθορίζει κάποιο συγκεκριμένο μοντέλο αποθήκευσης. Μια καταχώρηση μιας οντότητας στις λευκές σελίδες θα περιέχει και πληροφορίες ταξινόμησης, που θα δείχνουν τη θέση της οντότητας αυτής στις κίτρινες σελίδες, και επίσης, μια καταχώρηση μιας υπηρεσίας κάποιας οντότητας θα περιέχει πληροφορίες υλοποίησης που θα δείχνουν τη θέση της οντότητας αυτής μέσα στις πράσινες σελίδες. Αυτό αντανακλάται στις λεπτομέρειες της δομής businessentity. Το στοιχείο businessentity, πέρα από κάποιες πληροφορίες επικοινωνίας, αναγνώρισης και ταξινόμησης, περιέχει ένα businessservices στοιχείο, που είναι ένα πεδίο για στοιχεία τύπου businessservice. Ένα στοιχείο businessservice με τη σειρά του, περιέχει ένα στοιχείο bindingtemplates, το οποίο είναι ένα πεδίο για στοιχεία τύπου bindingtemplate. Τέλος, οι καταχωρήσεις bindingtemplate δείχνουν σε καταχωρήσεις tmodel. Οι συσχετίσεις που περιγράφονται παραπάνω, απεικονίζονται στο Error! Reference source not found..

68 Η δομή δεδομένων tmodel Η άλλη σημαντική δομή του μοντέλου πληροφορίας του UDDI, είναι το στοιχείο tmodel. Οι καταχωρήσεις στις πράσινες σελίδες, είναι στην ουσία εξειδικευμένες πληροφορίες κάθε επιχείρησης που συνδέουν πληροφορίες για τύπους υπηρεσιών και άλλες έννοιες που ορίζονται αλλού. Αυτές οι επαναχρησιμοποιήσιμες έννοιες αποκαλούνται μοντέλα τεχνολογίας, και η δομή δεδομένων του UDDI που αντιστοιχεί είναι το στοιχείο tmodel. Αυτό το στοιχείο δίνει τη δυνατότητα σε ομάδες βιομηχανιών, σε σώματα προτύπων αλλά και σε μεμονωμένες επιχειρήσεις να μπορούν να καθορίζουν επαναχρησιμοποιήσιμους εννοιολογικούς ορισμούς τύπων υπηρεσιών, οι οποίοι μπορούν να χρησιμοποιηθούν και να συνδυαστούν, σχηματίζοντας μια υπογραφή για μια υπηρεσία. Στο σχήμα αναγνώρισης του UDDI, σε κάθε στιγμιότυπο των τεσσάρων τύπων εγγραφών εκχωρείται ένα μοναδικό αναγνωριστικό από τον κόμβο του UDDI κατά την αρχική εγγραφή. Επιπρόσθετα, και ανάλογα με το σχήμα περιεχομένου του UDDI, κάθε στιγμιότυπο μιας περιεχόμενης δομής κρατάει μια αναφορά κλειδί προς την περιεχόμενη οντότητα, σε μια αυστηρή σχέση γονέα τέκνου. Αυτά τα αναγνωριστικά είναι UUIDs (Universal Unique IDentifiers), που ακολουθούν τις συμβάσεις του OSF για κατανεμημένο υπολογιστικό περιβάλλον (Distributed Computing Environment Error! Reference source not found.). Θεωρήθηκε πολύ σημαντικό για την επεκτασιμότητα του μοντέλου, οι ιδιωτικοί κατάλογοι UDDI να έχουν την ικανότητα να επεκτείνουν τη δομή businessentity, έτσι ώστε να μπορεί να διατηρεί δεδομένα που χρειάζονται για τους δικούς τους σκοπούς. Γι αυτήν την περίπτωση δημιουργήθηκε η οντότητα businessentityext. Οι διαχειριστές των καταλόγων UDDI πάντως δεν θα παρέχουν τέτοιες επεκτάσεις στα δεδομένα των επιχειρήσεων που διατηρούν στις δημόσια προσβάσιμες βάσεις τους Προγραμματιστική διεπαφή του UDDI Γενική περιγραφή Εκτός από τον ορισμό των δομών δεδομένων που θα αποθηκεύονται στον κατάλογο, οι προδιαγραφές του UDDI παρέχουν και δύο βασικούς τύπους προγραμματιστικών διεπαφών: την προγραμματιστική διεπαφή δημοσίευσης και την προγραμματιστική διεπαφή ερώτησης. Αυτές οι δύο διεπαφές ορίζουν ένα σύνολο από 20 μηνύματα SOAP για το πρωτόκολλο HTTP ή για το HTTPS, τα οποία πρέπει να είναι κατανοητά από οποιοδήποτε κατάλογο συμβατό με το UDDI πρότυπο. Το SOAP τμήμα του μηνύματος καθώς και οι απαντήσεις είναι δομές της XML που καθορίζονται στις προδιαγραφές του UDDI. Η προγραμματιστική διεπαφή δημοσίευσης ορίζει είναι ένα πιστοποιημένο σύνολο λειτουργιών που επιτρέπει στους οργανισμούς να δημοσιεύουν πληροφορία για εταιρίες, υπηρεσίες, υλοποιήσεις ή είδη υπηρεσιών στον κατάλογο UDDI. Το UDDI δεν καθορίζει κάποια μέθοδο πιστοποίησης, εκτός από την απαίτηση για ύπαρξη κουπονιού πιστοποίησης (authorization token), και τη χρήση του πρωτοκόλλου HTTPS κατά τις διαδικασίες πιστοποίησης. Έτσι ο κάθε διαχειριστής θα πρέπει να έχει το δικό του μηχανισμό πιστοποίησης. Η αντίστοιχη προγραμματιστική διεπαφή ερωτήσεων, αποτελείται από ένα σύνολο από λειτουργίες οι οποίες δεν απαιτούν πιστοποίηση και επιτρέπουν στους χρήστες να λαμβάνουν τις πληροφορίες που αναζητούν από τον κατάλογο UDDI. Τα ερωτήματα μπορούν να γίνονται με βάση δύο γενικά σχήματα: ένα σχήμα με τη χρήση επόπτη

69 διαδικτύου (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, busi-nessservice, bindingtemplate και tmodel) αντίστοιχα (Πίνακας 4). Operation Business Service Binding tmodel Save/Update save_business save_service save_binding save_tmodel Delete delete_business delete_service delete_binding delete_tmodel Find find_business find_service find_binding find_tmodel GetDetail get_businessdetail get_servicedet ail get_bindingdetai l get_tmodeldetai l Πίνακας 4 Μηνύματα των προγραμματιστικών διεπαφών που ορίζονται από τις προδιαγραφές του UDDI. Οι λειτουργίες αποθήκευσης μπορούν να χρησιμοποιηθούν για τη δημιουργία μιας καινούριας εγγραφής αλλά και για τη διόρθωση μιας υπάρχουσας. Κατά τη δημιουργία μιας καινούριας εγγραφής, η αναγνωριστική παράμετρος (κλειδί της εγγραφής) δεν καταχωρείται, αλλά εκχωρείται από το διαχειριστή και επιστρέφεται κατά την απάντηση του διαχειριστή. Για την ενημέρωση μιας εγγραφής όμως χρειάζεται και η εισαγωγή του κλειδιού αυτού. Οι λειτουργίες διαγραφής δέχονται τα κλειδιά που εκχώρησαν οι διαχειριστές σαν παραμέτρους, και διαγράφουν τις αντίστοιχες εγγραφές από τον κατάλογο. Ειδική περίπτωση διαγραφής αποτελεί η λειτουργία delete_tmodel. Όταν ένας αυθεντικοποιημένος χρήστης, χρησιμοποιήσει την παραπάνω λειτουργία για την διαγραφή ενός tmodel, αυτό δεν διαγράφεται φυσικά από τον κατάλογο, αλλά σημειώνεται ως κρυφό. Με τον τρόπο αυτό, είναι ακόμα διαθέσιμο στον αυθεντικοποιημένο χρήστη, αλλά δεν επιστρέφεται ως αποτέλεσμα από τις λειτουργίες αναζήτησης. Ο χρήστης, μπορεί να επανεισάγει το tmodel, χρησιμοποιώντας τη λειτουργία save_tmodel περνώντας ως παράμετρο το κλειδί του αρχικού tmodel. Οι λειτουργίες αναζήτησης δέχονται ένα σύνολο από κριτήρια σαν είσοδο, και το αποτέλεσμά τους συνήθως είναι μια δομή λίστας η οποία περιέχει τις εγγραφές που ικανοποιούν τα κριτήρια που είχαν τεθεί. Οι λειτουργίες αναζήτησης λεπτομερειών δέχονται μια λίστα από κωδικούς αναγνώρισης και επιστρέφουν λεπτομερείς πληροφορίες σχετικά με τις καταχωρήσεις που αντιστοιχούν στους κωδικούς της εισόδου. Η προγραμματιστική διεπαφή, παρέχει και μια επιπρόσθετη λειτουργία αναζήτησης λεπτομερειών, την get_businessdetailext, η οποία χρησιμοποιείται για την ανάκτηση εκτεταμένων πληροφοριών για εταιρίες από κόμβους μη διαχειριστών, που διατηρούν αυτές τις πρόσθετες πληροφορίες. Επιπλέον, επειδή η προγραμματιστική διεπαφή δημοσίευσης είναι ένα σύνολο από πιστοποιημένες λειτουργίες, όπου η αναγνώριση ενός χρήστη βασίζεται στη χρήση κουπονιών, η διεπαφή αυτη παρέχει και δυο λειτουργίες πιστοποίησης, τις get_authtoken και discard_authtoken.

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

71 4. Μελέτη Περίπτωσης (Case Study) 4.1 Σενάριο Η εταιρία παραγωγής λαχανικών και φρούτων ΦΡΕΣΚΟ Α.Ε ζήτησε την κατασκευή ενός προγράμματος το οποίο να αποθηκεύει τα δεδομένα ενός θερμοκηπίου μια φορά τη μέρα. 4.2 Προδιαγραφές συστήματος Γνωρίζοντας την ύπαρξη υπολογιστή και εκπαιδευμένου χρήστη καθώς και την ύπαρξη και χρήση συσκευής κινητού τηλεφώνου με λογισμικό android καταλήγουμε ότι οι προδιαγραφές για την ανάπτυξη του συστήματος που μας ζητήθηκε είναι οι εξής: Microsoft.NET 4.0 Framework Microsoft Visual C# Microsoft WCF Web Services Java Android SQL 4.3 Βάση δεδομένων Για την υλοποίηση και τη διαχείριση της βάσης δεδομένων έγινε χρήση του SQL Server Management Studio 2008 R2. Πριν όμως περάσουμε σε αυτό το κομμάτι θα αναλύσουμε τις οντότητες που υπάρχουν. Από την ανάλυση προκύπτουν οι εξής οντότητες με τις ακόλουθες συσχετίσεις. -71-

72 Συσκευή 1 1 Εγγραφή 1 1 Θερμοκήπιο 1 1 Εργάτης Στη συνέχεια θα αναλύσουμε τον κάθε πίνακα που προκύπτει από κάθε οντότητα και τα γνωρίσματα τις κάθε μιας Πίνακας tdevice Ο πίνακας αυτός περιγράφει τη συσκευή από την οποία έγινε η καταχώρηση. Έχει 2 πεδία, τον κωδικό της συσκευής που αποτελεί και το κύριο κλειδί του πίνακα και το όνομα της συσκευής. Εικόνα 1-72-

73 4.3.2 Πίνακας tgreenη Αυτός ο πίνακας 2 πεδίων περιγράφει το θερμοκήπιο το οποίο αφορά η καταχώρηση που γίνεται. Τα πεδία του είναι ο κωδικός του θερμοκηπίου, που έχει ρόλο κύριου κλειδιού, και η διεύθυνση του. Εικόνα Πίνακας tworker Υπεύθυνος για την περιγραφή της οντότητας του υπαλλήλου ο οποίος κάνει την εγγραφή κάθε φορά ο συγκεκριμένος πίνακας αποτελείται από 5 πεδία. Τον κωδικό του υπαλλήλου που είναι και πάλι το κύριο κλειδί, το όνομα, το επίθετο, την ηλικία και τη διεύθυνση του. Εικόνα Πίνακας trecord Τέλος ο πίνακας αυτός περιλαμβάνει όλα τα στοιχεία που μας ενδιαφέρει να καταγράψουμε στο θερμοκήπιο δηλαδή την ταχύτητα του ανέμου, την εξωτερική θερμοκρασία, την εσωτερική θερμοκρασία, την εξωτερική υγρασία και την εσωτερική υγρασία. Επίσης επικοινωνεί με όλους τους άλλους πίνακες με τη χρήση των ξένων κλειδιών που συνδέονται με τα κύρια κλειδιά των άλλων πινάκων που μαζί με τον κωδικό της εγγραφής που αποτελεί το δικό του κύριο κλειδί έχουμε ένα σύνολο 10 πεδίων. -73-

74 Εικόνα 4-74-

75 4.3.5 Διάγραμμα βάσης δεδομένων Τέλος οι πίνακες της βάσης δεδομένων μας συνδέονται με αυτόν τον τρόπο. Εικόνα 5-75-

76 4.4 Εφαρμογή Windows Form Αφού έχουμε κατασκευάσει τη βάση δεδομένων μας μπορούμε να προχωρήσουμε τη δημιουργία της εφαρμογής με την οποία θα γίνεται μέσω του υπολογιστή η εισαγωγή των εγγραφών και η αναζήτηση τους. Για αυτό το σκοπό θα χρησιμοποιήσουμε το Microsoft Visual Studio Η τελική μορφή που θέλουμε να έχει η εφαρμογή μας είναι αυτή. Εικόνα 6 Οπότε ο τύπος του project ο οποίος θα επιλέξουμε για να δημιουργήσουμε είναι windows form και το Framework.NET

77 Εικόνα Σύνδεση με βάση δεδομένων Αφού κάνουμε αυτές τις αλλαγές στις ιδιότητες συνδέουμε τη βάση με την εφαρμογή μας. Έτσι από τον server explorer και το εικονίδιο connect to database επιλέγοντας windows authentication και έπειτα το SQL Server Name μας βρίσκουμε το αρχείο της βάσης μας, το επιλέγουμε, κάνουμε κλικ στο test connection και αφού το τεστ είναι επιτυχές πατάμε Οκ για να συνδεθούμε με τη βάση. -77-

78 Εικόνα 8 Για να επιτρέψουμε όμως στην εφαρμογή μας να διαχειρίζεται η βάση πρέπει να γίνει και κάτι άλλο πρώτα για να γλυτώσουμε γραμμές κώδικα και να κερδίσουμε σε ευκολία διαχείρησης. Οπότε κάνοντας δεξί κλικ στο όνομα της εφαρμογής μας στο solution explorer και επιλέγοντας add και new item από τη λίστα στο επόμενο μενού από την επιλογή data διαλέγουμε LINQ to SQL Classes. -78-

79 Εικόνα 9 Με αυτό τον τρόπο δημιουργούμε το.dbml αρχείο το οποίο είναι ένας «κλώνος» της βάσης μας που τραβάει τους πίνακες της στην εφαρμογή μας και ενημερώνει τη βάση όταν γίνεται κάποια αλλαγή σε αυτό. Η γραφική μορφή του είναι η παρακάτω. Εικόνα

80 Όπως παρατηρείτε είναι παρόμοια με το διάγραμμα της βάσης δεδομένων μας. Αφού τελειώσουμε με αυτό από το toolbox στην καρτέλα [Design] του Form.cs αρχείου μας βάζουμε όλα τα γραφικά που είναι απαραίτητα για να κάνουμε τη φόρμα μας να μοιάζει με την παραπάνω μορφή της. Έπειτα θα γράψουμε τον κώδικα που χρειάζεται το κάθε γραφικό για να εκτελεί την διαδικασία που πρέπει και θα τον εξηγήσουμε Combo Boxes Ξεκινώντας λοιπόν το γράψιμο του κώδικα μας πρώτα γράφουμε την ενέργεια που θέλουμε να εκτελούν τα combo boxes μας. Η επιθυμητή ενέργεια που θέλουμε να πραγματοποιείται όταν επιλέγουμε ένα από τους κωδικούς στο combo box του υπαλλήλου είναι να εμφανίζονται στα αντίστοιχα πεδία κείμενου οι πληροφορίες που αντιστοιχούν στη εγγραφή του πίνακα που επιλέγουμε με τον αντίστοιχο κωδικό, ενώ στα κουτιά του θερμοκηπίου και της συσκευής, η διεύθυνση και το όνομα αντίστοιχα. Εικόνα 11 Ας εξηγήσουμε τον κώδικα που το κάνει αυτό δυνατό για το combo box με τον κωδικό του εργάτη. -80-

81 private void cmbworker_selectedindexchanged(object sender, EventArgs e) { try { DataClasses1DataContext dc = new DataClasses1DataContext(); var workers = from R in dc.tworkers //Ορίζω το R ως μεταβλητή πίνακα εγγραφών, πόσες και ποιές είναι οι εγγραφές μου where R.pki_woid == int.parse(this.cmbworker.selectedvalue.tostring()) select R; foreach(tworker w in workers) { this.txtwosu.text = w.wsname; this.txtwona.text = w.wname; this.txtage.text = w.age.tostring(); this.txtaddr.text = w.wadress; } } catch (Exception ex) { MessageBox.Show("Error: " + ex.tostring(), "Message from the Application", MessageBoxButtons.OK, MessageBoxIcon.Error); } } Δημιουργούμε την παραπάνω μέθοδο η οποία καλείται κάθε φορά που αλλάζει η τιμή που αναγράφετε στο κουτί. Αφού αλλάξει η τιμή καλείται η μέθοδος και ελέγχει δημιουργώντας ένα προσωρινό data context που στη συνέχεια το χρησημοποιώ για να τραβήξω τις πληροφορίες από τον πίνακα tworkers με τη βοήθεια της μεταβλητής R και να τις αποθηκεύσω στην var μεταβλητή workers. Στην συνέχεια όπου το πεδίο με τον κωδικό του υπαλλήλου είναι ίδιο με αυτό που υπάρχει στο combo box γίνεται επιλογή για κάθε στήλη που αντιστοιχεί σε αυτό και οι τιμές κάθε στήλης αναγράφονται στα αντίστοιχα πεδία κειμένου πάνω στην εφαρμογή μας όπως φάνηκε παραπάνω. Σε περίπτωση που πέσουμε σε χειρισμό εξαίρεσης η εφαρμογή εμφανίζει παράθυρο σφάλματος. Με όμοιο τρόπο εμφανίζονται και οι τιμές για τα combo boxes του θερμοκηπιόυ: private void cmbgreenhouse_selectedindexchanged(object sender, EventArgs e) { try { DataClasses1DataContext dc = new DataClasses1DataContext(); var greenh = from R in dc.tgreenhs where R.adress == this.cmbgreenhouse.selectedvalue.tostring() select R; foreach (tgreenh w in greenh) { g_intgreenhid = w.pki_grid; } } catch (Exception ex) { MessageBox.Show("Error: " + ex.tostring(), "Message from the Application", MessageBoxButtons.OK, MessageBoxIcon.Error); } -81-

82 } Και της συσκευής: private void cmbdevice_selectedindexchanged(object sender, EventArgs e) { try { DataClasses1DataContext dc = new DataClasses1DataContext(); var device = from R in dc.tdevices where R.devname == this.cmbdevice.selectedvalue.tostring() select R; foreach (tdevice w in device) { g_intdeviceid = w.pki_devid; } } catch (Exception ex) { MessageBox.Show("Error: " + ex.tostring(), "Message from the Application", MessageBoxButtons.OK, MessageBoxIcon.Error); } Κουμπία Ξεκινώντας να αναλύουμε τα κουμπιά της εφαρμογής μας το πρώτο κουμπί που θα αναλύσουμε είναι το Clear. private void btnnew_click(object sender, EventArgs e) { this.btnsub.enabled = true; dtpick.value = DateTime.Today; txtwona.clear(); txtwosu.clear(); txtage.clear(); txtaddr.clear(); txtwisp.clear(); txtextem.clear(); txtintem.clear(); txtexhum.clear(); txtinhum.clear(); //txtghaddr.clear(); //txtdevna.clear(); cmbworker.selectedindex = 0; cmbgreenhouse.selectedindex = 0; cmbdevice.selectedindex = 0; DateTime l_datetime = new DateTime(1900, 1, 1); this.setdetailstogrid(l_datetime); } Το όνομα του στην εφαρμογή είναι btnnew και στην υλοποίηση του Click του ενεργοποιείται το κουμπί btnsub, δηλαδή το κουμπί submit που κάνει την καταχώρηση στη βάση δεδομένων, ως ασφαλιστική δικλείδα για να αποφύγουμε διπλές εγγραφές. Έπειτα γυρνάει την ημερομηνία του ημερολογίου της εφαρμοργής στη σημερινή και καθαρίζει όλα τα πεδία κειμένου και τα combo boxes από τις τιμές που είχαν πριν. Τέλος βάζει στο datagridview μας μια ημερομηνία μηδενισμού ώστε να καθαρίζει και αυτό. -82-

83 Στη συνέχεια θα αναλύσουμε το κουμπί Submit. private void btnsub_click(object sender, EventArgs e) { try { DataClasses1DataContext dc = new DataClasses1DataContext(); //Δημιουργία data context trecord thisrecord = new trecord(); thisrecord.datime = DateTime.Now; thisrecord.wispeed = Convert.ToDouble(txtwisp.Text); thisrecord.extempec = Convert.ToDouble(txtextem.Text); thisrecord.intempec = Convert.ToDouble(txtintem.Text); thisrecord.exhumi = Convert.ToDouble(txtexhum.Text); thisrecord.inhumi = Convert.ToDouble(txtinhum.Text); thisrecord.fki_wid = int.parse(cmbworker.selectedvalue.tostring()); //thisworker.pki_woid; thisrecord.fki_ghid = g_intgreenhid; //thisgreenh.pki_grid; thisrecord.fki_did = g_intdeviceid; //thisdevice.pki_devid; dc.trecords.insertonsubmit(thisrecord); } catch { dc.submitchanges(); MessageBox.Show("Entry Added!"); MessageBox.Show("Please check for empty values and then press Submit button again.", "Message from the Application", MessageBoxButtons.OK, MessageBoxIcon.Exclamation); } } Δημιουργούμε και εδώ πρώτα ένα data context και έπειτα μια μεταβλητή πίνακα τύπου trecord όπως και ο πίνακας που έχουμε στη βάση μας. Στη συνέχεια παίρνουμε από τα αντίστοιχα πεδία κειμένου της εφαρμογής μας τις τιμές και τις μετατρέπουμε στη σωστή μορφή ώστε να ταιριάζουν με τη μορφή που και έχουμε ορίσει στη βάση και τις καταχωρούμε στα αντίστοιχα πεδία του πίνακα που μόλις δημιουργήσαμε. Αφού γίνει η καταχώρηση των τιμών στον πίνακα περνάμε τις τιμές του δημιουργημένου πίνακα μέσω του data context στον πίνακα της κλάσης LINQ που δημιουργήσαμε νωρίτερα και τέλος αφού τις αποθηκεύσουμε η εφαρμογή εμφανίζει το μήνυμα της επιτυχούς καταχώρησης. Εάν περάσουμε σε χειρισμό εξαίρεσης τότε εμφανίζεται μήνυμα ότι υπάρχουν κενά πεδία και πρέπει να γίνει έλεγχος και να δώσει ο χρήστης τιμές, σε ένα παράθυρο μηνύματος. -83-

84 Στη συνέχεια εξηγούμε γρήγορα το κουμπί Find. private void btnfin_click(object sender, EventArgs e) { this.btnsub.enabled = false; this.setdetailstogrid(dtpick.value.date); } To όνομα του είναι btnfin και έχει αρκετά απλή λειτουργία/ Απενεργοποιεί το κουμπί Sumbit και γεμίζει το datagridview με τιμές βάσει της ημερομηνίας τις οποίας οι εγγραφές μας ενδιαφέρουν. Στην ουσία η αναζήτηση γίνεται με βάση την ημερομηνία και η περιήγηση με το datagridview το οποίο από τις ιδιότητες του το έχουμε ορίσει να εμφανίζει μόνο τα πεδία ID και Date από τον πίνακα trecords που είναι συνδεδεμένο. Τέλος το κουμπί Exit. private void btnexit_click(object sender, EventArgs e) { try { if (MessageBox.Show("Are you sure to exit from application?", "Message from the Application", MessageBoxButtons.YesNo, MessageBoxIcon.Question) == System.Windows.Forms.DialogResult.Yes) { this.dispose(); } } catch (Exception ex) { MessageBox.Show("Error: " + ex.tostring(), "Message from the Application", MessageBoxButtons.OK, MessageBoxIcon.Error); } } Όταν πατηθεί η εφαρμογή εμφανίζει ένα yes no παράθυρο μηνύματος που ρωτάει εάν θέλουμε να βγούμε από την εφαρμογή. Ένα επιλέξουμε Yes την τερματίζει. Εάν μπούμε σε χειρισμό εξαίρεσης τότε εμφανίζει παράθυρο μηνύματος με το μήνυμα Error Message from the Application. -84-

85 4.5 WCF Web Service Για την δημιουργία της υπηρεσίας δικτύου η οποία θα επικοινωνεί με τη βάση δεδομένων θα γίνει χρήση του Microsoft Visual Web Developer 2010 Express. Ξεκινώντας λοιπόν τη δημιουργία του project όμοια με το Visual Studio πριν επιλέγουμε από την επιλογή Visual C# το WCF Service Application και όπως και πριν ορίζουμε το framework σε.νετ 4.0 και συνδέουμε τη βάση με μόνη διαφορά αυτή τη φορά πως αντί για LINQ to SQL Classes χρησιμοποιούμε dataset για λόγους σύγκρισης των τεχνολογιών LINQ και dataset. Στο WCF υπάρχουν 2 αρχεία που μας ενδιαφέρουν το Service1.svc.cs και το IService1.cs. Το πρώτο περιέχει τον κώδικα της υπηρεσίας και το δεύτερο περιέχει ένα είδος interface καθώς και τα συμβόλαια που πρέπει να ρυθμιστούν για την εκτέλεση της υπηρεσίας. Ξεκινώντας από το Service1 λοιπόν. using System; using System.Collections.Generic; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Web; using System.Text; using System.Data.Linq; using System.Data.Linq.Mapping; namespace CSWCF { // NOTE: You can use the "Rename" command on the "Refactor" menu to change the class name "Service1" in code, svc and config file together. public class Service1 : IService1 { public string GetData(string a_strdate) { string result = " "; using (ds l_ds = new ds()) { using (trecordtableadapter l_tarecords = new trecordtableadapter()) { l_tarecords.connection.connectionstring = Settings.Default.ITPROSAT_ProductKeysConnectionString; l_tarecords.fill(l_ds.trecord); using (tworkertableadapter l_taworkers = new tworkertableadapter()) { l_taworkers.connection.connectionstring = Settings.Default.ITPROSAT_ProductKeysConnectionString; l_taworkers.fill(l_ds.tworker); using (tgreenhtableadapter l_tagreenh = new tgreenhtableadapter()) { l_tagreenh.connection.connectionstring = Settings.Default.ITPROSAT_ProductKeysConnectionString; l_tagreenh.fill(l_ds.tgreenh); using (tdevicetableadapter l_tadevices = new tdevicetableadapter()) -85-

86 { l_tadevices.connection.connectionstring = Settings.Default.ITPROSAT_ProductKeysConnectionString; l_tadevices.fill(l_ds.tdevice); //Find records DataView l_dvrecords = new DataView(l_ds.tRecord); l_dvrecords.rowfilter = "datime = '" + a_strdate + "'"; for (int i = 0; i <= l_dvrecords.count - 1; i++) { DataView l_dvworker = new DataView(l_ds.tWorker); l_dvworker.rowfilter = "pki_woid = " + l_dvrecords[i]["fki_wid"]; DataView l_dvdevice = new DataView(l_ds.tDevice); l_dvdevice.rowfilter = "pki_devid = " + l_dvrecords[i]["fki_did"]; DataView l_dvgreenh = new DataView(l_ds.tGreenH); l_dvgreenh.rowfilter = "pki_grid = " + l_dvrecords[i]["fki_ghid"]; result += "Έγγραφή:" + l_dvrecords[i]["pki_rid"] + ";Όνομα" + l_dvworker[0]["wname"] + ";Επώνυμο:" + l_dvworker[0]["wsname"] + ";Ηλικία:" + l_dvworker[0]["age"] + ";Διεύθυνση:" + l_dvworker[0]["wadress"] + ";Θερμοκήπιο:" + l_dvgreenh[0]["adress"] + ";Συσκευή:" + l_dvdevice[0]["devname"] + ";Άνεμος:" + l_dvrecords[i]["wispeed"] + ";Εξ.Θερμ.:" + l_dvrecords[i]["extempec"] + ";Εσ.Θερμ.:" + l_dvrecords[i]["intempec"] + ";Εξ.Υγρασία:" + l_dvrecords[i]["exhumi"] + ";Εσ.Υγρασία:" + l_dvrecords[i]["inhumi"] + ";"; } } } } } } return result; } } } Βλέπουμε στην αρχή to namespace της υπηρεσίας μας και στη συνέχεια τον κώδικα της, στην δική μας περίπτωση η υπηρεσία που υλοποιούμε είναι η μέθοδος GeData τύπου String με όρισμα ένα String το a_strdate που περιέχει την ημερομηνία με βάση την οποία θα γίνει η έρευνα των εγγραφών. Αρχικοποιούμε την μεταβλητή result με κενό, αυτή η μεταβλητή στο τέλος θα περιέχει το αποτέλεσμα της αναζήτησης μας. Επειτα δημιουργούμε ένα προσωρινό dataset το l_ds ώστε να πάρουμε εκεί τις πληροφορίες από τους table adapters που δημιουργούμε παρακάτω. Παρακάτω λοιπόν γεμίζουμε το l_ds με πίνακες αντίγραφα των πινάκων από τη βάση με τη χρήση του connection string της βάσης που έχουμε σηκώσει στο server μας. Αφού λοιπόν γεμίσουμε το l_ds περνάμε στην έρευνα. Φτιάχνουμε ένα dataview με τις εγγραφές του trecord από l_ds και στη συνέχεια το φιλτράρουμε κατά γραμμή με βάση την ημερομηνία που μας δώθηκε. Έπειτα σε μια δομή επανάληψης με το μετρητή να ξεκινάει από το μηδέν και όσο είναι μικρότερος από το πλήθος των -86-

87 εγγραφών φτιάχνουμε data views όμοια με πριν για κάθε πίνακα της βάσης όπου το κύριο κλειδί των εγγραφών τους ταιριάζει με το ξένο κλειδί στις εγγραφές που γίνεται η αναζήτηση. Τέλος το αποτέλεσμα της αναζήτησης αποθηκεύεται στο result ως ένα μεγάλο string με ερωτηματικά σκόπιμα τοποθετημένα σε κάθε πεδίο και το result επιστρέφεται. Για να εκτελεστεί όμως αυτό πρέπει πρώτα να ορίσουμε την Get Data στο IService1. namespace CSWCF { // NOTE: You can use the "Rename" command on the "Refactor" menu to change the interface name "IService1" in both code and config file together. [ServiceContract] public interface IService1 { } } [OperationContract] string GetData(string a_strdate); Οπότε μέσα στο interface ορίζουμε ένα Operation Contract με την μέθοδο GetData και τα ορίσματα της μέσα. 4.6 Android Application Τέλος για να γίνει χρήση της υπηρεσίας που δημιουργήσαμε θα δημιουργήσουμε και μια android εφαρμογή έτσι ώστε να μπορεί ο αρμόδιος των θερμοκηπίων να βλέπει μέσω του κινητού του την εγγραφή της ημέρας για το θερμοκήπιο όπου και να βρίσκεται. Για τη δημιουργία της εφαρμογής αυτής χρησιμοποιήθηκε το eclipse indigo. Αφού γίνουν όλες οι αναβαθμίσεις για να γίνει εφικτή η ανάπτυξη android εφαρμογών ξεκινάμε δημιουργώντας ένα νέο android project. Αφού δώσουμε όνομα επιλέγουμε σαν build target το Android 2.2 και στη συνέχεια σαν package name το com.greenhouse το οποίο είναι τύπου activity. Στη συνέχεια με δεξί κλίκ στο όνομα του project στο package explorer επιλέγουμε configure build path ώστε να βγει το παρακάτω παράθυρο διαλόγου. -87-

88 Εικόνα 12 Στη συνέχεια επιλέγουμε το add external JARs και βρίσκουμε και επιλέγουμε το ksoap2-android-assembly-2.4-jar-with-dependencies.jar που περιέχει όλες τις βιβλιοθήκες που χρειαζόμαστε για να καλέσουμε και να χρησιμοποιήσουμε μέσω της android εφαρμογής μας την υπηρεσία δικτύου που δημιουργήσαμε παραπάνω. Έπειτα πηγαίνουμε στο res, layout, main.xml στον package explorer ώστε να τροποποιήσουμε το interface της εφαρμογής. -88-

89 Εικόνα 13 Αφού το φέρουμε σε αυτή τη μορφή τοποθετώντας τα αντίστοιχα textviews, edittexts και το κουμπί, περνάμε στο γράψιμο του κώδικα. Στη μορφή αυτή έχουμε ένα textview που λέει στο χρήστη σε τι μορφή να βάλει την ημερομηνία. Κάτω από το textview Results όλες οι textview που δείχνουν παύλες θα εμφανίσουν μετά την κλήση της υπηρεσίας τα αποτελέσματα της εγγραφής. Ο κώδικας της εφαρμογής είναι ο ακόλουθος: package com.greenhouse; import org.ksoap2.soapenvelope; import org.ksoap2.serialization.soapobject; import org.ksoap2.serialization.soapserializationenvelope; import org.ksoap2.transport.httptransportse; import android.app.activity; import android.content.context; import android.os.bundle; import android.view.view; import android.view.inputmethod.inputmethodmanager; import android.widget.button; import android.widget.edittext; import android.widget.textview; import java.util.*; public class GreenHouseActivity extends Activity { private static final String SOAP_ACTION = " private static final String METHOD_NAME = "GetData"; -89-

90 private static final String NAMESPACE = " private static final String URL = " private String g_strresult; /** Called when the activity is first created. public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.main); final EditText l_txtedit = (EditText)findViewById(R.id.txtEdit); final Button l_btninvoke = (Button)findViewById(R.id.btnOK); final TextView txttitle = (TextView)findViewById(R.id.txtTitle); final TextView txtfield = (TextView)findViewById(R.id.txtField); final TextView txtrec = (TextView)findViewById(R.id.txtRec); final TextView txtname = (TextView)findViewById(R.id.txtName); final TextView txtsurname = (TextView)findViewById(R.id.txtSurname); final TextView txtage = (TextView)findViewById(R.id.txtAge); final TextView txtaddress = (TextView)findViewById(R.id.txtAddress); final TextView txtgreenhouse = (TextView)findViewById(R.id.txtGreenhouse); final TextView txtdevice = (TextView)findViewById(R.id.txtDevice); final TextView txtwindpeed = (TextView)findViewById(R.id.txtWindspeed); final TextView txtextemperature = (TextView)findViewById(R.id.txtExtemperature); final TextView txtintemperature = (TextView)findViewById(R.id.txtIntemperature); final TextView txtexhumidity = (TextView)findViewById(R.id.txtExhumidity); final TextView txtinhumidity = (TextView)findViewById(R.id.txtInhumidity); InputMethodManager imm = (InputMethodManager) getsystemservice(context.input_method_service); imm.hidesoftinputfromwindow(l_txtedit.getwindowtoken(),0); l_btninvoke.setonclicklistener ( new View.OnClickListener() { public void onclick(view v) { InvokeWebService(l_txtEdit.getText().toString()); g_strresult = StringTokenizer st = new StringTokenizer(g_strResult,";"); ArrayList <String> al = new ArrayList<String>(); while (st.hasmoretokens()) { -90-

91 } ); } } al.add(st.nexttoken()); } txtrec.settext(al.get(0)); txtname.settext(al.get(1)); txtsurname.settext(al.get(2)); txtage.settext(al.get(3)); txtaddress.settext(al.get(4)); txtgreenhouse.settext(al.get(5)); txtdevice.settext(al.get(6)); txtwindpeed.settext(al.get(7)); txtextemperature.settext(al.get(8)); txtintemperature.settext(al.get(9)); txtexhumidity.settext(al.get(10)); txtinhumidity.settext(al.get(11)); private String InvokeWebService(String a_strdate) { try { SoapObject request = new SoapObject(NAMESPACE, METHOD_NAME); request.addproperty("a_strdate", a_strdate); SoapSerializationEnvelope envelope = new SoapSerializationEnvelope(SoapEnvelope.VER11); envelope.dotnet = true; envelope.setoutputsoapobject(request); HttpTransportSE androidhttptransport = new HttpTransportSE(URL); androidhttptransport.call(soap_action, envelope); Object result = (Object)envelope.getResponse(); return result.tostring(); } catch (Exception ex) { return ex.tostring(); } } } Αφού εισάγουμε όλες τις βιβλιοθήκες που είναι απαραίτητες ξεκινάμε δηλώνοντας σαν global μεταβλητές τις παραμέτρους κλήσης της υπηρεσίας μας. Δηλαδή το όνομα της δράσης που θα πρέπει να εκτελέσει η υπηρεσία, το όνομα της μεθόδου, το namespace της υπηρεσίας, τη διεύθυνση της στο δίκτυο και τέλος τη μεταβλητή που θα περιέχει το αποτέλεσμα που θα επιστρέψει η υπηρεσία. Στη συνέχεια ορίζουμε όλα τα γραφικά που βάλαμε στο graphic layout του interface στο main.xml. Έπειτα υλοποιούμε το click του κουμπιού. Η πρώτη διαδικασία που θα γίνει θα είναι να κληθεί η μέθοδος InvokeWebService με την τιμή που έχουμε δώσει στο textedit πεδίο και να τοποθετήσει το αποτέλεσμα στην global μεταβλητή g_strresult. Η μέθοδος InvokeWebService λειτουργεί ως εξής. -91-

92 Δημιουργεί ένα αντικείμενο τύπου SoapObject με το όνομα request που περιέχει το namespace και το όνομα της μεθόδου. Στη συνέχεια το αντικείμενο αυτό δέχεται την τιμή της ημερομηνίας που έχουμε δώσει. Μετά δημιουργεί ένα SoapEnvelope αντικείμενο που περιέχει την έκδοση που δηλώνουμε να έχει το πρωτόκολο και μετά δηλώνει ότι απευθύνεται σε.net. Έπειτα ορίζει Ως αντικείμενο του envelope που θα καλέσει το SOAP το request. Στη συνέχεια δημιουργεί το αντικείμενο τύπου HttpTransportSE με τη URL της υπηρεσίας μέσα ώστε να την καλέσει. Μέτα με ορίσματα τη δράση που πρέπει να κληθεί και το envelope καλείται η υπηρεσία δικτύου που έχουμε δημιουργήσει. Τέλος δημιουργεί το αντικείμενο request και καταχωρεί εκεί το αποτέλεσμα που του επιστρέφει η υπηρεσιά και την επιστρέφει. Πίσω στο click του κουμπιού με τη χρήση της μεθόδου string tokenizer και τη δημιουργία μια λίστας πινάκων «σπάμε» το αποτέλεσμα της υπηρεσίας με βάση τα ερωτηματικά και μετά τοποθετούμε τα πεδία από τις θέσεις τις λίστας στα textviews. Εικόνα