ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ. ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ

Transcript

1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ «Σύγκριση Υπηρεσιοστραφών Μεθοδολογιών Ανάπτυξης Λογισμικού» Ζάχαρη Δέσποινα Μ ΑΘΗΝΑ,

2

3 ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ «Σύγκριση Υπηρεσιοστραφών Μεθοδολογιών Ανάπτυξης Λογισμικού» Ζάχαρη Δέσποινα Μ Επιβλέπων Καθηγητής: Εμμανουήλ Γιακουμάκης Εξωτερικός Κριτής: Νικόλαος Μαλεύρης ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΑΘΗΝΑ,

4

5 ΠΙΝΑΚΑΣ ΠΕΡΙΕΧΟΜΕΝΩΝ Ευχαριστίες Περίληψη Abstract Λεξικό Όρων ο - ΚΕΦΑΛΑΙΟ «SOA: Βασικά Στοιχεία» Ιστορική Αναδρομή Ορισμός και Σκεπτικό Υπηρεσιοστραφούς Αρχιτεκτονικής (Service-Oriented Architecture SOA) Βασικά Χαρακτηριστικά και Απαιτήσεις Οφέλη και Παγίδες Η Έννοια της Υπηρεσίας Χαρακτηριστικά Υπηρεσιών Στοιχεία SOA Αρχιτεκτονικής SOA Αρχιτεκτονική Αναφοράς Μοντελοποίηση SOA Αρχιτεκτονικών Στατικό Μοντέλο Δυναμικό Μοντέλο ο - ΚΕΦΑΛΑΙΟ «SOA: Ανάλυση και Σχεδίαση» Υπηρεσιοστραφείς Αρχές Υλοποίησης Πρακτικές Σωστής Ανάπτυξης μίας SOA Αρχιτεκτονικής SOA Ανάλυση και Σχεδίαση ESB Ο Συνδυασμός της BPM, της EA και της Αντικειμενοστραφούς Ανάλυσης και Σχεδίασης Επιχειρησιακή Αρχιτεκτονική (Enterprise Architecture EA) Μοντέλο Επιχειρησιακών Διαδικασιών (Business Process Model BPM) Η Αντικειμενοστραφής (Object-Oriented) Σχεδίαση σε Σχέση με την Υπηρεσιοστραφή (Service-Oriented) Σχεδίαση Απαιτήσεις Παράγοντες που Καθορίζουν την Ποιότητα Ο - ΚΕΦΑΛΑΙΟ «Περιγραφή Μεθοδολογιών»

6 3.1 Εισαγωγή Μεθοδολογία SOAD Παράγοντες Ποιότητας Αναγνώριση και Ορισμός Υπηρεσιών Κατηγοριοποίηση και Συσσωμάτωση Υπηρεσιών Σημασιολογία Μεσιτείας Υπηρεσιών Πολιτικές και Πτυχές Διαδικασία meet-in-the-middle Συγκομιδή Υπηρεσιών και Μεσιτεία Γνώσης Μεθοδολογία TRUE (ICEIS) Μοντελοποίηση Επιχειρησιακών Υπηρεσιών Σχεδιασμός Τομέων Σχεδιασμός Συστατικών Σχεδίαση Διεπαφών και Ενεργειών Μεθοδολογία SOAF Φάση 1 η Εκμαίευση Πληροφοριών Φάση 2 η - Αναγνώριση υπηρεσιών και αντιστοίχιση Φάση 3 η - Ορισμός Υπηρεσιών και Μοντελοποίηση Φάση 4 η - Πραγματοποίηση Υπηρεσιών Φάση 5 η - Πλάνο Σχεδιασμού Μεθοδολογία SODIUM (Service-Oriented Development In a Unified framework) Γενικευμένο Μοντέλο Υπηρεσιών (GeSMO) Γλώσσες της SODIUM Μεθοδολογία SODIUM Πλατφόρμα SODIUM και Εργαλεία Μεθοδολογία SOMA (Service Oriented Monteling and Architecture) Γενική Επισκόπιση Φάση Μοντελοποίησης Επιχείρησης και Μετασχηματισμού (Business Modeling and Transformation) Διαχείριση Λύσης (Solution Management) Φάση Εντοπισμού (Identification Phase) Φάση Προσδιορισμού (Specification Phase) Φάση Πραγματοποίησης (Realization Phase) Φάση Υλοποίησης (Implementation Phase) Μεθοδολογία SOSE (Service Oriented Software Engineering) Λόγοι Χρήσης Επιχειρησιακών Περιπτώσεων Λογισμικού

7 3.7.2 Μετατροπή Επιχειρησιακών Περιπτώσεων σε Αρχιτεκτονική Λογισμικού Τελική Σχεδίαση Μεθοδολογία Papazoglou (WSLD Web Services Lifecycle Development) _ Φάση 1 η - Προγραμματισμός Φάση 2 η Ανάλυση Φάση 3 η Σχεδίαση Υπηρεσιών Φάση 4 η Κατασκευή και Δοκιμή Υπηρεσιών Φάση 5 η Πρόβλεψη Υπηρεσιών Φάση 6 η Εγκατάσταση (Deployment) Φάση 7 η Εκτέλεση και Παρακολούθηση Μεθοδολογία Chang Οι φάσεις της μεθοδολογίας Φάση 100. Ανάλυση Υπηρεσιών Στόχων Φάση 200. Ορισμός Μονάδων Υπηρεσιών Φάση 300. Σχεδιασμός της απόκτησης συστατικών υπηρεσιών Φάση 400. Απόκτηση Συστατικών Υπηρεσιών Φάση 500. Ανάπτυξη Προσαρμογέα Υπηρεσιών Φάση 600. Επαλήθευση Σύνθεσης Υπηρεσιών Η μεθοδολογία OASIS Το Επίπεδο Το Επίπεδο Κοινόχρηστες υπηρεσίες εικόνας και υποστήριξης Συλλογική Εργασία Η γλώσσα για τον προσδιορισμό των υπηρεσιών Η Δημιουργία μιας Υπηρεσιοστραφούς Αρχιτεκτονικής Ολοκλήρωση της Αρχιτεκτονικής Διαχείριση Αλλαγής Μεθοδολογία SOUP Η μεθοδολογία SOUP πριν την 1 η Μετάβαση Η μεθοδολογία SOUP μετά την 1 η Μετάβαση Μεθοδολογία SECSE Επισκόπηση Service Centric System Engineering Functional Area Διαδικασίες Χρόνου Σχεδίασης Διαδικασίες Χρόνου Εκτέλεσης Service Engineering Functional Area

8 Service Acquisition/Provisioning Functional Area Validation and Verification Service Area Ο - ΚΕΦΑΛΑΙΟ «Σύγκριση Μεθοδολογιών» Εισαγωγή Η Καταλληλότητα Εφαρμογής Παραδοσιακών Μεθοδολογιών (RUP και XP) XP RUP Κριτήρια Αξιολόγησης SOSE Μεθοδολογιών Πλαίσιο Αξιολόγησης ως προς τα Γενικά Χαρακτηριστικά Πλαίσιο Αξιολόγησης ως προς τα Υπηρεσιοστραφή Χαρακτηριστικά Πλαίσιο Αξιολόγησης ως προς τα Χαρακτηριστικά Ανάλυσης και Σχεδίασης Σύγκριση SOSE Μεθοδολογιών Σύγκριση Γενικών Χαρακτηριστικών Σύγκριση Υπηρεσιοστραφών Χαρακτηριστικών Σύγκριση Χαρακτηριστικών Ανάλυσης και Σχεδίασης Σύνοψη - Συμπεράσματα ΒΙΒΛΙΟΓΡΑΦΙΑ

9 ΠΙΝΑΚΑΣ ΕΙΚΟΝΩΝ Εικόνα 1 Πριν και μετά την υπηρεσιοστραφή αρχιτεκτονική (Service-Oriented Architecture SOA) [10] Εικόνα 2 Αρχιτεκτονικά Στοιχεία της SOA [1] Εικόνα 3 SOA επιχειρησιακή προοπτική [1] Εικόνα 4 Πτυχές μίας SOA αρχιτεκτονικής αναφοράς [1] Εικόνα 5 SOA αρχιτεκτονική αναφοράς [1] Εικόνα 6 Το πακέτο των δομικών στοιχείων [2] Εικόνα 7 Το πακέτο για τα έγγραφα των προδιαγραφών [2] Εικόνα 8 Πακέτο για τα μηνύματα [2] Εικόνα 9 Ο κανόνας μετασχηματισμού ως ένα ζεύγος γραφημάτων [2] Εικόνα 10 Συνοπτικός συμβολισμός για την αποστολή μίας αίτησης σύνδεσης [2] Εικόνα 11 Κανόνας με κατάσταση αρνητικής εφαρμογής [2] Εικόνα 12 Κανόνας μετασχηματισμού «σύνδεσης στη συνεδρία» [2] Εικόνα 13 BPM, EA και αντικειμενοστραφής προσέγγιση μοντελοποίησης [6] Εικόνα 14 ESB μπλοκ διάγραμμα [7] Εικόνα 15 Τα επιμέρους στοιχεία της υπηρεσιοστραφούς (service-oriented) ανάλυσης και σχεδίασης και η προέλευση τους [6] Εικόνα 16 Επίπεδα σχεδίασης [6] Εικόνα 17 Υπηρεσιοστραφής ιεράρχηση του ορισμού της υπηρεσίας [6] Εικόνα 18 - Αποσύνθεση υπηρεσιών στη μεθοδολογία SOAD [6] Εικόνα 19 - Οι φάσεις της μεθοδολογίας SOAF [16] Εικόνα 20 Η φάση αναγνώρισης υπηρεσιών στη μεθοδολογία SOAF [16] Εικόνα 21 Διαδικασία διάσπασης υπηρεσιών [16] Εικόνα 22 - Προσεγγίσεις πραγματοποίησης υπηρεσιών στη μεθοδολογία SOAF [16] Εικόνα 23 - Τα τμήματα της μεθοδολογίας SODIUM [19] Εικόνα 24 - Αναπαράσταση του Γενικευμένου Μοντέλου Υπηρεσίας [19] Εικόνα 25 - Οι φάσεις της μεθοδολογίας SODIUM [19] Εικόνα 26 - Η πλατφόρμα και τα εργαλεία της SODIUM [19] Εικόνα 27 Διαδικασία Ανάπτυξης της Μεθοδολογίας SOSE [17] Εικόνα 28 - Η έννοια της υπηρεσίας στην Chang [15] Εικόνα 29 - Αρχιτεκτονική Διαστρωμάτωση [15] Εικόνα 30Τα στρώματα της αρχιτεκτονικής [15] Εικόνα 31 Οι φάσεις της μεθοδολογίας Chang [15] Εικόνα 32 Η αρχιτεκτονική του Χειριστή Δυναμικών Συνθέσεων [15] Εικόνα 33 - Το μοντέλο διαδικασίας SOUP [13] Εικόνα 34 - Το μοντέλο SOUP σε συνδιασμό με RUP [13] Εικόνα 35 - Η μεθοδολογία SOUP και οι XP διαδικασίες [13] Εικόνα 36 - Αλληλεπιδράσεις των λειτουργικών περιοχών της μεθοδολογίας SECSE [20]

10 Ευχαριστίες Θα ήθελα να ευχαριστήσω όλους όσους συνέβαλαν στην ολοκλήρωση της παρούσας εργασίας. Πρώτα απ όλα, θα ήθελα να ευχαριστήσω τον καθηγητή μου κ. Εμμανουήλ Γιακουμάκη για την εμπιστοσύνη και την πίστη που έδειξε στις ικανότητές μου, καθώς και για τις υποδείξεις του κατά την εκπόνηση της διπλωματικής μου εργασίας. Επιπρόσθετα, θα ήθελα να εκφράσω την ευγνωμοσύνη μου στον κ. Νικόλαο Διαμαντίδη, ο οποίος μου παρείχε συνεχή στήριξη και τις απαραίτητες κατευθύνσεις σε όλη τη διάρκεια της μελέτης και της συγγραφής της εργασίας μου. Τέλος, οφείλω ένα μεγάλο ευχαριστώ στην οικογένεια μου και στους φίλους μου για την αγάπη, τη συμπαράσταση και την ψυχολογική υποστήριξη που μου προσέφεραν και συνεχίζουν να μου προσφέρουν σε κάθε μου βήμα

11 Περίληψη Η υπηρεσιοστραφής αρχιτεκτονική (SOA) αποτελεί την πιο σύγχρονη αρχιτεκτονική προσέγγιση όσον αφορά το σχεδιασμό και την ανάπτυξη πληροφοριακών συστημάτων. Αφορά το σύνολο του οργανισμού και δεν επικεντρώνεται σε επίπεδο εφαρμογής. Βασικό χαρακτηριστικό αυτής της αρχιτεκτονικής είναι οι χαλαρά συνδεδεμένες, διαλειτουργικές και κατανεμημμένες δομικές μονάδες που παρέχονται με τη μορφή υπηρεσιών. Στο πλαίσια της παρούσας εργασίας μελετήθηκαν και περιγράφονται αναλυτικά έντεκα από τις υπάρχουσες υπηρεσιοστραφείς μεθοδολογίες ανάπτυξης λογισμικού που υποστηρίζουν την ανάπτυξη υπηρεσιοστραφών λύσεων. Από τις επιλεγμένες μεθοδολογίες άλλες έχουν προταθεί από τη βιομηχανία λογισμικού και άλλες από την ακαδημαϊκή κοινότητα. Η επιλογή των μεθοδολογιών που παρουσιάζονται έγινε με βάση τα παρακάτω κριτήρια: επίπεδο ωριμότητας αριθμός αναφορών διαθεσιμότητα πηγών κατάλληλη τεκμηρίωση Εκτός από τις δραστηριότητες των παραδοσιακών μεθοδολογιών (όπως η κωδικοποίηση, ο έλεγχος, η μετάβαση) η ανάπτυξη υπηρεσιοστραφών έργων απαιτεί τον εντοπισμό, την ανάκάλυψη και τη σύνθεση υπηρεσιών. Ως εκ τούτου οι υπάρχουσες μεθοδολογίες ανάπτυξης λογισμικού δεν πληρούν πλέον τις ανάγκες ενός υπηρεσιοστραφούς έργου. Σχεδόν όλες οι υπηρεσιοστραφείς μεθοδολογίες έχουν οριστεί στηριζόμενες στα χαρακτηριστικά των παραδοσιακών μεθοδολογιών (π.χ. αντικειμενοστρεφείς μεθοδολογίες). Οι υπηρεσιοστραφείς μεθοδολογίες μπορούν να θεωρηθούν ως εξέλιξη των παραδοσιακών μεθοδολογιών μιας και δεν διαφέρουν τόσο πολύ από τις παραδοσιακές. Ωστόσο υπάρχουν νέες εκτιμήσεις και οπτικές που θα πρέπει να ληφθούν υπόψη από την άποψη των νέων χαρακτηριστικών και των δραστηριοτήτων που είναι ειδικά για τις υπηρεσιοστραφείς μεθοδολογίες

12 Το ερώτημα «ποια είναι η καταλληλότερη υπηρεσιοστραφής μεθοδολογία» έχει απασχολήσει και συνεχίζει να απασχολεί εντόνως τόσο τη βιομηχανία λογισμικού όσο και την επιστημονική κοινότητα. Δεν είναι τυχαίο ότι το ερώτημα αυτό αποτελεί μια ερευνητική τάση των τελευταίων ετών στο πεδίο της SOA αρχιτεκτονικής που παρουσιάζει τεράστιο ενδιαφέρον. Πολλοί ερευνητές προσπάθησαν να απαντήσουν στην παραπάνω ερώτηση ή τουλάχιστον να ορίσουν τα κατάλληλα κριτήρια για τη σύγκρισή τους. Το μόνο βέβαιο είναι ότι όλες οι μεθοδολογίες έχουν τα παρακάτω μειoνεκτήματα: 1. Έλλειψη πλήρους κάλυψης του υπηρεσιοστραφούς κύκλου ζωής. 2. Έλλειψη υποστηρικτικών εγγράφων όσον αφορά την πρακτική εφαρμογή των μεθοδολογιών. 3. Πρόχειρα μοντέλα ανάπτυξης διαδικασιών. 4. Οι περισσότερες μεθοδολογίες περιγράφουν διαφορετικές δραστηριότητες με διαφορετικά ονόματα που στην πραγματικότητα είναι παρόμοιες. Παρόλο που έχει προταθεί ένας μεγάλος αριθμός υπηρεσιοστραφών μεθοδολογιών που καλύπτουν είτε ολόκληρο τον κύκλο ζωής είτε κάποιες φάσεις του, η έρευνα που αφορά το κομμάτι της σύγκρισης των υπαρχουσών μεθοδολογιών βρίσκεται ακόμα σε πρωτογενές στάδιο. Η παρούσα εργασία ορίζει ένα πλαίσιο σύγκρισης υπηρεσιοστραφών μεθοδολογιών που περιλαμβάνει τρεις κατηγορίες κριτηρίων: Γενικά κριτήρια αξιολόγησης Υπηρεσιοστραφή κριτήρια αξιολόγησης Κριτήρια που σχετίζονται με τα χαρακτηριστικά ανάλυσης και σχεδίασης Επιπρόσθετα, περιγράφεται μια ολοκληρωμένη σύγκριση των υπηρεσιοστραφών μεθοδολογιών που επιλέχθηκαν. Η σύγκριση των μεθοδολογιών ακολουθεί την μέθοδο της ποιοτικής ανάλυσης που βασίζεται στους διαθέσιμους πόρους και στα έγγραφα των συγκρινόμενων μεθοδολογιών

13 Abstract The service-oriented architecture is the most modern architectural approach for designing and development of information systems. It covers the entire organization and is not focused in application level. The main components of this architectural style are loosely coupled, interoperable, and distributed building blocks provided in the form of services. In this work, studied and described in detail eleven service-oriented software engineering methodologies from existing methodologies that support the development of service-oriented solutions. The selected methodologies have been proposed by both the software industry and the academic community. The selection of the presented methodologies is based on the following criteria: maturity level number of citations adequate resources proper documentation Apart from the activities of traditional methodologies (such as coding, testing, transition) service-oriented development projects requires the identification, discovery and composition of services. Therefore existing software development methodologies no longer meet the needs of service-oriented projects. Almost all service-oriented software engineering methodologies have been defined based on the characteristics of the traditional methodologies (ex. Objectoriented methodologies). The service-oriented software engineering methodologies can be considered as evolution of traditional methodologies. However, there are new considerations and perspectives that should be considered in terms of new features and activities that are specific to the service-oriented methodologies. Τhe question Which is the most suitable Service-Oriented Software Engineering Methodology is a research trend of SOA domain that attract the interest of software industry and academia community. Many researchers tried to answer the above question or at least to define the appropriate criteria in order to compare them. However, it is certaint that all serviceoriented methodologies have the below drawbacks: 1. Lack of full coverage of the service-oriented development life cycle 2. Lack of supportive documents on their practical use

14 3. Cursory development process models 4. Most of the methodologies prescribe different activities with different names that are in fact similar Although, it has been proposed a large number of service-oriented methodologies covering either the whole life cycle or some phases, the research on the part of the comparison of existing methodologies is in primary stage. This work defines a comparison framework of service-oriented methodologies that includes three categories of criteria: General evaluation criteria Service specific criteria Analysis and design criteria It is also described a comprehensive comparison of selected methodologies. The comparison of service-oriented methodologies follows the method of qualitative analysis based on the available resources and documentation

15 Λεξικό Όρων Service-Oriented Architecture: Υπηρεσιοστραφής Αρχιτεκτονική Service Consumer: Καταναλωτής Υπηρεσίας Service Provider/Owner: Πάροχος/Ιδιωκτήτης Υπηρεσίας Service Composition: Σύνθεση Υπηρεσιών Choreography: Χορογραφία Orchestration: Ενορχήστρωση Coarse-grained service: Χονδρόκκοκη (γενική) Υπηρεσία Fine-grained: Λεπτόκκοκη (λεπτομερής) Υπηρεσία Service governance: Διακυβέρνηση Υπηρεσιών Service granularity: Bαθμός Διάσπασης Υπηρεσιών Service identification: Αναγνώριση Υπηρεσιών Service realization: Πραγματοποίηση Υπηρεσιών Domain Decomposition: Διάσπαση Τομέα Legacy Systems: Υπάρχοντα Συστήματα Mediators: Μεσολαβητές Enterprise Service Bus: Επιχειρησιακός Υπηρεσιακός Δίαυλος Enterprise Architecture: Επιχειρησιακή Αρχιτεκτονική Business Process Modeling: Μοντελοποίηση Επιχειρησιακών Διαδικασιών Lanes: Λωρίδες Business Gap Analysis: Ανάλυση Επιχειρησιακού Κενού Streamlining: Εξορθολογισμός

16 1 ο - ΚΕΦΑΛΑΙΟ «SOA: Βασικά Στοιχεία» 1.1 Ιστορική Αναδρομή Την τελευταία δεκαπενταετία έχει γίνει αντιληπτό ότι οι υπηρεσίες Web μπορούν να αποτελέσουν τη βάση όχι μόνο μίας πλειάδας εφαρμογών, αλλά και μίας ξεχωριστής αρχιτεκτονικής που θα έχει την ικανότητα να αναδείξει της τεχνολογίας των υπηρεσιών Web και να υλοποιήσει την έννοια των υπηρεσιών σε μία επιχείρηση. Έτσι η Υπηρεσιοστραφής Αρχιτεκτονική (Serviced-Oriented Architecture SOA) αποτέλεσε μία από τις επικρατούσες τάσεις της τεχνολογίας της πληροφορικής [9]. Η Υπηρεσιοστραφής Αρχιτεκτονική είναι ιδιαίτερα πολύπλοκη καθότι εμπεριέχει τις αρχιτεκτονικές των εξυπηρετητών, τον προγραμματισμό αντικειμενοστραφών αντικειμένων, την ανάπτυξη εφαρμογών, τη χρήση του διαδικτύου καθώς και τα πλεονεκτήματα των τεχνολογιών ευρείας διάδοσης. Αναμφισβήτητα η SOA αποτελεί μια εξέλιξη στον τομέα της πληροφορικής που έχει ως στόχο τη σχεδίαση λογισμικού (software) με τη μορφή διαλειτουργικών υπηρεσιών, την εδραίωση γνώσεων που αποκτήθηκαν από προηγούμενες τεχνολογίες, την αξιοποίηση των πλεονεκτημάτων των υφιστάμενων τεχνολογιών και τον περιορισμό των κινδύνων από πιθανές δυσλειτουργίες του συστήματος [8]. Πριν τη SOA Στις συμβατικές αρχιτεκτονικές πληροφορικής, οι επιχειρησιακές διαδικασίες, οι εφαρμογές και τα δεδομένα τοποθετούνται σε ανεξάρτητες, μη συμβατές μεταξύ τους αποθήκες δεδομένων (data silos). Οι αποθήκες αυτές έχουν μεγάλο κόστος συντήρησης. Οι χρήστες περιηγούνται σε ξεχωριστά δίκτυα, σε ξεχωριστές εφαρμογές και σε ξεχωριστές βάσεις δεδομένων προκειμένου να εκτελέσουν συγκεκριμένες επιχειρησιακές διαδικασίες. Μετά τη SOA

17 Μία υπηρεσιοστραφής αρχιτεκτονική (Service-Oriented Architecture SOA) παρέχει τα δεδομένα που απαιτούνται για τις επιχειρησιακές διαδικασίες με τη μορφή ολοκληρωμένων υπηρεσιών. Οι χρήστες δεν είναι απαραίτητο να συνδέονται σε πολλαπλά συστήματα, να αναζητούν σχετικά δεδομένα και να ενσωματώνουν τα αποτελέσματα. Οι πληροφορίες εμφανίζονται ως μία ενιαία εφαρμογή [10]. Εικόνα 1 Πριν και μετά την υπηρεσιοστραφή αρχιτεκτονική (Service-Oriented Architecture SOA) [10]. 1.2 Ορισμός και Σκεπτικό Υπηρεσιοστραφούς Αρχιτεκτονικής (Service-Oriented Architecture SOA) Ο όρος Υπηρεσιοστραφής Αρχιτεκτονική (Service Oriented Architecture - SOA) αντιστοιχεί σε ένα υπόδειγμα για την υλοποίηση και τη συντήρηση των επιχειρησιακών διαδικασιών στα μεγάλα κατανεμημένα συστήματα. Ως όρος υφίσταται εδώ και αρκετό καιρό και έχει χρησιμοποιηθεί εκτενώς μέσα από διαφορετικά τεχνολογικά πλαίσια και σε διαφορετικούς επιχειρησιακούς σκοπούς. Η SOA δεν αναφέρεται σε μία συγκεκριμένη τεχνολογία, μεθοδολογία ή προτυποποίηση. Αντίθετα αποτελεί ένα τρόπο σκέψης, ένα σύστημα αξιών το οποίο μπορεί να αξιοποιηθεί στα πλαίσια του σχεδιασμού των πληροφοριακών συστημάτων ενός οργανισμού [8]

18 Η SOA έρχεται να καλύψει την ανάγκη της διαλειτουργικότητας των πληροφοριακών συστημάτων σε μεγάλους οργανισμούς. Στο παρελθόν υπήρξαν άλλες προσεγγίσεις για την αντιμετώπιση του προβλήματος της διαλειτουργικότητας των πληροφοριακών συστημάτων, όπως η συγκέντρωση (centralizing), δηλαδή η ύπαρξη ενός κεντρικού συστήματος το οποίο θα κάλυπτε όλες τις ανάγκες του οργανισμού και η εναρμόνιση (alignment), δηλαδή η χρησιμοποίηση κοινών τεχνολογιών και μεθοδολογιών για την ανάπτυξη των πληροφοριακών συστημάτων του οργανισμού. Και οι δύο αυτές προσεγγίσεις απέτυχαν επειδή δεν ήταν ούτε επεκτάσιμες ούτε ευέλικτες. Η SOA αποδέχεται ότι ο μόνος τρόπος για να διατηρηθεί η ευελιξία των μεγάλων κατανεμημένων συστημάτων, είναι η υποστήριξη: Της ετερογένειας των συστημάτων ενός οργανισμού. Σε έναν μεγάλο οργανισμό συνήθως υπάρχουν εφαρμογές που έχουν υλοποιηθεί με διαφορετική λογική και διαφορετικές τεχνολογίες. Η επικοινωνία των εφαρμογών αυτών παρουσίαζε ανέκαθεν τεχνικές δυσκολίες. Η εναρμόνιση των τεχνολογιών που χρησιμοποιούνται συνήθως δεν είναι εφικτή καθώς οι εφαρμογές αυτές έχουν διαφορετικούς ιδιοκτήτες. Επίσης η εναρμόνιση διάφορων εφαρμογών σε μία συγκεκριμένη τεχνολογία ακόμα και όταν είναι εφικτή, κοστίζει πολύ ακριβά. Της αποκέντρωσης των συστημάτων ενός οργανισμού. Σε έναν οργανισμό υπάρχουν πολλά και μεγάλα συστήματα τα οποία πρέπει να επικοινωνούν και να συνεργάζονται για την εκτέλεση των επιχειρησιακών λειτουργιών. Οι δυναμικές αλλαγές που συμβαίνουν σε ένα σύγχρονο εταιρικό περιβάλλον οδηγούν στη δημιουργία ετερογενών κατανεμημένων συστημάτων. Η ανοχή σφαλμάτων. Το κόστος από τη διακοπή της λειτουργίας των συστημάτων σε ορισμένες περιπτώσεις είναι πολύ μεγάλο καθότι υπάρχουν συστήματα τα οποία πρέπει να είναι πάντα σε λειτουργία. Η ανοχή στα σφάλματα μπορεί να επιτευχθεί με τη χαλαρή σύνδεση των κατανεμημένων συστημάτων η οποία αποτελεί μία από τις αρχές της υπηρεσιοστραφούς αρχιτεκτονικής [8]

19 1.3 Βασικά Χαρακτηριστικά και Απαιτήσεις Ορισμένα από τα βασικά χαρακτηριστικά και τις βασικές απαιτήσεις της υπηρεσιοστραφούς (service-oriented) αρχιτεκτονικής, συνοψίζονται παρακάτω: Διαλειτουργικότητα. Αφορά την εγκαθίδρυση συνδέσεων μεταξύ ετερογενών εφαρμογών λογισμικού ή μεταξύ ετερογενών συστημάτων. Οι υπηρεσίες επιτρέπουν στα προγράμματα που γράφονται σε διαφορετικές γλώσσες προγραμματισμού και αναπτύσσονται σε διαφορετικές πλατφόρμες χρησιμοποιώντας διαφορετικά πρωτόκολλα, να επικοινωνούν μεταξύ τους. Χαλαρή σύζευξη. Αναφέρεται στο βαθμό αμοιβαίας εξάρτησης μεταξύ των υπηρεσιών. Οι υπηρεσίες ανταλλάσσουν μηνύματα με τη βοήθεια σαφώς καθορισμένων συνδέσεων οι οποίες καθιστούν εφικτή την επικοινωνία με άλλες υπηρεσίες, μειώνοντας τις αμοιβαίες εξαρτήσεις. Απομόνωση. Αφορά τη δυνατότητα της τροποποίησης των υπηρεσιών χωρίς οποιοδήποτε αντίκτυπο σε υπηρεσίες με τις οποίες αλληλεπιδρούν. Συναρμολόγηση. Αποσκοπεί στην αύξηση της αξίας των υπηρεσιών χάρη στην ενσωμάτωση απλούστερων υπηρεσιών, με στόχο την επίτευξη νέας λειτουργικότητας. Οι υπηρεσίες μπορούν να συναρμολογηθούν εύκολα η μία με την άλλη προκειμένου να δημιουργηθούν πιο σύνθετες διαδικασίες και πιο εξελιγμένες υπηρεσίες, με μεγαλύτερη αξία. Από τεχνικής άποψης, ο όρος SOA επικεντρώνεται στον τρόπο σχεδιασμού ενός συστήματος. Έτσι οι υπηρεσίες που συνθέτουν τα SΟA συστήματα παρουσιάζουν τα ακόλουθα χαρακτηριστικά: Οι υπηρεσίες μπορούν να είναι μεμονωμένες ή μπορούν να συνδυάζονται και να συνθέτουν υψηλότερου επιπέδου υπηρεσίες. Οι υπηρεσίες επικοινωνούν με τους χρήστες-πελάτες τους με την ανταλλαγή κατάλληλων μηνυμάτων. Ο καθορισμός των υπηρεσιών εξαρτάται από τα μηνύματα που μπορούν να δεχθούν και τις απαντήσεις που μπορούν να δώσουν. Οι υπηρεσίες συμμετέχουν στη ροή μιας εργασίας. Έτσι, η σειρά με την οποία τα μηνύματα στέλνονται και παραλαμβάνονται έχει επιπτώσεις στην έκβαση των διαδικασιών που εκτελούνται από μια υπηρεσία. Αυτή η έννοια καλείται service choreography

20 Οι υπηρεσίες μπορούν να είναι απολύτως ανεξάρτητες ή να εξαρτώνται από τη διαθεσιμότητα άλλων υπηρεσιών ή να εξαρτώνται από την ύπαρξη ενός πόρου. Οι υπηρεσίες παρουσιάζουν λεπτομέρειες που τις χαρακτηρίζουν, όπως είναι οι δυνατότητες, οι διεπαφές, οι πολιτικές και τα υποστηριζόμενα πρωτόκολλα επικοινωνίας [9]. 1.4 Οφέλη και Παγίδες Στην παράγραφο αυτή παρουσιάζονται τα πλεονεκτήματα που προκύπτουν από τη χρήση της SOA, τα οποία έχουν να κάνουν κυρίως με την ταχύτερη ανάπτυξη των εφαρμογών και τον τρόπο που επωφελείται ένας οργανισμός από τις αρχές της υπηρεσιοστραφούς σχεδίασης. Ολοκλήρωση εφαρμογών. Επιτυγχάνεται μέσω της διαλειτουργικότητας των υπηρεσιών, οι οποίες είναι εφικτό να χρησιμοποιούνται από τις εφαρμογές ανεξάρτητα από την τεχνολογία από την οποία είναι υλοποιημένες. Επαναχρησιμοποίηση λογισμικού. Υλοποιείται σχεδιάζοντας τις υπηρεσίες με τρόπο που να καθίσταται εφικτή η κάλυψη των ζητούμενων απαιτήσεων και ταυτόχρονα λαμβάνοντας υπόψη μελλοντικές απαιτήσεις που ίσως προκύψουν. Εξορθολογισμός (Streamlining). H Αρχιτεκτονική των εφαρμογών βασίζεται στη σύνθεση των υπηρεσιών από άλλες υπηρεσίες. Αξιοποίηση συστημάτων που ήδη υπάρχουν. Οι υπηρεσίες είναι εφικτό να κατασκευαστούν έχοντας ως βάση τα υπάρχοντα συστήματα. Ευελιξία. Η ευελιξία επιτυγχάνεται με τη δημιουργία ενός συστήματος χαλαρά συνδεδεμένων, συναρμολογούμενων (composable), διαλειτουργικών και επαναχρησιμοποιήσιμων (reusable) υπηρεσιών. Εκτός από τα οφέλη που απορρέουν από την υλοποίηση μίας SOA αρχιτεκτονικής, η υλοποίηση αυτή κρύβει και ορισμένες παγίδες: Η υλοποίηση της SOA με βάση τη λογική παραδοσιακών κατανεμημένων συστημάτων. Στη περίπτωση αυτή ο οργανισμός

21 χρησιμοποιεί τεχνολογίες κατάλληλες για την υλοποίηση της SOA αλλά δεν ακολουθεί τις αρχές της SOA. Για παράδειγμα, ένας οργανισμός μπορεί να χρησιμοποιεί την τεχνολογία των Web υπηρεσιών, αλλά οι υπηρεσίες που κατασκευάζει με την τεχνολογία αυτή να μην είναι ούτε επαναχρησιμοποιήσιμες (reusable) ούτε συναρμολογούμενες (composable). Έλλειψη κοινών προτύπων κατά την ανάπτυξη συστημάτων στα πλαίσια ενός οργανισμού. Η μετάβαση σε μία SOA αρχιτεκτονική χωρίς την υιοθέτηση ενιαίων μεθοδολογιών κατά την ανάπτυξη των συστημάτων ενός οργανισμού, δεν μπορεί από μόνη της να εγγυηθεί τη διαλειτουργικότητα των συστημάτων αυτών. Έλλειψη μεταβατικού πλάνου. Η εγκατάσταση νέων υπηρεσιών μπορεί να αναδιαμορφώσει τη δομή των πληροφοριακών συστημάτων του οργανισμού. Συνεπώς είναι απαραίτητη η κατάρτιση ενός μεταβατικού πλάνου, για την αποφυγή πιθανών προβλημάτων. Απόδοση συστημάτων. Η εφαρμογή των τεχνολογιών που είναι κατάλληλες για την υλοποίηση της SOA, μπορεί να προσδώσει πρόσθετο υπολογιστικό κόστος. Πρόκειται για το υπολογιστικό κόστος της επεξεργασίας και της αποστολής των μηνυμάτων μεταξύ των υπηρεσιών, όπως επίσης και το υπολογιστικό κόστος που προκύπτει από τις αυξημένες ανάγκες ασφάλειας οι οποίες πρέπει να συνεκτιμηθούν πριν τη μετάβαση στη SOA αρχιτεκτονική [9]. 1.5 Η Έννοια της Υπηρεσίας Η βασική έννοια στην οποία στηρίζεται η SOA αρχιτεκτονική είναι οι υπηρεσίες. Η υπηρεσία είναι μία διακριτή μονάδα επιχειρησιακής λειτουργικότητας η οποία γίνεται διαθέσιμη μέσω ενός συμβολαίου υπηρεσίας. Το συμβόλαιο της υπηρεσίας καθορίζει όλες τις αλληλεπιδράσεις μεταξύ του καταναλωτή και του παρόχου της υπηρεσίας: Διεπαφή της υπηρεσίας. Η διεπαφή της υπηρεσίας προσδιορίζει τις λειτουργίες της υπηρεσίας, τα δεδομένα εισόδου και εξόδου των λειτουργιών της υπηρεσίας και τα πρωτόκολλα επικοινωνίας μεταξύ των λειτουργιών της

22 υπηρεσίας. Για παράδειγμα μία υπηρεσία πελάτη μπορεί να περιέχει λειτουργίες όπως η αναζήτηση πελατών, τα στοιχεία πελάτη, η καταχώρηση νέου πελάτη, η διαγραφή ενός πελάτη, η αλλαγή των στοιχείων ενός πελάτη. Υλοποίηση της υπηρεσίας. Αφορά τον τρόπο με τον οποίο η υπηρεσία παρέχει τις δυνατότητες που προδιαγράφει η σύνδεση της. Η υλοποίηση μπορεί να βασίζεται σε υπάρχουσες εφαρμογές, σε άλλες υπηρεσίες, σε κώδικα γραμμένο ειδικά για τη συγκεκριμένη υπηρεσία ή σε ένα συνδυασμό των παραπάνω περιπτώσεων. Ο χρήστης της υπηρεσίας μπορεί να δει τον τρόπο που λειτουργεί η υπηρεσία, όμως δεν μπορεί να δει τον τρόπο που υλοποιείται. Ο πάροχος όμως της υπηρεσίας μπορεί οποιαδήποτε στιγμή να αλλάξει τον τρόπο υλοποίησης της υπηρεσίας, εφόσον δεν επηρεάζεται η διεπαφή ή δεν αλλοιώνεται ο χαρακτήρας της υπηρεσίας. Ποιότητα και απόδοση υπηρεσίας. Η διαχείριση της ποιότητας και της απόδοσης της υπηρεσίας πραγματοποιείται με μία συμφωνία στο επίπεδο της υπηρεσίας (Service Level Agreement - SLA). Η συμφωνία αυτή είναι διαφορετική από χρήστη σε χρήστη. Για παράδειγμα αν κάποιος χρήστης καλεί την υπηρεσία φορές καθημερινά, μεταξύ 08:00 και 09:00, ο κάτοχος της υπηρεσίας θα πρέπει να έχει επιστρατεύσει τους κατάλληλους πόρους σε υλικό (hardware) και λογισμικό (software) για να μπορέσει να ικανοποιήσει την ανάγκη αυτή. Αξίζει να αναφερθεί ότι ο κύκλος ζωής (life cycle) της υπηρεσίας (δηλαδή η επαναλαμβανόμενη μεταβολή της υπηρεσίας με την πάροδο του χρόνου) αποτελείται από το σχεδιασμό, την υλοποίηση, την εγκατάσταση και τη συντήρηση της υπηρεσίας [1] Χαρακτηριστικά Υπηρεσιών Τα χαρακτηριστικά τα οποία κατά κοινή ομολογία διαθέτει μια «καλή» υπηρεσία είναι τα εξής: Αρθρωτή επεκτασιμότητα και διακριτότητα. Μία υπηρεσία πρέπει να είναι εφικτό να επαναχρησιμοποιηθεί στα πλαίσια μίας άλλης υπηρεσίας ή απευθείας από μία επιχειρησιακή διαδικασία. Επιπρόσθετα μια υπηρεσία πρέπει να έχει έναν ικανοποιητικό βαθμό πληρότητας όσον αφορά την

23 επιχειρησιακή λειτουργία που πρέπει να καλύψει. Επίσης είναι άξιο αναφοράς ότι μία υπηρεσία πρέπει να προσφέρει γενικές και όχι ειδικές λειτουργίες έτσι ώστε να περιορίζεται το πλήθος των κλήσεων που πρέπει να κάνει ο χρήστης της υπηρεσίας για να ικανοποιήσει τις ανάγκες του, καθώς κάθε κλήση κοστίζει. Ενθυλάκωση (Encapsulation). Η ενθυλάκωση έχει να κάνει με το διαχωρισμό της διεπαφής της υπηρεσίας από τον τρόπο υλοποίησης της υπηρεσίας. Η ενθυλάκωση «κρύβει» τις λεπτομέρειες υλοποίησης της υπηρεσίας οι οποίες έχουν να κάνουν με τους αλγορίθμους και τη δομή των δεδομένα που χρησιμοποιεί [1]. Χαλαρή σύζευξη. Στόχος της χαλαρής σύζευξης είναι η ελαχιστοποίηση των εξαρτήσεων μεταξύ του χρήστη και του παρόχου της υπηρεσίας και η κάλυψη των απαιτήσεων για επεκτασιμότητα, ευελιξία και ανοχή σφαλμάτων. Η χαλαρή σύζευξη απαντάται σε διάφορες μορφές, οι κυριότερες εκ των οποίων είναι και οι εξής: 1. Ασύγχρονος τρόπος επικοινωνίας. Μπορεί να πραγματοποιηθεί με χρήση ουρών. Βασικό του χαρακτηριστικό είναι ότι ο αποστολέας και ο παραλήπτης του μηνύματος δεν είναι συγχρονισμένοι. Έτσι ο χρήστης της υπηρεσίας δεν είναι υποχρεωμένος να περιμένει μένοντας αδρανής μέχρι να πάρει απάντηση από την υπηρεσία. 2. Ετερογενείς τύποι δεδομένων. Η διατήρηση διαφορετικών δεδομένων από κάθε σύστημα οδηγεί σε μία πιο χαλαρή σύζευξη των υπηρεσιών. Στην αντίθετη περίπτωση θα πρέπει να υπάρχει ένα κοινό σχήμα δεδομένων το οποίο θα πρέπει υποχρεωτικά να εφαρμόζεται από όλα τα συστήματα ενός οργανισμού. Έτσι οι υπηρεσίας καταλήγουν να εξαρτώνται από το κοινό σχήμα δεδομένων. Όποια υπηρεσία δεν το χρησιμοποιεί, δεν μπορεί να λειτουργήσει. 3. Μεσολαβητές (Mediators). Όταν ο χρήστης εντοπίζει μια υπηρεσία χρησιμοποιώντας τη διεύθυνση της στο δίκτυο, τότε δεν επιτυγχάνεται χαλαρή σύζευξη ως προς τον τρόπο κλήσης της υπηρεσίας, καθώς σε περίπτωση που αλλάξει η διεύθυνση της υπηρεσίας ο κώδικας που καλεί την υπηρεσία θα σταματήσει να λειτουργεί. Χαλαρή σύζευξη επιτυγχάνεται όταν χρησιμοποιείται ένας μεσολαβητής (mediator) στον οποίο αποδίδεται μία συμβολική λέξη οι οποία αντιστοιχεί στην υπηρεσία

24 Στη συνέχεια ο μεσολαβητής αναλαμβάνει τη σύνδεση με την υπηρεσία. Επίσης είναι άξιο αναφοράς ότι ο μεσολαβητής μπορεί να προσφέρει υπηρεσίες εξισορρόπησης φόρτου,. Αυτό συμβαίνει για παράδειγμα σε περίπτωση που η υπηρεσία είναι εκτός λειτουργίας, οπότε ο μεσολαβητής μεταφέρει το χρήστη σε μία εφεδρική υπηρεσία. 4. «Αδύναμοι» τύποι δεδομένων. Όταν η δομή των δεδομένων εισόδου και εξόδου προσδιορίζεται με σαφήνεια στη διεπαφή της υπηρεσίας τότε δημιουργείται μία εξάρτηση μεταξύ του χρήστη και της υπηρεσίας, καθώς σε περίπτωση αλλαγής της εισόδου ή της εξόδου θα πρέπει να αλλάξει και ο τρόπος κλήσης από την πλευρά του χρήστη. Αυτό συμβαίνει κυρίως όταν τα συστήματα επεκτείνονται. Ο έλεγχος των τύπων (με τη χρήση γλωσσών προγραμματισμού που προσφέρουν τη δυνατότητα αυτή) είναι χρονοβόρος και απαιτεί πολλές πληροφορίες. Έτσι χρησιμοποιούνται αδύναμοι τύποι δεδομένων (π.χ. συλλογές από συμβολοσειρές) [8]. Αυτονομία. Μία υπηρεσία πρέπει να αναπτύσσεται να τροποποιείται και να συντηρείται ανεξάρτητα από τις άλλες υπηρεσίες. Δηλαδή πρέπει να έχει αυτόνομο κύκλο ζωής σε σχέση με τις υπόλοιπες υπηρεσίες. Επαναχρησιμοποίηση. Μία υπηρεσία πρέπει να είναι εφικτό να χρησιμοποιηθεί σε πολλές επιχειρησιακές διαδικασίες. Δηλαδή πρέπει να κατασκευαστεί με τέτοιο τρόπο ώστε να μπορεί να χρησιμοποιηθεί ως δομική μονάδα άλλων σύνθετων υπηρεσιών ή διαδικασιών. Δυναμική αναζήτηση και σύνδεση. Η δυναμική αναζήτηση των υπηρεσιών κατά τη σχεδίαση, μπορεί να γίνει με τη χρήση ενός αποθετηρίου υπηρεσιών. Έλλειψη διατήρησης κατάστασης (Stateless). Οι υπηρεσίες δε διατηρούν κάποια πληροφορία μεταξύ δύο ή περισσότερων κλήσεων τους. Οι υπηρεσίες δεν εξαρτώνται από το περιεχόμενο ή την κατάσταση άλλων υπηρεσιών, παρά μόνο από τη λειτουργικότητα τους. Αυτό-περιγραφή. Οι πληροφορίες που είναι απαραίτητες για τη χρήση της υπηρεσίας (λειτουργίες, δεδομένα εισόδου-εξόδου και τυχόν άλλες προϋποθέσεις) πρέπει να υπάρχουν στο συμβόλαιο της υπηρεσίας. Ανεξαρτησία από πρωτόκολλα, τοποθεσίας και γλώσσα. Οι υπηρεσίες θα πρέπει να είναι προσβάσιμες από κάθε εξουσιοδοτημένο χρήστη ανεξαρτήτως πλατφόρμας ή τοποθεσίας

25 Πολιτική διαχείρισης. Η σχέση μεταξύ των χρηστών και των παρόχων της υπηρεσίας θα πρέπει να ελέγχεται από πολιτικές και συμφωνίες στο επίπεδο της υπηρεσίας (Service Level Agreements - SLAs) [1]. 1.6 Στοιχεία SOA Αρχιτεκτονικής Η SOA αποτελεί ένα αρχιτεκτονικό στυλ για τη δημιουργία επιχειρησιακών λύσεων με βάση τις υπηρεσίες και σχετίζεται με την κατασκευή ανεξάρτητων υπηρεσιών (με βάση τις ανάγκες μίας επιχείρησης) οι οποίες μπορούν να συνδυαστούν με σημαντικές, υψηλού επιπέδου επιχειρησιακές διαδικασίες και λύσεις, στα πλαίσια της επιχείρησης. Στα πλαίσια της SOA είναι εφικτό να συνδυαστούν επαναχρησιμοποιήσιμες (reusable) υπηρεσίες και να δημιουργηθούν νέες ευκίνητες και ευέλικτες επιχειρησιακές διαδικασίες. Έτσι ένα μέρος της υπηρεσιοστραφούς αρχιτεκτονικής αναλώνεται στη δημιουργία των απαραίτητων συνθηκών με στόχο τη δημιουργία και τη χρήση συναρμολογήσιμων (composable) υπηρεσιών σε ολόκληρη την επιχείρηση. Η SOA προσφέρει τη δυνατότητα στους διάφορους οργανισμούς να υλοποιήσουν υπηρεσίες οι οποίες καλύπτουν τις άμεσες ανάγκες τους και είναι εφικτό να συνδυαστούν με υψηλότερου επιπέδου επιχειρησιακές διαδικασίες και επιχειρησιακές λύσεις, υπό τις εξής προϋποθέσεις: Οι υπηρεσίες πρέπει να καταλαμβάνουν παρόμοιο όγκο, να έχουν παρόμοια δομή και να έχουν παρόμοιο τρόπο λειτουργίας. Οι υπηρεσίες πρέπει να συμμορφώνονται με τα πρότυπα των επιχειρήσεων. Οι υπηρεσίες πρέπει να επικοινωνούν σε τεχνικό επίπεδο. Οι υπηρεσίες πρέπει να επικοινωνούν σε σημασιολογικό επίπεδο. Οι υπηρεσίες δεν πρέπει να παρουσιάζουν ελλείψεις, ούτε επικαλύψεις αρμοδιοτήτων [1]. Τα σημαντικότερα μέρη της Υπηρεσιοστραφούς Αρχιτεκτονικής (Service- Oriented Architecture - SOA) είναι: Διαδικασίες. Υψηλού επιπέδου επιχειρησιακές λειτουργίες που περιλαμβάνονται σε εφαρμογές ή LOBs (Line of Businesses)

26 Υπηρεσίες. Αρθρωτές μονάδες που αφορούν τη λειτουργικότητα των επιχειρήσεων. Ενσωμάτωση. Σύνδεση και έκθεση των υφιστάμενων εφαρμογών και/ή των δεδομένων, ως υπηρεσίες. Υπάρχοντα συστήματα. Τα υπάρχοντα παλαιού τύπου συστήματα, οι έτοιμες εμπορικές (commercial of the self COTS) εφαρμογές και τα δεδομένα που θέλει η επιχείρηση να ελέγξει. Έγγραφα. Υψηλού επιπέδου μονάδες των επιχειρησιακών πληροφοριών όπως μία εντολή αγοράς ή ένα έγγραφο EDI (Electronic Data Interchange). Σημασιολογία. Το βαθύτερο νόημα των πληροφοριών που ανταλλάσσεται στις επιμέρους διαδικασίες. Μετασχηματισμός. Η μετατροπή των πληροφοριών από μία μορφή ή από μία σημασιολογία σε μία άλλη. Επικοινωνία. Η ικανότητα των υπηρεσιών να επικοινωνούν μεταξύ τους [1]. Στο σχήμα που ακολουθεί απεικονίζεται μία διαστρωματωμένη (layered) αρχιτεκτονική SOA όπου συμπεριλαμβάνονται δύο σημαντικές έννοιες για κάθε επίπεδο. Εικόνα 2 Αρχιτεκτονικά Στοιχεία της SOA [1]

27 Στα αριστερά εμφανίζονται λειτουργικές έννοιες οι οποίες χρησιμοποιούνται για την κατασκευή συστημάτων και διαδικασιών. Στα δεξιά εμφανίζονται πληροφοριακές έννοιες οι οποίες χρησιμοποιούνται για τη διάδοση, περιγραφή ή διαχείριση των δεδομένων στα διάφορα λειτουργικά επίπεδα. Η SOA επικεντρώνεται μόνο στις λειτουργικές πτυχές αγνοώντας σημαντικές έννοιες δεδομένων. Οι διεπαφές μεταξύ των επιπέδων αντιπροσωπεύουν τις σχέσεις μεταξύ των λειτουργιών. Τα επίπεδα (από κάτω προς τα πάνω) είναι: Πόροι επιχείρησης και λειτουργικά συστήματα. Το επίπεδο αυτό αποτελείται από τις υπάρχουσες εφαρμογές, από παλαιού τύπου συστήματα και από έτοιμα εμπορικά (commercial of the self COTS) συστήματα συμπεριλαμβανομένων των CRM (Customer Relationship Management Διαχείριση Πελατειακών Σχέσεων) και ERP (Enterprise Resource Planning Σχεδιασμός Επιχειρησιακών Πόρων) πακέτων εφαρμογών και από άλλες παλαιότερες αντικειμενοστραφείς (object-oriented) υλοποιήσεις. Οι εφαρμογές αυτές παρέχουν επιχειρησιακές λειτουργίες, δηλαδή συναλλαγές που αναπαριστούν ενιαίες λογικές μονάδες εργασίας στα λειτουργικά συστήματα της επιχείρησης. Η εκτέλεση μίας λειτουργίας θα προκαλέσει τυπικά την ανάγνωση, γραφή ή τροποποίηση ενός η περισσότερων αρχείων δεδομένων στο σύστημα εγγραφής (System of Record SOR). Οι υπηρεσίες έχουν ένα συγκεκριμένο, δομημένο περιβάλλον και παρέχουν δομημένες αποκρίσεις. Τα δεδομένα του επιπέδου αυτού βρίσκονται στις υπάρχουσες εφαρμογές ή στις υπάρχουσες βάσεις δεδομένων. Υπηρεσίες ενσωμάτωσης. Οι υπηρεσίες ενσωμάτωσης παρέχουν τη δυνατότητα ενσωμάτωσης και πρόσβασης στις υπάρχουσες εφαρμογές. Ο διαχωρισμός μεταξύ των υπηρεσιών ενσωμάτωσης και των επιχειρησιακών υπηρεσιών είναι ιδιαίτερα κρίσιμος για τη διατήρηση ενός ευέλικτου επιχειρησιακού περιβάλλοντος. Αυτός ο διαχωρισμός περιλαμβάνει συχνά τη μετατροπή δεδομένων και λειτουργιών από αυτό που είναι επιθυμητό στο επίπεδο των επιχειρησιακών υπηρεσιών σε αυτό που είναι πραγματικά εφικτό στα υπάρχοντα συστήματα [1]. Επιχειρησιακές υπηρεσίες. Οι επιχειρησιακές υπηρεσίες παρέχουν λειτουργικότητα υψηλού επιπέδου σε ολόκληρη την επιχείρηση. Το επίπεδο αυτό παρέχει την αφαίρεση της διεπαφής της υπηρεσίας και την ενσωμάτωση

28 του από κάτω στρώματος, σπάζοντας με αυτό τον τρόπο την άμεση εξάρτηση μεταξύ των διαδικασιών και των υπαρχόντων συστημάτων. Οι υπηρεσίες αποτελούν διαχειριζόμενα και ρυθμιζόμενα σύνολα στοιχείων της επιχείρησης τα οποία είναι υπεύθυνα για την εξασφάλιση της τήρησης των συμφωνιών στο επίπεδο της υπηρεσίας (Service Level Agreements SLAs). Οι επιχειρησιακές υπηρεσίες προσφέρουν αρκετές δυνατότητες μέσω της λογικής ομαδοποίησης των δραστηριοτήτων. Για παράδειγμα αν θεωρηθούν τα χαρακτηριστικά των πελατών ως υπηρεσία, τότε αυτή η υπηρεσία είναι πιθανό να περιλαμβάνει αναζήτηση πελατών με βάση τον τηλεφωνικό τους αριθμό, καταχώρηση πελατών με βάση το όνομα τους και αποθήκευση των δεδομένων των νέων πελατών. Οι δραστηριότητες αυτές δεν είναι απαραίτητο να προέρχονται από τα ίδια λειτουργικά συστήματα και είναι πιθανό να πρέπει να επαναληφθούν σε πολλά παρόμοια συστήματα. Όπως γίνεται αντιληπτό οι επιχειρησιακές υπηρεσίες παρέχουν μία εικονική υλοποίηση των επιμέρους επιχειρησιακών δραστηριοτήτων. Οι επιχειρησιακές υπηρεσίες λειτουργούν με σημασιολογικά αντικείμενα δεδομένων, δηλαδή εικονικά δεδομένα που περιγράφουν τις πληροφορίες που πρέπει να κοινοποιηθούν ή να διαβιβαστούν μεταξύ των υπηρεσιών. Επιχειρησιακές διαδικασίες. Μία επιχειρησιακή διαδικασία αποτελείται από μία σειρά λειτουργιών οι οποίες εκτελούνται σε μία διατεταγμένη σειρά σύμφωνα με ένα σύνολο επιχειρησιακών κανόνων. Η επιχειρησιακή διαδικασία περιγράφεται συχνά από ένα κατάλληλο μοντέλο το οποίο καλείται μοντέλο επιχειρησιακής διαδικασίας (Business Process Model BPM). Το μοντέλο αυτό εκτελείται από ένα εξειδικευμένο σύστημα διαχείρισης της επιχειρησιακής διαδικασίας (Business Process Management System - BPMS). Η ταξινόμηση, η επιλογή και η εκτέλεση των διαδικασιών καλείται orchestration. Οι επιχειρησιακές διαδικασίες παρέχουν μακροχρόνια σύνολα δράσεων ή δραστηριοτήτων. Αποτελούνται από επιχειρησιακές υπηρεσίες και περιλαμβάνουν την επίκληση πολλαπλών υπηρεσιών. Επίσης οι επιχειρησιακές διαδικασίες λειτουργούν σε συνδυασμό με τα επιχειρησιακά έγγραφα. Οι διαδικασίες και τα έγγραφα αποτελούνται από υπηρεσίες και αντικείμενα του κατώτερου επιπέδου σύμφωνα με το BPM και ένα κοινό μοντέλο σημασιολογικών δεδομένων. Το πεδίο εφαρμογής των διαδικασιών αυτών είναι συνήθως ολόκληρη η επιχείρηση. Χαρακτηριστικά παραδείγματα

29 επιχειρησιακών διαδικασιών είναι η πώληση προϊόντων ή υπηρεσιών και η ολοκλήρωση παραγγελιών [1]. Οι παραπάνω έννοιες παρέχουν αξία στην επιχείρηση για τους εξής λόγους: Παρέχουν ένα ενιαίο και σταθερό χώρο μέσο του οποίου είναι εφικτή η πρόσβαση στα δεδομένα ή η διεξαγωγή των επιχειρησιακών λειτουργιών. Απομονώνουν και παρουσιάζουν τα δεδομένα και τις λειτουργίες των εφαρμογών. Κατασκευάζουν επαναχρησιμοποιήσιμες (reusable) δομικές μονάδες οι οποίες είναι εφικτό να συνδυαστούν μεταξύ τους για την κατασκευή επιχειρησιακών διαδικασιών. Στην εικόνα που ακολουθεί παρουσιάζεται μία SOA επιχειρησιακή προοπτική: Εικόνα 3 SOA επιχειρησιακή προοπτική [1]. Η SOA πρέπει να περιγράψει τις ακόλουθες πτυχές των υπηρεσιών μίας επιχείρησης: Τον ορισμό, την ποικιλία και τα επιμέρους είδη των υπηρεσιών. Τον τρόπο κατασκευής και χρήσης των υπηρεσιών. Τον τρόπο που τα τυποποιημένα και τα υπάρχοντα συστήματα ενσωματώνονται στο περιβάλλον των υπηρεσιών. Τον τρόπο που οι υπηρεσίες συνδυάζονται στις διαδικασίες. Τον τρόπο που επικοινωνούν οι υπηρεσίες σε τεχνικό επίπεδο, δηλαδή πως συνδέονται μεταξύ τους και πως διαβιβάζουν τις πληροφορίες. Τον τρόπο που διαλειτουργούν οι υπηρεσίες σε σημασιολογικό επίπεδο, δηλαδή πως κοινοποιούν έννοιες σχετικές με τις πληροφορίες

30 Τον τρόπο που οι υπηρεσίες συμμορφώνονται με τη στρατηγική και τους στόχους των επιχειρήσεων. Τον τρόπο χρήσης της αρχιτεκτονικής [1]. 1.7 SOA Αρχιτεκτονική Αναφοράς Η δημιουργία και η διατήρηση μίας αρχιτεκτονικής αναφοράς αποτελεί μία σημαντική και ταυτόχρονα δύσκολη πρακτική για τη SOA. Η αρχιτεκτονική αναφοράς είναι ένας ιδιαίτερα κρίσιμος παράγοντας ο οποίος καθορίζει την επιτυχία των στόχων της SOA. Στην εικόνα που ακολουθεί παρουσιάζονται τα βασικά χαρακτηριστικά μίας SOA αρχιτεκτονικής αναφοράς. Εικόνα 4 Πτυχές μίας SOA αρχιτεκτονικής αναφοράς [1]. Η αρχιτεκτονική αναφοράς αντιπροσωπεύει ένα πιο επίσημο ορισμό της αρχιτεκτονικής ο οποίος μπορεί να χρησιμοποιηθεί για την αντικειμενική επαλήθευση των υπηρεσιών και των εφαρμογών. Μία SOA αρχιτεκτονική αναφοράς πρέπει: Να υποστηρίζει τις βασικές έννοιες των επιχειρήσεων όπως είναι οι επιμέρους αρχιτεκτονικές των επιχειρήσεων, οι πληροφορίες, οι εφαρμογές και η τεχνολογία. Να καθορίζει την ιεραρχία και την ταξινόμηση των υπηρεσιών και των επιμέρους τύπων των υπηρεσιών. Να δρα σαν μία πύλη (portal) και να ορίζει τον τρόπο ένταξης των υπηρεσιών σε μία συνολική επιχειρησιακή εφαρμογή

31 Να διαχωρίζει τις έννοιες των επιχειρήσεων, των εφαρμογών και της τεχνολογίας. Να είναι εφικτό να ενσωματωθεί στην αναπτυξιακή διαδικασία. Η SOA αρχιτεκτονική αναφοράς έχει επίσης ως αποστολή την εκπλήρωση των παρακάτω στόχων: Να παρέχει μία «κοινή γλώσσα» επικοινωνίας για τις υπηρεσίες και τη SOA. Να παρέχει συνέπεια υλοποίησης, επιχειρησιακούς στόχους και σημασιολογία σε όλες τις υπηρεσίες. Να παρέχει μία μεθοδολογία σχεδιασμού που βασίζεται στην αρχιτεκτονική. Να υποστηρίζει SOA διαχείριση. Να υποστηρίζει επιχειρησιακές αρχιτεκτονικές (Enterprise Architectures ΕΑ). Να ορίζει τον τρόπο χρήσης της αρχιτεκτονικής αναφοράς [1]. Αναλυτικότερα, το εννοιολογικό περιεχόμενο μίας SOA αρχιτεκτονικής αναφοράς περιλαμβάνει: Μεταμοντέλο (Metamodel) υπηρεσίας Εκεί ορίζονται η έννοια, τα χαρακτηριστικά και οι λεπτομέρειες μίας υπηρεσίας, καθώς και ο τρόπος με τον οποίο συνδέονται οι υπηρεσίες με άλλα μέρη της αρχιτεκτονικής. Πιο συγκεκριμένα εκεί ορίζεται ο τύπος της υπηρεσίας (π.χ. επιχειρησιακή, κοινωφελής, εσωτερική, εξωτερική, θεμελιώδης) και οι διαστάσεις της υπηρεσίας. Προοπτικές Επιχειρησιακής Αρχιτεκτονικής (Enterprise Architecture) Η Επιχειρησιακή Αρχιτεκτονική αποτελείται από τα παρακάτω βασικά πεδία: Επιχειρησιακό μεταμοντέλο (metamodel). Ορίζει τις έννοιες που χρησιμοποιούνται για την περιγραφή της επιχειρησιακής αρχιτεκτονικής. Επίσης ορίζεται η σχέση μεταξύ παραδοσιακών επιχειρησιακών αρχιτεκτονικών εννοιών (π.χ. στρατηγική, στόχοι, αποτελέσματα, οργάνωση, διεργασίες, πλαίσια, αλυσίδα αξιών) και των υπηρεσιοστραφών συστημάτων

32 Πληροφοριακό μεταμοντέλο (metamodel). Ορίζει τις έννοιες που χρησιμοποιούνται για το χαρακτηρισμό της αρχιτεκτονικής της πληροφορίας όπως είναι τα σημασιολογικά και φυσικά δεδομένα, καθώς και τα δεδομένα πεδίου. Επίσης ορίζει τη σχέση μεταξύ παραδοσιακών πληροφοριακών αρχιτεκτονικών εννοιών και των υπηρεσιοστραφών συστημάτων. Μεταμοντέλο (metamodel) εφαρμογών. Εδώ ορίζονται οι έννοιες που χρησιμοποιούνται για το χαρακτηρισμό της αρχιτεκτονικής των εφαρμογών. Επίσης ορίζεται η σχέση μεταξύ παραδοσιακών εννοιών της αρχιτεκτονικής εφαρμογών και των υπηρεσιοστραφών συστημάτων. Για παράδειγμα περιγράφεται ο τρόπος που χρησιμοποιούνται οι υπηρεσίες σε μία αρχιτεκτονική n-βαθμίδων. Τεχνολογικό μεταμοντέλο (metamodel). Εδώ ορίζονται οι έννοιες που χρησιμοποιούνται για το χαρακτηρισμό της αρχιτεκτονικής της τεχνολογίας. Επίσης ορίζεται η σχέση μεταξύ των παραδοσιακών εννοιών της αρχιτεκτονικής της τεχνολογίας και των υπηρεσιοστραφών συστημάτων. Για παράδειγμα ορίζεται ο τρόπος που συγκεκριμένες πλατφόρμες και δίκτυα υποστηρίζουν συμφωνίες στο επίπεδο των υπηρεσιών (Service Level Agreements SLAs) για ποιοτική παροχή υπηρεσιών [1]. Εικόνα 5 SOA αρχιτεκτονική αναφοράς [1]. MBD (Model Based Development) προοπτικές

33 Υποστηρίζει MBD προσεγγίσεις με συγκεκριμένο προφίλ. Τα MBD προφίλ σχετίζονται με τα αρχιτεκτονικά μεταμοντέλα (metamodels) και παρέχουν ένα μηχανισμό για την ενσωμάτωση του μεταμοντέλου σε ένα τυπικό εργαλείο μοντελοποίησης και παραγωγής. Επιχειρησιακό Προφίλ. Ορίζει τις έννοιες που χρησιμοποιούνται για την περιγραφή ενός επιχειρησιακού προβλήματος με μη τεχνικούς όρους. Επιπλέον καθορίζει τις σχέσεις μεταξύ εννοιών, κανόνων και περιορισμών. Προφίλ Εφαρμογών. Ορίζει τη λογική δομή των εφαρμογών από την άποψη των επιπέδων, των βαθμίδων και των αρχιτεκτονικών στοιχείων. Επίσης ορίζει του «που» και το «πως» ταιριάζουν οι υπηρεσίες στη συνολική δομή της εφαρμογής. Προφίλ πλατφόρμας. Ένα προφίλ πλατφόρμας ορίζει τις λεπτομέρειες της τεχνολογικής πλατφόρμας που πρόκειται να χρησιμοποιηθούν κατά τη διαδικασία της υλοποίησης. Συνήθως υπάρχουν πολλά διαφορετικά μεταμοντέλα τεχνολογικής πλατφόρμας για την υποστήριξη διαφορετικών τεχνολογιών (π.χ..net, Java, ESB). Μετασχηματισμοί. Ορίζει τον τρόπο που μετασχηματίζονται οι έννοιες ενός μοντέλου στις έννοιες ενός άλλου μοντέλου και την ικανότητα ανίχνευσης των επιμέρους στοιχείων των δύο μοντέλων [1]. Μεταμοντέλο (Metamodel) διαδικασίας Καθορίζει μία διαδικασία για το σχεδιασμό και την υλοποίηση των υπηρεσιών ξεκινώντας από το επιχειρησιακό επίπεδο, προχωρώντας μέσω του σχεδιασμού της υπηρεσίας και καταλήγοντας στην υλοποίηση μίας συγκεκριμένης πλατφόρμας. Επίσης ορίζει τη ροή της συνολικής εργασίας τους στόχους και τις ανησυχίες κάθε επιμέρους βήματος της διαδικασίας, τα στοιχεία του μεταμοντέλου που περιλαμβάνονται σε κάθε επιμέρους βήμα, τα παραγόμενα προϊόντα και τις μετρικές. Μεταμοντέλο (Metamodel) διαχείρισης Ορίζει τις θεμελιώδεις έννοιες διαχείρισης, τα στοιχεία των μεταμοντέλων που χρησιμοποιούνται σε κάθε μία από αυτές, τους συσχετισμούς και τους περιορισμούς. Επίσης ορίζει τον τρόπο που το μεταμοντέλο διαχείρισης αλληλεπιδρά με τα υπόλοιπα τμήματα της αρχιτεκτονικής αναφοράς κατά το χρονικό διάστημα της σχεδίασης και κατά το χρονικό διάστημα της εκτέλεσης

34 Μοντέλο αρχιτεκτονικών συσχετισμών Ορίζει τον τρόπο συσχέτισης όλων των διαφορετικών πτυχών μίας αρχιτεκτονικής αναφοράς, καθώς και τον τρόπο συσχέτισης με άλλα κοινά αρχιτεκτονικά πλαίσια όπως η επιχειρησιακή αρχιτεκτονική (Enterprise Architecture EA) και η αρχιτεκτονική λογισμικού (Software Architecture). Μοντέλο χρήσης της αρχιτεκτονικής Περιγράφει τον τρόπο χρήσης της αρχιτεκτονικής αναφοράς. Στο σημείο αυτό αξίζει να αναφερθεί ότι τα παραπάνω ζητήματα πρέπει να αντιμετωπιστούν κατά την ανάπτυξη SOA επιχειρησιακών λύσεων. Η αρχιτεκτονική αναφοράς παρέχει ένα μηχανισμό που διασφαλίζει τη βελτιστοποίηση των συσχετισμών μεταξύ όλων των παραπάνω επιμέρους πτυχών αλλά και το ότι όλες οι επιμέρους πτυχές συλλειτουργούν και υποστηρίζουν τους στόχους του οργανισμού [1]. 1.8 Μοντελοποίηση SOA Αρχιτεκτονικών Οι SOA αρχιτεκτονικές είναι εφικτό να μοντελοποιηθούν με κατάλληλη χρήση UML (Unified Modeling Language Ενιαία Γλώσσα Μοντελοποίησης) διαγραμμάτων και κατάλληλη χρήση των κανόνων μετασχηματισμού γραφημάτων. Η μοντελοποίηση αυτή βασίζεται στον ορισμό ενός στατικού και ενός δυναμικού μέρους. Το στατικό μέρος καθορίζει τους τύπους των εξαρτημάτων και των συνδέσεων και τους περιορισμούς για τη διασύνδεση αυτών των στοιχείων. Το δυναμικό μέρος καθορίζει τον τρόπο που μία συγκεκριμένη αρχιτεκτονική εξελίσσεται εξαιτίας της εισαγωγής νέων προγραμματισμένων ρυθμίσεων ή απρόβλεπτων αλλαγών [2] Στατικό Μοντέλο Το στατικό μέρος της SOA αρχιτεκτονικής μοντελοποιείται με τη βοήθεια κατάλληλων UML διαγραμμάτων κλάσεων. Οι κλάσεις αυτές αντιπροσωπεύουν τρία διαφορετικά είδη στοιχείων, τα οποία ομαδοποιούνται σε τρία πακέτα:

35 Τα δομικά στοιχεία όπως είναι τα εξαρτήματα και οι υπηρεσίες, τα οποία ομαδοποιούνται στο πακέτο της δομής. Τα έγγραφα των προδιαγραφών για την περιγραφή των υπηρεσιών και των απαιτήσεων, τα οποία ομαδοποιούνται στο πακέτο των προδιαγραφών. Τα μηνύματα για τη μοντελοποίηση της επικοινωνίας, τα οποία ομαδοποιούνται στο πακέτο των μηνυμάτων. «Πακέτο» Δομής ( Package Structure) Το πακέτο της δομής περιλαμβάνει τις κλάσεις που αποτελούν τον πυρήνα της αρχιτεκτονικής. Στις υπηρεσιοστραφείς αρχιτεκτονικές η υπηρεσία αποτελεί ειδικό εξάρτημα το οποίο έχει ως στόχο να παρουσιάσει τη λειτουργικότητα του σε άλλες υπηρεσίες και εξαρτήματα. Με βάση την έννοια της αρχιτεκτονικής σύνδεσης, μία συνεδρία (session) χρησιμοποιείται για να συνδεθεί ένα εξάρτημα σε μία υπηρεσία, αφού αποθηκεύει την τρέχουσα κατάσταση μεταξύ του αιτούντος (για χρήση της υπηρεσίας) και της υπηρεσίας. Επίσης είναι άξιο αναφοράς ότι από τη στιγμή που μία υπηρεσία αποτελεί υποκατηγορία των εξαρτημάτων, μία υπηρεσία είναι εφικτό να συνδεθεί σε μία άλλη υπηρεσία μέσω μίας συνεδρίας (session). Σε μία υπηρεσιοστραφή αρχιτεκτονική οι φορείς ανίχνευσης παρέχουν υπηρεσίες ανίχνευσης (discovery services) οι οποίες είναι ειδικές υπηρεσίες για την αναζήτηση σε ένα κατάλογο υπηρεσιών [2]. Εικόνα 6 Το πακέτο των δομικών στοιχείων [2]. «Πακέτο» Προδιαγραφών ( Package Specification)

36 Το πακέτο των προδιαγραφών προσθέτει τα έγγραφα των προδιαγραφών στο στατικό μοντέλο. Τα έγγραφα αυτά είναι απαραίτητα για την περιγραφή των δραστηριοτήτων αναδιαμόρφωσης οι οποίες πραγματοποιούν δυναμική αναζήτηση ενός εξαρτήματος για την κάλυψη ορισμένων απαιτήσεων κατά το χρόνο εκτέλεσης. Το πακέτο αυτό ορίζει δύο τύπους εγγράφων προδιαγραφών, τις απαιτήσεις (requirements) και τις προδιαγραφές της υπηρεσίας (service specifications). Τα δύο αυτά έγγραφα περιέχουν μία σειρά από ιδιότητες (properties) οι οποίες προέρχονται από την υπερκλάση (superclass) του έγγραφου προδιαγραφών (specification document). Στην περίπτωση ενός εγγράφου απαιτήσεων, οι ιδιότητες αυτές είναι απαραίτητες για ένα εξάρτημα όταν θέλει να χρησιμοποιήσει μία υπηρεσία. Στην περίπτωση των προδιαγραφών των υπηρεσιών οι οποίες περιγράφουν μία συγκεκριμένη υπηρεσία, οι ιδιότητες αυτές διασφαλίζονται από τον πάροχο της υπηρεσίας. Σε ορισμένες περιπτώσεις αυτό καθίσταται εφικτό μόνο υπό ορισμένες παραδοχές οι οποίες λειτουργούν ως σύνδεσμος μεταξύ της αντίστοιχης ιδιότητας και των περαιτέρω απαιτήσεων. Εφόσον εγκαθιδρυθεί με επιτυχία μία συνεδρία που αφορά τις απαιτήσεις, το γεγονός αυτό σημειώνεται με ένα σύνδεσμο «επιτυχίας» στη συνεδρία [2]. Εικόνα 7 Το πακέτο για τα έγγραφα των προδιαγραφών [2]. «Πακέτο» Μηνυμάτων ( Package Messages)

37 Τα εξαρτήματα και οι υπηρεσίες είναι χαλαρά συνδεδεμένα σε μία SOA αρχιτεκτονική με αποτέλεσμα να αλληλεπιδρούν ανταλλάζοντας μηνύματα. Το πακέτο των μηνυμάτων παρέχει τις απαραίτητες κλάσεις για την επικοινωνία. Έτσι ένα μήνυμα αποστέλλεται και λαμβάνεται από τα εξαρτήματα ή από τις υπηρεσίες. Τα μηνύματα που έχουν ως αποστολή διεργασίες αναδιαμόρφωσης, ορίζονται ως οι υποκλάσεις του μηνύματος. Για παράδειγμα ένα μήνυμα που αφορά αίτηση σύνδεσης δίνει το έναυσμα για τη δημιουργία μίας νέας συνεδρίας για την κάλυψη συγκεκριμένων απαιτήσεων. Με εξαίρεση το μήνυμα που αφορά την αίτηση σύνδεσης, τα υπόλοιπα μηνύματα αποστέλλονται μέσω μίας έγκυρης συνεδρίας [2]. Εικόνα 8 Πακέτο για τα μηνύματα [2] Δυναμικό Μοντέλο Για να προσδιοριστούν οι προγραμματισμένες ή οι μη αναμενόμενες αναδιαμορφώσεις των αρχιτεκτονικών χρησιμοποιούνται οι κανόνες μετασχηματισμού γραφημάτων ώστε να καταγραφούν οι δυναμικές πτυχές της αρχιτεκτονικής. Οι τρόποι απεικόνισης ενός κανόνα μετασχηματισμού γραφήματος είναι δύο. Ο πρώτος τρόπος είναι η απεικόνιση ενός κανόνα ως ένα ζεύγος γραφημάτων. Το αριστερό μέρος των διαγραμμάτων καθορίζει τις προϋποθέσεις και το δεξιό μέρος καθορίζει τις συνθήκες που επικρατούν μετά το μετασχηματισμό. Τα δύο αυτά γραφήματα αναπαριστούν ένα μέρος της διαμόρφωσης ως παράδειγμα του στατικού μοντέλου της SOA αρχιτεκτονικής

38 Στην εικόνα που ακολουθεί απεικονίζεται ο κανόνας για την αποστολή ενός αιτήματος σύνδεσης κατά το οποίο ένα εξάρτημα παίζει το ρόλο του αιτούντος για μία υπηρεσία και στέλνει μία αίτηση σύνδεσης στην υπηρεσία με την οποία θέλει να συνδεθεί. Βέβαια ο αιτών πρέπει να γνωρίζει απαραίτητα τις προδιαγραφές της υπηρεσίας που μπορούν να καλύψουν τις απαιτήσεις του. Έπειτα δημιουργείται το μήνυμα της αίτησης και συνδέεται με το δέκτη [2]. Εικόνα 9 Ο κανόνας μετασχηματισμού ως ένα ζεύγος γραφημάτων [2]. Στην επόμενη εικόνα παρουσιάζεται ένας εναλλακτικός τρόπος απεικόνισης με βάση τον οποίο είναι εφικτό να συμπεριληφθούν οι συνθήκες πριν (pre) και μετά (post) το μετασχηματισμό, σε ένα διάγραμμα UML. Τα νέα στοιχεία που έχουν προστεθεί στο γράφημα επισημαίνονται με την ετικέτα (new) και τα στοιχεία που έχουν διαγραφεί με την ετικέτα (destroyed). Εικόνα 10 Συνοπτικός συμβολισμός για την αποστολή μίας αίτησης σύνδεσης [2]

39 Για τη δημιουργία του αιτήματος, η υπηρεσία που λαμβάνει το αίτημα πρέπει να προετοιμάσει μία συνεδρία και να επιβεβαιώσει όλες τις απαιτούμενες ιδιότητες. Για το σκοπό αυτό οι ιδιότητες σημειώνονται αρχικά με μία «προς επιβεβαίωση» (to confirm) σύνδεση μεταξύ κάθε ιδιότητας και της υπηρεσίας. Κάθε φορά που είναι εφικτό να επιβεβαιωθεί μία ιδιότητα (π.χ. με σύγκριση με τις ιδιότητες της υπηρεσίας) είναι εφικτό να σβηστεί η «προς επιβεβαίωση» σύνδεση της ιδιότητας αυτής. Όταν αφαιρεθούν επιτυχώς όλες οι «προς επιβεβαίωση» συνδέσεις, η υπηρεσία αποκρίνεται στο αίτημα στέλνοντας μία «κοινοποίηση επιτυχίας» (success notification) όπως φαίνεται στην επόμενη εικόνα. Ο κανόνας αυτός περιέχει μία κατάσταση αρνητικής εφαρμογής η οποία εμποδίζει την υλοποίηση του κανόνα αν υπάρχει οποιαδήποτε απαιτούμενη ιδιότητα η οποία δεν έχει επιβεβαιωθεί ακόμα από την υπηρεσία [2]. Εικόνα 11 Κανόνας με κατάσταση αρνητικής εφαρμογής [2]. Μετά τη λήψη του μηνύματος κοινοποίησης (notification message), ο κανόνας «σύνδεσης στη συνεδρία» (που φαίνεται στην επόμενη εικόνα) μπορεί να εφαρμοστεί για την εγκαθίδρυση της σύνδεσης μεταξύ του αιτούντος την υπηρεσία (service requestor) και της νέας συνεδρίας. Παράλληλα, τα μηνύματα αίτησης και κοινοποίησης διαγράφονται, αφού δε χρησιμοποιούνται πλέον. Συνολικά το δυναμικό μοντέλο περιλαμβάνει γύρω στους 20 κανόνες μετασχηματισμού οι οποίοι καλύπτουν τη δημοσίευση της περιγραφής μίας υπηρεσίας σε μία υπηρεσία ανακάλυψης, την αναζήτηση στον κατάλογο μίας υπηρεσίας από μία υπηρεσία ανακάλυψης, τη σύνδεση σε μία γνωστή υπηρεσία, την αλληλεπίδραση με μία υπηρεσία ανταλλάσσοντας μηνύματα και την αποσύνδεση από μία υπάρχουσα συνεδρία [2]

40 Εικόνα 12 Κανόνας μετασχηματισμού «σύνδεσης στη συνεδρία» [2]

41 2 ο - ΚΕΦΑΛΑΙΟ «SOA: Ανάλυση και Σχεδίαση» 2.1 Υπηρεσιοστραφείς Αρχές Υλοποίησης Οι υπηρεσιοστραφείς μέθοδοι παρέχουν καθοδήγηση σε πολλαπλές δραστηριότητες ανάπτυξης και αποτελούνται από δύο κύριες φάσεις: Η πρώτη φάση σχετίζεται με την ανάπτυξη των υπηρεσιών με στόχο την επαναχρησιμοποίηση τους. Η δεύτερη φάση αποτελείται από υπηρεσιοστραφείς λύσεις. Πραγματοποιείται επαναχρησιμοποίηση των υπηρεσιών οι οποίες λειτουργούν ως δομικές μονάδες με βάση την υπηρεσιοστραφή αρχιτεκτονική. Η SOA είναι ένα αρχιτεκτονικό στυλ το οποίο καθορίζει τον τρόπο που χρησιμοποιούνται οι υπηρεσίες ως θεμελιώδη στοιχεία για το σχηματισμό μίας υπηρεσιοστραφούς λύσης. Οι υπηρεσιοστραφείς μέθοδοι υλοποίησης λογισμικού σχετίζονται με την ανάπτυξη υπηρεσιών με βάση δύο στόχους: Αναγνώριση υπηρεσίας. Ασχολείται με τον εντοπισμό υποψήφιων υπηρεσιών οι οποίες είναι λογικά συνεκτικές, ανεξάρτητες και επαναχρησιμοποιήσιμες. Πραγματοποίηση υπηρεσίας. Ασχολείται με τον καθορισμό των συμβάσεων παροχής υπηρεσιών, με την υλοποίηση, τον έλεγχο και την ανάπτυξη των υπηρεσιών [4]. H υλοποίηση μίας SOA αρχιτεκτονικής πρέπει να βασίζεται στις παρακάτω βασικές αρχές: Η καταγραφή των επιχειρησιακών διαδικασιών είναι ιδιαίτερα σημαντική, είτε πρόκειται για καταγραφή από κάτω προς τα πάνω (bottom up), είτε για καταγραφή από πάνω προς τα κάτω (top down). Ειδικότερα, τα έγγραφα που περιγράφουν τις επιχειρησιακές διεργασίες πρέπει να είναι

42 ανά πάσα στιγμή διαθέσιμα καθότι περιέχουν στοιχεία τα οποία είναι πολύ σημαντικά για την ανάπτυξη μίας SOA αρχιτεκτονικής. Η SOA αρχιτεκτονική πρέπει να προσφέρει επιχειρησιακή αξία και σταδιακά να την αυξάνει. Η υλοποίηση μίας SOA αρχιτεκτονικής πρέπει να βασίζεται σε χαλαρά συνδεδεμένες υπηρεσίες οι οποίες παρέχουν τη μεγαλύτερη δυνατή ευελιξία και διαρκή μείωση του κόστους, λόγω δυνατότητας επαναχρησιμοποίησης και μικρότερων απαιτήσεων για συντήρηση. Οι υπηρεσίες πρέπει να έχουν πρότυπες συμβατές διεπαφές ώστε να καθιστούν εφικτή την ενσωμάτωση σε άλλες υπηρεσίες ή τη διαλειτουργικότητα με άλλες υπηρεσίες. Η επιχείρηση πρέπει να καθορίζει τις χρησιμοποιούμενες υπηρεσίες και οι υπηρεσίες τη χρησιμοποιούμενη τεχνολογία. Η ευελιξία της επιχείρησης πρέπει να αποτελεί θεμελιώδες στοιχείο για μία SOA αρχιτεκτονική [3]. 2.2 Πρακτικές Σωστής Ανάπτυξης μίας SOA Αρχιτεκτονικής Στην παράγραφο αυτή παρουσιάζονται μερικές από τις πιο σημαντικές πρακτικές για τη σωστή ανάπτυξη και λειτουργία μίας υπηρεσιοστραφούς αρχιτεκτονικής. Επαναχρησιμοποίηση Πρέπει να δημιουργηθεί ένα επαναχρησιμοποιήσιμο (reusable) πλαίσιο αρχιτεκτονικής για την ευκολότερη προσαρμογή των SOA καινοτομιών σε ολόκληρη την επιχείρηση. Αυτό μπορεί να συμβεί υπό δύο προϋποθέσεις: Θεσπίζοντας ότι η επαναχρησιμοποίηση των αρχιτεκτονικών στοιχείων έχει προτεραιότητα έναντι των μεμονωμένων απαιτήσεων του έργου. Αξιολογώντας τις νέες απαιτήσεις όσον αφορά τη δημιουργία επαναχρησιμοποιήσιμων στοιχείων

43 Οι υπηρεσίες πρέπει να σχεδιάζονται με τρόπο που να καθιστά εφικτή την επαναχρησιμοποίηση και να αυξάνονται οι δυνατότητες επαναχρησιμοποίησης ανάλογα με τις απαιτήσεις της επιχείρησης. Η επαναχρησιμοποίηση απαιτεί προσεκτικό σχεδιασμό και προσεκτική διαχείριση. Επιχειρησιακός Υπηρεσιακός Δίαυλος (Enterprise Service Bus ESB) και δρομολόγηση μηνυμάτων Η δρομολόγηση μηνυμάτων με βάση το περιεχόμενο αποτελεί κεντρικό κομμάτι κάθε εύρωστης SOA υποδομής. Για να συμβεί αυτό καλό είναι να προσαρμοστούν πρωτόκολλα δρομολόγησης όπως είναι το TCP και το IP τα οποία φημίζονται για την ανθεκτικότητα και την ευελιξία τους. Μία ESB αρχιτεκτονική μπορεί να φροντίσει για τη μετάφραση και τη δρομολόγηση των μηνυμάτων μεταξύ διαφορετικών υπηρεσιών. Διαχείριση δεδομένων Κατά την υλοποίηση της SOA είναι ιδιαίτερα σημαντική η εστίαση στα δεδομένα της εφαρμογής. Σε κάθε περίπτωση πρέπει να υπάρχει ως προτεραιότητα η δημιουργία ενός πλαισίου διαχείρισης των δεδομένων το οποίο πρέπει να αναγνωρίζει τα επιμέρους στοιχεία του πλαισίου, τους συσχετισμούς, τους ρόλους και τις ευθύνες. Η έλλειψη πλαισίου διαχείρισης μπορεί να οδηγήσει σε κακή διαχείριση των δεδομένων και απειλές για ακεραιότητα των δεδομένων. Ασφάλεια Αν και η SOA δημιουργεί ένα ανοιχτό πλαίσιο είναι εφικτό να ενισχύσει την ασφάλεια των δεδομένων και των συστημάτων, υλοποιώντας την ασφάλεια ως υπηρεσία. Έτσι στη SOA πρέπει να δημιουργηθούν ειδικές απαιτήσεις ασφαλείας σε κατάλληλα σημεία της αρχιτεκτονικής. Πρέπει να υπάρξει κατάλληλη διαχείριση των ενδιάμεσων υπηρεσιών προκειμένου να πληρούν τις βασικές απαιτήσεις ασφάλειας, καταγραφής και παρακολούθησης. Διασφάλιση της επεκτασιμότητας Μία SOA εφαρμογή αποτελείται συνήθως από εκατοντάδες επιμέρους συνδέσεις. Έτσι, πρέπει να χρησιμοποιηθούν κατάλληλες λύσεις για την κάλυψη των απαιτήσεων αξιοπιστίας και απόδοσης. Στη συνέχεια πρέπει να υπάρξει κατάλληλος σχεδιασμός και έλεγχος για να πιστοποιηθεί ότι πληρούνται οι απαιτήσεις επεκτασιμότητας και διαλειτουργικότητας

44 Επίτευξη λειτουργικής προβολής και ελέγχου Η SOA διαχείριση είναι ένας ιδιαίτερα σημαντικός παράγοντας ο οποίος καθορίζει την απορροή σταθερών πλεονεκτημάτων από τη χρήση της SOA και βοηθάει στη διασφάλιση των περισσότερων δυνατών αρχιτεκτονικών πλεονεκτημάτων κατά τη διαδικασία της επαναχρησιμοποίησης. Μία αποτελεσματική SOA πλατφόρμα διαχείρισης βοηθάει τους εργαζόμενους να εργάζονται και να συνεργάζονται πιο αποτελεσματικά αφού ορίζει με σαφήνεια τους ρόλους και τις ευθύνες τους. Επίσης βοηθάει την επιχείρηση να εντοπίσει τα προγράμματα εκείνα που συμβάλλουν περισσότερο, στην επίτευξη των επιχειρησιακών στόχων [5]. 2.3 SOA Ανάλυση και Σχεδίαση Οι προηγούμενες διαδικασίες ανάπτυξης και σχεδίασης (π.χ. αντικειμενοστραφής αρχιτεκτονική (object-oriented architecture) καλύπτουν μόνο μερικά τμήματα από αυτά που απαιτούνται για την υποστήριξη μίας SOA αρχιτεκτονικής. Η SOA αρχιτεκτονική ενισχύει τις καθιερωμένες αρχές λογισμικού όπως είναι για παράδειγμα η απόκρυψη πληροφοριών, ο τμηματικός σχεδιασμός και ο διαχωρισμός των προβλημάτων. Επίσης προσθέτει επιπλέον στοιχεία όπως είναι για παράδειγμα τα αρχεία καταγραφής πληροφοριών, η choreography λειτουργία και το πρότυπο ESB (Enterprise Service Bus - Επιχειρησιακός Δίαυλος Υπηρεσίας). Στην εικόνα που ακολουθεί παρουσιάζεται η EA (Enterprise Architecture Επιχειρησιακή Αρχιτεκτονική), BPM (Business Process Modeling Μοντελοποίηση Επιχειρησιακών Διαδικασιών) και η αντικειμενοστραφής (object-oriented) προσέγγιση μοντελοποίησης

45 Εικόνα 13 BPM, EA και αντικειμενοστραφής προσέγγιση μοντελοποίησης [6]. Οι παραπάνω προσεγγίσεις αποτελούν την αφετηρία μίας υπηρεσιοστραφούς (service-oriented) ανάλυσης και σχεδίασης [6] ESB Ο επιχειρησιακός δίαυλος υπηρεσίας (Enterprise Service Bus ESB) αντιπροσωπεύει ένα νέο είδος εφαρμογής η οποία αφορά την ενσωμάτωση ενδιάμεσου λογισμικού και παρέχει θεμελιώσεις υπηρεσίες στις περισσότερο πολύπλοκες SOA αρχιτεκτονικές, μέσω μίας μηχανής ανταλλαγής μηνυμάτων η οποία βασίζεται είτε στα γεγονότα είτε σε μία γλώσσα σήμανσης (Extensible Markup Language XML) και παίζει το ρόλο του διαύλου (bus). Το ESB υποστηρίζει τη μεταφορά δεδομένων, την «έξυπνη» δρομολόγηση, παίζει το ρόλο του διαμεσολαβητή κατά τη διάρκεια της επικοινωνίας, παρέχει πρόσβαση στους πόρους μέσω κατάλληλων προσαρμογέων (adapters) ή κατάλληλων πρωτοκόλλων επικοινωνίας, παρέχει συντονισμό διαδικασιών (ενορχήστρωση orchestration), φροντίζει για τη διαχείριση της ποιότητας και της ασφάλειας των υπηρεσιών και διασφαλίζει την παράδοση των μηνυμάτων. Έτσι το ESB παρέχει μία περισσότερο ευέλικτη προσέγγιση για την ενσωμάτωση εφαρμογών η οποία καλύπτει τις απαιτήσεις συγχρονισμού μεταξύ δύο ή περισσότερων εφαρμογών

46 Το ESB σχηματίζει ένα επίπεδο (layer) το οποίο καθιστά εφικτή την αξιοποίηση της δυνατότητας ανταλλαγής μηνυμάτων διατηρώντας παράλληλα ένα απλό μοντέλο αρχιτεκτονικής. Επίσης λειτουργεί ως μία ευέλικτη «ραχοκοκαλιά» (backbone) ενσωμάτωσης, στην οποία εισάγονται τα στοιχεία των υπηρεσιών λογισμικού και τα στοιχεία των εφαρμογών. Δηλαδή το ESB παίζει το ρόλο μίας δομής η οποία μεταφέρει και δρομολογεί μηνύματα, καθιστώντας εφικτή την ενσωμάτωση νέων προτύπων σε μία SOA αρχιτεκτονική [7]. Στην εικόνα που ακολουθεί απεικονίζεται το μπλοκ διάγραμμα ενός ESB που μπορεί να ενσωματώσει πολυπλατφορμικές (multiplatform) επιχειρησιακές και προσαρμοσμένες εφαρμογές με διαφορετικές πηγές δεδομένων, σε ένα κοινό κανάλι το οποίο παρέχει έξυπνη δρομολόγηση (intelligent routing) και προηγμένες δυνατότητες επικοινωνίας. Εικόνα 14 ESB μπλοκ διάγραμμα [7]. Το πιο σημαντικό πλεονέκτημα της χρήσης του ESB ως υποκείμενη υποδομή επικοινωνίας είναι ότι μπορεί να αποσπάσει υπηρεσίες από μία ισχυρή ζεύξη με βάση ένα τρόπο επικοινωνίας ο οποίος βασίζεται στην ανταλλαγή μηνυμάτων [7]

47 2.3.2 Ο Συνδυασμός της BPM, της EA και της Αντικειμενοστραφούς Ανάλυσης και Σχεδίασης Το σκεπτικό της SOA έχει γίνει αποδεκτό με ευκολία αφού βασίζεται σε ευρύτερα γνωστές, ήδη υπάρχουσες, τεχνικές. Για παράδειγμα, οι γενικές αρχές της αρχιτεκτονικής λογισμικού, ο αντικειμενοστραφής (object-oriented) προγραμματισμός και οι component-orientation αρχές, είναι από τις πλέον έγκυρες τεχνικές και είναι εφικτό να εφαρμοστούν σε κάθε SOA. Η αντικειμενοστραφής (object-oriented) μεθοδολογία ανάλυσης και σχεδίασης μπορεί να αποτελέσει αφετηρία για την ερμηνεία της SOA. Ωστόσο, η αντικειμενοστραφής (object-oriented) ανάλυση και σχεδίαση επικεντρώνεται σε στοιχεία του μικρό-επίπεδου (micro-level) (π.χ. κλάσεις και μεμονωμένες περιπτώσεις αντικειμένων). Η εφαρμογή των αντικειμενοστραφών τεχνικών και της Ενιαίας Γλώσσας Μοντελοποίησης (Unified Modeling Language UML) στο επίπεδο της αρχιτεκτονικής, αποτέλεσε κοινή πρακτική τα τελευταία χρόνια. Ωστόσο πάντοτε ήταν αναγκαία η κατασκευή ενός ξεχωριστού μοντέλου για την επίλυση προβλημάτων ανά πεδίο. Αυτό είχε ως αποτέλεσμα, να παρουσιάζει προβλήματα η ανάπτυξη των εφαρμογών σε αρκετές περιπτώσεις. Οι προσεγγίσεις της επιχειρησιακής αρχιτεκτονικής (Enterprise Architecture EA) προσθέτουν το στοιχείο του κεντρικού προγραμματισμού στις διάφορες αρχιτεκτονικές λογισμικού. Δυστυχώς όμως δε διευκολύνουν την επαναχρησιμοποίηση και δεν μπορούν να προσδιορίσουν τον τρόπο αύξησης της διάρκειας ζωής και χρήσης του λογισμικού. Από την πλευρά της η μοντελοποίηση των επιχειρησιακών διαδικασιών (Business Process Modeling BPM) παρέχει μία από άκρη σε άκρη (end to end) άποψη για τις λειτουργικές μονάδες εργασίας, χωρίς να ασχολείται με την αρχιτεκτονική και το πεδίο υλοποίησης

48 Με βάση τα παραπάνω, η κατάλληλη προσέγγιση πρέπει να περιλαμβάνει στοιχεία και τεχνικές που προκύπτουν από το συνδυασμό της μοντελοποίησης των επιχειρησιακών διαδικασιών (Business Process Modeling BPM), της επιχειρησιακής αρχιτεκτονικής (Enterprise Architecture EA) και της αντικειμενοστραφούς (object-oriented) μεθοδολογίας ανάλυσης και σχεδίασης. Εκτός από αυτά τα στοιχεία, καλό είναι να περιέχει αρκετά ευδιάκριτα και καινοτόμα στοιχεία. Στην εικόνα που ακολουθεί, παρουσιάζονται τα στοιχεία που πρέπει να περιέχει η υπηρεσιοστραφής (service-oriented) ανάλυση και σχεδίαση, καθώς και οι τεχνικές από τις οποίες προέρχονται τα στοιχεία αυτά. Εικόνα 15 Τα επιμέρους στοιχεία της υπηρεσιοστραφούς (service-oriented) ανάλυσης και σχεδίασης και η προέλευση τους [6] Επιχειρησιακή Αρχιτεκτονική (Enterprise Architecture EA) Η επιχειρησιακή αρχιτεκτονική (Enterprise Architecture EA) αντιπροσωπεύει τις συνολικές απαιτήσεις των επιχειρήσεων. Η ΕΑ συμπεριλαμβάνει επιχειρησιακούς στόχους, το μοντέλο παροχής πληροφοριών και τη συνολική αρχιτεκτονική της επιχείρησης. Η ΕΑ βάζει τα θεμέλια για τη δημιουργία ενός καταλόγου υπηρεσιών και ενός χάρτη πλοήγησης που προσδιορίζει τις πιο σημαντικές οντότητες, τις πιο σημαντικές υπηρεσίες και τις πιο σημαντικές ομάδες υπηρεσιών που είναι απαραίτητες για την υποστήριξη των επιχειρησιακών στόχων. Ο χάρτης πλοήγησης καθορίζει επίσης την προτεραιότητα της υλοποίησης των υπηρεσιών έτσι ώστε να υλοποιούνται πρώτα οι πιο σημαντικές υπηρεσίες [1]

49 2.3.4 Μοντέλο Επιχειρησιακών Διαδικασιών (Business Process Model BPM) Η διαδικασία μοντελοποίησης των επιχειρησιακών διαδικασιών υποδιαιρείται σε πολλά επιμέρους τμήματα. Επίσης αποτελείται από πολλά διαφορετικά σύμβολα και πολλά διαφορετικά επιμέρους στοιχεία. Το επιχειρησιακό μοντέλο διαδικασιών (Business Process Model BPM) μπορεί να αποτελέσει την αφετηρία μίας SOA αρχιτεκτονικής, αφού μπορεί να λειτουργήσει ως ένα σύνολο επιχειρησιακών απαιτήσεων. Με βάση το σκεπτικό αυτό, οι εργασίες του BPM υλοποιούνται από τις επιχειρησιακές υπηρεσίες. Το BPM μπορεί να προσφέρει πρόσθετη ανάλυση του συστήματος της επιχείρησης (enterprise system) αφού παρέχει περισσότερες λεπτομέρειες σχετικά με την αρχιτεκτονική της επιχείρησης. Ένα BPM μοντέλο αποτελείται από τα παρακάτω βασικά στοιχεία: Βήματα της διαδικασίας. Αντιπροσωπεύουν τις επιμέρους ενέργειες από την πλευρά της επιχείρησης. Πύλες (gateways). Συνδυάζουν ή χωρίζουν τη ροή των διαδικασιών, είτε συνδυάζοντας παράλληλες ροές είτε διαιρώντας ροές με βάση διάφορα κριτήρια απόφασης. Έγγραφα. Αναπαριστούν συνεκτικά σύνολα επιχειρησιακών δεδομένων (π.χ. παραγγελία ή πληρωμή) Ροές διαδικασιών (process flows). Συνδέουν βήματα διαδικασιών και πύλες προβάλλοντας και ενισχύοντας συγκεκριμένα στοιχεία των διαδικασιών. Ροές δεδομένων (data flows). Δείχνουν τον τρόπο που οι διεργασίες παράγουν και/ή καταναλώνουν συγκεκριμένα δεδομένα. Λωρίδες (lanes). Επισημαίνονται με τα ονόματα των φορέων, οργανώνουν τα επιμέρους βήματα και το ποιος κάνει τι (π.χ. ο πελάτης δίνει την παραγγελία). Οι λωρίδες επισημαίνουν επίσης την προέλευση και τον προορισμό των ροών δεδομένων (data flows) (π.χ. δείχνουν ότι η ναυτιλιακή εταιρία έχει ενημερωθεί για το αίτημα αποστολής ενός πακέτου) [1], [6]

50 2.3.5 Η Αντικειμενοστραφής (Object-Oriented) Σχεδίαση σε Σχέση με την Υπηρεσιοστραφή (Service-Oriented) Σχεδίαση Η αντικειμενοστραφής (object-oriented) σχεδίαση είναι μία ιδιαίτερα δυναμική τεχνική. Έτσι η υπηρεσιοστραφής (service-oriented) σχεδίαση χρησιμοποιεί αρκετές αντικειμενοστραφείς αρχές όπου είναι απαραίτητο. Ο στόχος της objectoriented σχεδίασης είναι ο ταχύτατος και αποτελεσματικός σχεδιασμός, η ανάπτυξη και εκτέλεση ευέλικτων και επεκτάσιμων εφαρμογών. Οι θεμελιώδεις αρχές της αντικειμενοστραφούς σχεδίασης είναι: Ενθυλάκωση (Encapsulation). Ένα αντικείμενο λογισμικού είναι ένα διακριτό πακέτο το οποίο περιέχει τόσο τις φυσικές ιδιότητες (αντιστοιχούν στα δεδομένα) όσο και τη λειτουργικότητα (αντιστοιχεί στη συμπεριφορά). Απόκρυψη πληροφοριών. Τα καλά δομημένα αντικείμενα χαρακτηρίζονται από απλό τρόπο διασύνδεσης, χωρίς όμως να αποκαλύπτεται κανένας από τους εσωτερικούς τους μηχανισμούς. Κλάσεις και υποδείγματα. Οι κλάσεις είναι πρότυπα τα οποία ορίζουν το είδος των ιδιοτήτων και τη συμπεριφορά που έχει ο κάθε τύπος αντικειμένου λογισμικού. Τα υποδείγματα είναι μεμονωμένα αντικείμενα που περιέχουν τιμές για αυτές τις ιδιότητες. Κληρονομικότητα. Υπάρχει μία φυσική ιεραρχία των αντικειμένων λογισμικού. Ανταλλαγή μηνυμάτων. Τα αντικείμενα λογισμικού πρέπει να επικοινωνούν μεταξύ τους προκειμένου να εκτελέσουν κάθε χρήσιμη εργασία. Όταν ένα υπόδειγμα λαμβάνει ένα μήνυμα, εκτελεί μία αντίστοιχη λειτουργία η οποία καλείται μέθοδος και έχει το ίδιο όνομα με το μήνυμα. Πολυμορφισμός. Ο όρος αυτός περιγράφει την κατάσταση κατά την οποία δύο ή περισσότερες κλάσεις χειρίζονται ένα συγκεκριμένο μήνυμα και το χρησιμοποιούν με το διαφορετικό τρόπο η κάθε μία [6]. Ο αντικειμενοστραφής (object-oriented) τρόπος σχεδίασης είναι μία πλήρης διαδικασία για ανάλυση, σχεδιασμό και ανάπτυξη εφαρμογών:

51 Αντικειμενοστραφής ανάλυση και σχεδιασμός. Προσπαθεί να βρει το βέλτιστο σύνολο επιχειρησιακών αντικειμένων και την πιο φυσική ιεραρχία κλάσεων για την υλοποίηση τους. Αντικειμενοστραφής ανάπτυξη. Επικεντρώνεται στη σταδιακή ανάπτυξη των εφαρμογών, ένα επιχειρησιακό σενάριο (ή περίπτωση χρήσης) τη φορά. Εργαλεία όπως είναι για παράδειγμα το WSAD βοηθούν τους προγραμματιστές να κατασκευάσουν και να δοκιμάσουν ταχύτατα της object-oriented εφαρμογές. Περιβάλλον λειτουργίας. Μπορεί να είναι το περιβάλλον μίας Java εικονικής μηχανής η οποία εκτελεί κώδικα, παρέχει υπηρεσίες εφαρμογών όπως είναι για παράδειγμα η αφαίρεση πόρων που δε χρησιμοποιούνται πλέον και πλαίσια τα οποία διαθέτουν μηχανισμούς για την επικοινωνία αντικειμένων που βρίσκονται σε διαφορετικούς διακομιστές (servers) [6]. Το κύριο ζήτημα για τις αντικειμενοστραφείς πρακτικές σχεδίασης σε σχέση με τις υπηρεσιοστραφείς, είναι ότι το ποσοστό της διακριτότητας εστιάζεται στο επίπεδο των κλάσεων. Το γεγονός αυτό καθιστά ιδιαίτερα δύσκολη την προσαρμογή στις τρέχουσες SOA αντιλήψεις αν και εξακολουθεί να αποτελεί μία πολύτιμη προσέγγιση για το σχεδιασμό των υφιστάμενων κλάσεων και το σχεδιασμό της δομής των στοιχείων, σε μία καθορισμένη υπηρεσία. Επιπρόσθετα πολλές object-oriented τεχνικές ανάλυσης και σχεδίασης μπορούν να λειτουργήσουν ως μοχλός για τη μοντελοποίηση υπηρεσιών. Στην εικόνα που ακολουθεί παρουσιάζονται τα επιμέρους επίπεδα μίας αντικειμενοστραφούς και μίας υπηρεσιοστραφούς σχεδίασης καθώς και ο τρόπος που σχετίζονται μεταξύ τους στα πλαίσια μίας SOA αρχιτεκτονικής. Η UML (Unified Modeling Language Ενιαία Γλώσσα Μοντελοποίησης) ενισχυμένη με μερικά πρόσθετα χαρακτηριστικά στερεότυπα και προφίλ, αποτελεί βασικό στοιχείο της service-oriented ανάλυσης και σχεδίασης. Στον τομέα των διαδικασιών η RUP (Rational Unified Process - Ορθολογική Ενιαία Διαδικασία) είναι μία από τις κορυφαίες διεργασίες υπηρεσιοστραφούς ανάλυσης και σχεδίασης για την ανάπτυξη επαναληπτικού λογισμικού (iterative software)

52 Εικόνα 16 Επίπεδα σχεδίασης [6]. Όμως η RUP βασίζεται στην αντικειμενοστραφή σχεδίαση και δεν είναι εύκολο να προσαρμοστεί στο σκεπτικό της SOA σχεδίασης. Από τη σκοπιά της RUP, η αρχιτεκτονική του συστήματος είναι η δομή των κύριων στοιχείων του, τα οποία αλληλεπιδρούν μέσω καθορισμένων συνδέσεων. Τα στοιχεία αυτά αποτελούνται από άλλα μικρότερα στοιχεία. Αντίθετα σε μία SOA σχεδίαση, η αρχιτεκτονική του συστήματος είναι η δομή ακανόνιστων, πλήρως ενθυλακωμένων, αυτό-περιγραφόμενων υπηρεσιών, οι οποίες ικανοποιούν μία γενική επιχειρησιακή υπηρεσία. Η υπηρεσία αυτή αντιστοιχίζεται στο επιχειρησιακό μοντέλο διαδικασιών όπως φαίνεται στην επόμενη εικόνα [6]. Εικόνα 17 Υπηρεσιοστραφής ιεράρχηση του ορισμού της υπηρεσίας [6]

53 2.3.6 Απαιτήσεις Η υπηρεσιοστραφής ανάλυση και σχεδίαση συνοδεύεται από τις ακόλουθες απαιτήσεις: Η διαδικασία και ο συμβολισμός πρέπει να οριστούν επίσημα (ή σχεδόν επίσημα) όπως ακριβώς συμβαίνει και σε οποιαδήποτε άλλη μεθοδολογία σχεδίασης. Η SOA ανάλυση και σχεδίαση δεν ξεκινάει από το μηδέν. Αντίθετα ξεκινάει με κατάλληλη επιλογή ή κατάλληλο συνδυασμό BPM, EA και αντικειμενοστραφών (object-oriented) στοιχείων. Στη συνέχεια είναι εφικτό να οριστούν νέα στοιχεία αν αυτό κριθεί απαραίτητο. Από άκρη σε άκρη μοντελοποίηση συμπεριλαμβανομένης της παροχής εργαλείων υποστήριξης. Η SOA αναμένεται να προσφέρει ευελιξία και ευκινησία στην επιχείρηση. Βέλτιστες δυνατές πρακτικές με στόχο την παροχή ποιοτικών υπηρεσιών. Δυνατότητα διάκρισης των επιμέρους στοιχείων. Η SOA πρέπει να προσφέρει ένα δομημένο τρόπο κατανόησης των επιχειρησιακών υπηρεσιών και των υπηρεσιών λογισμικού. Η αντικειμενοστραφής ανάλυση και σχεδίαση οδηγεί στο σχηματισμό κλάσεων και αντικειμένων στο επίπεδο της εφαρμογής και σε BPM μοντέλα διαδικασιών με βάση τα γεγονότα. Η SOA καθιστά εφικτή τη συνένωση τους. Η SOA πρέπει να χρησιμοποιεί διεργασίες που βασίζονται στα επιχειρησιακά γεγονότα, να φροντίζει όχι μόνο για το συντακτικό, αλλά και για τη σημασιολογία και τις πολιτικές (αυτό απαιτείται στην ad-hoc σύνθεση, στη σημασιολογική διαμεσολάβηση και στον καθορισμό του χρόνου εκτέλεσης [6] Παράγοντες που Καθορίζουν την Ποιότητα Στην παράγραφο αυτή παρουσιάζονται ορισμένες βασικές αρχές ή ορισμένοι παράγοντες καθορισμού της ποιότητας οι οποίοι αποτελούν τη βάση της serviceoriented ανάλυσης και σχεδίασης:

54 Οι καλοφτιαγμένες υπηρεσίες προσφέρουν ευελιξία και ευκινησία στην επιχείρηση, αφού καθιστούν εφικτή την αναδιαμόρφωση και την επαναχρησιμοποίηση μέσω της χαλαρής σύνδεσης, της ενθυλάκωσης και της απόκρυψης των πληροφοριών. Οι καλά σχεδιασμένες υπηρεσίες είναι σημαντικές και εφαρμόσιμες σε περισσότερες από μία επιχειρησιακές εφαρμογές. Η εξάρτηση μεταξύ των υπηρεσιών ελαχιστοποιείται και δηλώνεται με σαφήνεια. Η αφαίρεση υπηρεσιών είναι συνεκτική, ολοκληρωμένη και συνεπής. Η ονομασία των υπηρεσιών είναι κατανοητή για τους ειδικούς του χώρου ακόμα και όταν στερούνται βαθύτερων τεχνικών γνώσεων. Όλες οι υπηρεσίες ακολουθούν την ίδια φιλοσοφία σχεδίασης (η οποία διαρθρώνεται μέσω προτύπων και υποδειγμάτων) και τα ίδια πρότυπα αλληλεπίδρασης. Έτσι μπορεί να προσδιοριστεί με ευκολία το υποκείμενο αρχιτεκτονικό στυλ (π.χ. κατά την αξιολόγηση της αρχιτεκτονικής). Η ανάπτυξη των υπηρεσιών απαιτεί μόνο βασικές γνώσεις προγραμματισμού. Επίσης η τεχνογνωσία ενδιάμεσου λογισμικού (middleware) είναι απαραίτητη μόνο σε λίγες περιπτώσεις. Πέρα από το συνδυασμό της αντικειμενοστραφούς (object-oriented), της BPM και της EA τεχνικής, μερικές ακόμα σημαντικές SOA έννοιες και πτυχές είναι η ταυτοποίηση και ορισμός των υπηρεσιών, η κατηγοριοποίηση και η ομαδοποίηση των υπηρεσιών, η διαμεσολάβηση στη διαχείριση της σημασιολογίας, οι πολιτικές και οι πτυχές, η διαδικασία meet in the middle, η συλλογή υπηρεσιών και η διαμεσολάβηση στη διαχείριση των γνώσεων [6]

55 3 Ο - ΚΕΦΑΛΑΙΟ «Περιγραφή Μεθοδολογιών» 3.1 Εισαγωγή Στο παρόν κεφάλαιο περιγράφονται αναλυτικά έντεκα από τις υπάρχουσες SOSE (Service Oriented Software Engineering) μεθοδολογίες. Σχεδόν όλες οι SOSE μεθοδολογίες έχουν οριστεί στηριζόμενες στα χαρακτηριστικά των παραδοσιακών μεθοδολογιών (π.χ. αντικειμενοστρεφείς μεθοδολογίες). Κάθε παραδοσιακή μεθοδολογία περιλαμβάνει δραστηριότητες όπως η κωδικοποίηση, ο έλεγχος και η μετάβαση σε περιβάλλον παραγωγής. Η παροχή όμως μιας υπηρεσιοστραφούς λύσης απαιτεί τον εντοπισμό, την ανακάλυψη και τη σύνθεση υπηρεσιών. Ως εκ τούτου οι υπάρχουσες μεθοδολογίες ανάπτυξης λογισμικού δεν πληρούν πλέον τις ανάγκες για την ανάπτυξη υπηρεσιοστραφών έργων. Οι SOSE μεθοδολογίες μπορούν να θεωρηθούν ως εξέλιξη των παραδοσιακών μεθοδολογιών μιας και δεν διαφέρουν τόσο πολύ από τις παραδοσιακές. Ωστόσο υπάρχουν νέες εκτιμήσεις και οπτικές που θα πρέπει να ληφθούν υπόψη από την άποψη των νέων χαρακτηριστικών και των δραστηριοτήτων που είναι ειδικά για τις SOSE μεθοδολογίες. Η επιλογή για τη μελέτη και την παρουσίαση των συγκεκριμένων μεθοδολογιών έγινε με βάση τα παρακάτω κριτήρια: επίπεδο ωριμότητας αριθμός αναφορών διαθεσιμότητα πηγών κατάλληλη τεκμηρίωση Από τις επιλεγμένες μεθοδολογίες άλλες έχουν προταθεί από τη βιομηχανία λογισμικού και άλλες από την ακαδημαϊκή κοινότητα. 3.2 Μεθοδολογία SOAD Η μεθοδολογία SOAD είναι αποτέλεσμα της ανάγκης για τη δημιουργία μιας πειθαρχημένης μεθόδου ανάπτυξης υπηρεσιοστραφών λύσεων που να συνδυάζει στοιχεία από την Αντικειμενοστρεφή Ανάλυση και Σχεδίαση (OOAD), την Επιχειρησιακή Αρχιτεκτονική (EA) και τη Μοντελοποίηση Επιχειρησιακών Διαδικασιών (BPM) με νέα καινοτόμα στοιχεία. Η νέα διεπιστημονική (Επιστήμη

56 Πληροφορικής και Οικονομικών Επιστημών) προσέγγιση ανάλυσης και σχεδίασης που εξυπηρετεί την υπηρεσιοστραφή προσέγγιση θα πρέπει να περιγραφεί φορμαλιστικά. Η μεθοδολογία παρουσιάζει: Διαδικασία και σημειογραφία, όπως και κάθε άλλη μεθοδολογία ανάπτυξης λογισμικού. Η SOAD επιλέγει και συνδυάζει στοιχεία από OΟAD, BPM και EA. Επιπλέον στοιχεία μπορούν να οριστούν αν χρειάζεται. Δομημένο τρόπο σύλληψης των υπηρεσιών του οργανισμού και των υπηρεσιών λογισμικού. Η OOAD παρέχει κλάσεις και αντικείμενα στο επίπεδο της εφαρμογής, ενώ τα BPM μοντέλα διαδικασιών στηριζόμενα σε γεγονότα. Η SOAD έχει την πλήρη εικόνα του οργανισμού ενώνοντας τα παραπάνω κομμάτια. Στηρίζεται σε επιχειρησιακά γεγονότα και διαδικασίες και όχι σε περιπτώσεις χρήσης, οι οποίες χρησιμοποιούνται σε επόμενο βήμα χαμηλότερου επίπεδου. Επίσης, παρέχει σημασιολογία και πολιτικές που μπορούν να χρησιμοποιηθούν για ad-hoc σύνδεση υπηρεσιών, εξερεύνηση και μεσιτεία υπηρεσιών. Παράγοντες ποιότητας και καλές πρακτικές Κατανομή των ρόλων που παρουσιάζονται στην διαδικασία ανάπτυξης υπηρεσιοστραφούς λύσης. Από άκρη σε άκρη μοντελοποίηση συμπεριλαμβανομένων και εργαλείων υποστήριξής της [6] Παράγοντες Ποιότητας Οι παράγοντες που καθορίζουν την ποιότητα του αποτέλεσμα της μεθοδολογίας είναι: 1. Η δημιουργία σωστών υπηρεσιών, οι οποίες προσφέρουν ευκαμψία και ευκινησία στον οργανισμό. 2. Ο καλός σχεδιασμός έχει ως αποτέλεσμα υπηρεσίες σωστά ορισμένες που προσφέρουν μεγαλύτερη εφαρμοσιμότητα από ότι η Εnterprise Αpplication

57 Οι εξαρτήσεις είναι πλέον ελαχιστοποιημένες και ρητά εκφρασμένες. 3. Η αφαιρετική περιγραφή των υπηρεσιών, η οποία θα πρέπει να είναι πλήρης, συνεκτική και συνεπής. 4. Οι υπηρεσίες θα πρέπει να είναι όσο γίνεται να μην διατηρούν κατάσταση (stateless) στα πλαίσια του τομέα μελέτης. 5. Οι υπηρεσίες και οι αλληλεπιδράσεις τους θα πρέπει να ακολουθούν κοινά πρότυπα και φιλοσοφία σχεδίασης σε όλη την υπηρεσιοστραφή λύση. 6. Η ανάπτυξη των υπηρεσιών και των καταναλωτών υπηρεσιών θα πρέπει να απαιτεί μόνο βασική γνώση προγραμματισμού, επιπλέον της γνώσης του τομέα εφαρμογής. Οι ειδικές γνώσεις για το ενδιάμεσο επίπεδο την τεχνολογικής λύσης θα πρέπει να αφορούν μόνο λίγους ειδικούς [6] Αναγνώριση και Ορισμός Υπηρεσιών Η υπηρεσιοστραφής λύση συνήθως δεν χτίζεται από την αρχή, αντίθετα χρησιμοποιεί υπάρχουσες υποδομές του οργανισμού. H λύση ενσωματώνει κληρονομημένα συστήματα μετά την αποσύνθεση τους σε υπηρεσίες, λειτουργίες, επιχειρησιακές διαδικασίες και επιχειρησιακούς κανόνες, δηλαδή: Τα πακέτα εφαρμογών του οργανισμού μετατρέπονται σε σύνολα διακριτών υπηρεσιών που αντιπροσωπεύουν σύνολα σχετικών λειτουργιών. Οι επιχειρησιακοί κανόνες και διαδικασίες νοούνται αφαιρετικά, από την εφαρμογή που τους υλοποιεί, σε ένα ξεχωριστό επιχειρησιακό μοντέλο διαδικασιών, διαχειριζόμενο από την χορογραφία επιχειρήσεων Χρησιμοποιώντας τα ανοιχτά πρότυπα διασφαλίζουν τη διαλειτουργικότητα π.χ. BPEL, J2EE, XML κ.λ.π. Διαγραμματικά τα παραπάνω εμφανίζονται στην παρακάτω εικόνα

58 Εικόνα 18 - Αποσύνθεση υπηρεσιών στη μεθοδολογία SOAD [6]. Οι αντικειμενοστραφείς τεχνικές μπορούν να εφαρμοστούν, αλλά από ένα υψηλότερο σημείο παρατήρησης του οργανισμού, με στόχο να τον περιγράψουν σε υψηλό επίπεδο. Συνεπώς, οι στόχοι που τίθονται είναι οι ακόλουθοι: Η άμεση και έμμεση επιχειρησιακή ανάλυση. Η επιχειρησιακή μοντελοποίηση διαδικασιών και η απευθείας ανάλυση είναι ένας προφανής τρόπος για την αναγνώριση υποψήφιων υπηρεσιών, θα πρέπει όμως να υποστηρίζεται και να συμπληρώνεται από έμμεσες τεχνικές. Η αποσύνθεση τομέα. Η αποσύνθεση τομέα είναι το πρώτο βήμα για την περιγραφή του πλαισίου υπηρεσιών. Ο αποδεκτός βαθμός διάσπασης υπηρεσιών (granularity). Ο σωστός βαθμός αφαίρεσης είναι κλειδί για την μοντελοποίηση. Προτείνεται η όσο γίνεται πιο χονδρόκοκκη μοντελοποίηση, χωρίς να πέσει κάτω από τα ανεκτά επίπεδα πληρότητας και συνέπειας, και μόνο αν υπάρχει επιχειρησιακή ανάγκη να γίνει σε βάθος διάσπαση υπηρεσιών. Οι κανόνες ονοματολογίας. Πρέπει να οριστεί ένα κοινό σχήμα ονοματοδοσίας για όλα τα συστήματα του οργανισμού. Η μη χρήση αντι-προτύπων. Θα πρέπει να οριστεί τι δεν είναι καλήαποδεκτή υπηρεσία [6]

59 3.2.3 Κατηγοριοποίηση και Συσσωμάτωση Υπηρεσιών Οι υπηρεσίες μπορεί να είναι είτε υπηρεσίες λογισμικού είτε επιχειρησιακές υπηρεσίες. Οι υπηρεσίες χαμηλού επιπέδου μπορεί να συνδεθούν σε υψηλότερο επίπεδο, σε πλήρως λειτουργικές επιχειρησιακές υπηρεσίες που εξυπηρετούν τον οργανισμό. Η σύνθεση υπηρεσιών μπορεί να απλοποιηθεί από μοντέλα εκτέλεσης όπως η BPEL Σημασιολογία Μεσιτείας Υπηρεσιών Στη SOA θα πρέπει να οριστούν τυπικά οι διεπαφές των υπηρεσιών τόσο ως προς τον τύπο-σύνταξη των παραμέτρων αλλά και ως προς την σημασιολογία τους. Αυτή η δυνατότητα είναι σημαντική για να επιτευχθεί η απαραίτητη ευελιξία και προσαρμοστικότητα της υπηρεσιοστραφούς λύσης στις νέες επιχειρησιακές ανάγκες του οργανισμού Πολιτικές και Πτυχές Τυπικά συμβόλαια διεπαφών περιέχουν την σύνταξη της υπηρεσίας, την σημασιολογία και χαρακτηριστικά ποιότητας που θα μοντελοποιηθούν. Επίσης οποιοδήποτε λογισμικό ή τμήμα χρησιμοποιείται κατά την εκτέλεση της εφαρμογής θα πρέπει να αντιστοιχεί σε ένα επιχειρησιακό κομμάτι ή έννοια που καταλαβαίνει ο εκπρόσωπος του οργανισμού [6] Διαδικασία meet-in-the-middle Αν η μεθοδολογία μοντελοποίησης που ακολουθείται είναι από κάτω προς τα πάνω (top-down) τότε μπορεί να μην επιτευχθεί το κατάλληλο επίπεδο αφαίρεσης των επιχειρησιακών υπηρεσιών, και από την άλλη η μεθοδολογία από πάνω-προς-τακάτω (bottom-up) μπορεί να οδηγήσει σε ανεπαρκή συνολικά χαρακτηριστικά και να κάνει συμβιβασμούς σε άλλους παράγοντες της αρχιτεκτονικής ή να μην επιτύχει την σωστή σύνδεση του επιπέδου υπηρεσιών και συστατικών. Επειδή, λοιπόν, υπάρχει ήδη πληροφοριακό σύστημα που χρησιμοποιεί ο οργανισμός το καλύτερο είναι να ακολουθηθεί μια ενδιάμεση διαδικασία meet-in-the-middle [6]

60 3.2.7 Συγκομιδή Υπηρεσιών και Μεσιτεία Γνώσης Η επιτυχημένη επαναχρησιμοποίηση των υπηρεσιών είναι θέμα διαχείρισης γνώσης. Η υπηρεσίες θα πρέπει να αναγνωρίζονται και να ορίζονται με σκοπό να μπορούν να επαναχρησιμοποιηθούν. Αν ένα κομμάτι δεν έχει πιθανότητα να επαναχρησιμοποιηθεί τότε δε θα έπρεπε να αναπτυχθεί ως υπηρεσία, αλλά να συνδεθεί σε άλλη υπηρεσία. Ακόμα και αν η επαναχρησιμοποίηση δεν είναι στόχος, η διαδικασία συγκομιδής-αναζήτησης υπηρεσιών θα πρέπει να τυποποιηθεί, ώστε οι υπηρεσίες να είναι αναζητήσιμες από τους χρήστες τους [6]. 3.3 Μεθοδολογία TRUE (ICEIS) H μεθοδολογία TRUE χωρίζει την ανάπτυξη υπηρεσιoστραφών λύσεων σε τέσσερα τμήματα. Το ένα τμήμα αφορά το πεδίο του οργανισμού και περιλαμβάνει την εξερεύνηση και αξιολόγηση των επιχειρησιακών υπηρεσιών. Τα υπόλοιπα τρία αφορούν το πεδίο της Τεχνολογίας Πληροφορικής για την σχεδίαση τομέων, συστατικών (components) και διεπαφών (interfaces). Τα τμήματα στο πεδίο της Τεχνολογίας Πληροφορικής χρησιμοποιούν τις επιχειρησιακές υπηρεσίες ως δεδομένα εισόδου τους. Στη συνέχεια παρουσιάζονται τα τέσσερα κομμάτια της μεθόδου [18] Μοντελοποίηση Επιχειρησιακών Υπηρεσιών Το 1 ο τμήμα της μεθοδολογίας, που αφορά το πεδίο του οργανισμού, είναι ο προσδιορισμός επιχειρησιακών υπηρεσιών σε διαφορετικά επίπεδα διάσπασης. Στην αρχή προσδιορίζονται οι χονδρόκοκκες ή υψηλού επιπέδου επιχειρησιακές υπηρεσίες και στη συνέχεια οι λεπτόκοκκες ή χαμηλού επιπέδου υπηρεσίες. Οι χοντρόκοκκες υπηρεσίες αποτελούνται από λεπτόκοκκες υπηρεσίες δημιουργώντας μια ιεραρχία. Τα βήματα που ακολουθούνται για την δημιουργία της ιεραρχίας υπηρεσιών είναι με τη σειρά τα ακόλουθα: 1. Στο πρώτο βήμα αναγνωρίζονται οι υψηλού επιπέδου επιχειρησιακές υπηρεσίες. 2. Στο δεύτερο βήμα αναγνωρίζονται οι ενέργειες που γίνονται από την κάθε υψηλού επιπέδου υπηρεσία. Οι ενέργειες αυτές είναι υποψήφιες να θεωρηθούν υπηρεσίες στο επόμενο (πιο λεπτομερές) επίπεδο ανάλυσης

61 3. Στο τρίτο βήμα γίνεται η εκκαθάριση και βελτίωση των υπηρεσιών στις παρακάτω περιπτώσεις: Αν υπάρχουν πολλοί πάροχοι υπηρεσιών. Αν μια υψηλού επιπέδου υπηρεσία καλύπτει πολλούς επιχειρησιακούς στόχους. Αν υπάρχουν επιχειρησιακοί στόχοι που δεν καλύπτονται από τις ως τώρα υπηρεσίες, οπότε ή θα πρέπει να αναλυθούν περισσότερο ή να οριστούν νέες. Τα στάδια αναγνώρισης και εκκαθάρισης-βελτιστοποίησης υπηρεσιών επαναλαμβάνονται μέχρι να φτάσει η ανάλυση σε ικανοποιητικό επίπεδο ή να βρεθούν στοιχειώδεις επιχειρησιακές υπηρεσίες (να μην γίνεται δηλαδή να προχωρήσει η ανάλυση σε χαμηλότερο επίπεδο). 4. Το τελευταίο βήμα είναι ο καθορισμός επιχειρησιακών υπηρεσιών ως περιπτώσεις χρήσης, που συνεπάγεται τον καθορισμό ονόματος αλλά και τον πάροχο και καταναλωτή της υπηρεσίας, τις προϋποθέσεις και τις συνέπειες, τις μη λειτουργικές απαιτήσεις και προβλέψεις για την τροποποίηση (provisioning) των υπηρεσιών. Οι επιχειρησιακές υπηρεσίες μοιάζουν με την συμπεριφορά ενός συστήματος (οργανισμός ή τμήμα οργανισμού) όπως την καταλαβαίνουν οι πελάτες του συστήματος [18] Σχεδιασμός Τομέων Το 2 ο τμήμα της μεθόδου είναι αυτό της σχεδίασης τομέων για την αντιμετώπιση της πολυπλοκότητας της υπηρεσιοστραφούς λύσης του οργανισμού. Για την σχεδίαση των τομέων η μέθοδος χρειάζεται πληροφορίες που παρέχονται από: 1. Τις επιχειρησιακές υπηρεσίες του υψηλού επιπέδου, κύριες και υποστηρικτικές, 2. Τα επιχειρησιακά αντικείμενα που συμπεραίνονται από τις εισόδους και εξόδους των υπηρεσιών 3. Τις επιχειρησιακές διαστάσεις που αντανακλούν τη στρατηγική του οργανισμού, δηλαδή σε ποιους εξωτερικούς φορείς ο οργανισμός παρέχει

62 υπηρεσίες. Έχοντας την παραπάνω γνώση η μεθοδολογία ορίζει τις υψηλού επιπέδου κύριες υπηρεσίες ως αρχικούς τομείς. Στους αρχικούς τομείς εφαρμόζονται επαναληπτικά οι επιχειρησιακές διαστάσεις (διαφορετικά τμήματα του οργανισμού στα οποία χρησιμοποιείται η υπηρεσία) οδηγώντας σε διαφοροποιήσεις μέσα στον ίδιο τομέα με αποτέλεσμα να διασπαστεί. Έπειτα κατατάσσονται τα επιχειρησιακά αντικείμενα στους υπάρχοντες τομείς. Αν κάποιο επιχειρησιακό αντικείμενο χρησιμοποιείται σε περισσότερους από ένα από τους υπάρχοντες τομείς, τότε δημιουργείται ένας νέος για κάθε ένα τέτοιο επιχειρησιακό αντικείμενο. Επίσης, νέοι τομείς δημιουργούνται για κάθε μια από τις υποστηρικτικές και διαχειριστικές υπηρεσίες. Τελευταίο βήμα περιλαμβάνει την ονοματοδοσία τομέων, τον έλεγχος πληρότητας και αποδοχής του μοντέλου τομέων που σχεδιάστηκε [18] Σχεδιασμός Συστατικών Το 3 ο τμήμα της μεθοδολογίας είναι ο σχεδιασμός συστατικών με πρώτο βήμα την αντιστοίχιση των υπηρεσιών από την ιεραρχία των υπηρεσιών του πρώτου κομματιού σε τομείς. Η αντιστοίχιση αφορά τις υπηρεσίες που είναι έστω εν μέρει αυτοματοποιημένες, τις οποίες ονομάζουμε υπηρεσίες εφαρμογών. Στη συνέχεια οι υπηρεσίες εφαρμογών κατηγοριοποιούνται σε υπηρεσίες: Δεδομένων (διαχείριση επιχειρησιακών αντικειμένων). Λειτουργίας (που έχουν αλγοριθμική λογική). Διαδικασίες (που έχουν λογική ροής). Διεπαφής με χρήστες. Έπειτα, για κάθε υπηρεσία σε κάθε τομέα κατασκευάζεται ένα επιχειρησιακό συστατικό (enterprise component). Ως επιχειρησιακό συστατικό ορίζεται το κομμάτι λογισμικού που υλοποιεί ένα μεγάλο τμήμα επιχειρησιακής λογικής και συνδέεται μέσω διεπαφών με άλλα συστατικά. Επόμενο βήμα είναι η βελτιστοποίηση και η εκκαθάριση των επιχειρησιακών συστατικών. Τα κριτήρια που χρησιμοποιούνται είναι τα ακόλουθα: H επιχειρησιακή λογική που μεταβάλλεται με διαφορετικό ρυθμό θα πρέπει να διαχωρίζεται

63 Τα στατικά δεδομένα πρέπει να είναι διαχωρισμένα από τα δεδομένα δοσοληψιών. Τα συστατικά δεν θα πρέπει να έχουν κυκλικές εξαρτήσεις. Τα συστατικά διαφορετικών κατηγοριών θα πρέπει να έχουν εξάρτηση σε στρώματα, όπου το χαμηλότερο στρώμα είναι τα δεδομένα, το επόμενο οι λειτουργίες και το υψηλότερο οι διαδικασίες. Τελευταίο βήμα είναι η οριστικοποίηση του σχεδιασμού σύμφωνα με τις υπηρεσίες που μελετώνται και η κατάλληλη ονοματοδοσία των συστατικών [18] Σχεδίαση Διεπαφών και Ενεργειών Το 4 ο τμήμα της μεθόδου είναι η σχεδίαση διεπαφών και ενεργειών (operations) ξεκινώντας από τις υπηρεσίες που θα πραγματοποιούνται από το πληροφοριακό σύστημα. Κάθε πράξη (action) της υπηρεσίας ορίζεται ως ενέργεια (operation). Οι διεπαφές και οι ενέργειες θα πρέπει να τηρούν κάποιους κανόνες. Οι ενέργειες θα πρέπει να παρέχουν επιχειρησιακή λογική μόνο, και όχι να φανερώνουν τρόπους υλοποίησης, να περικλείουν όσο γίνεται περισσότερη επιχειρησιακή λογική και να έχουν ελάχιστη γνώση του πεδίου στο οποίο χρησιμοποιούνται. Επίσης, το αποτέλεσμα των ενεργειών θα πρέπει να είναι το ίδιο για ίδια δεδομένα εισόδου και για κάθε ενέργεια θα πρέπει να υπάρχει μια που να αναιρεί το αποτέλεσμά της. Χρησιμοποιώντας UML διαγράμματα και συγκρίνοντας τις ενέργειες με ενέργειες του υφιστάμενου πληροφοριακού συστήματος γίνεται η πιστοποίηση των ενεργειών. Οι ενέργειες ομαδοποιούνται σε διεπαφές με πιθανά κριτήρια την ομάδα χρηστών τους και τα δικαιώματα πρόσβασης στις πληροφορίες του οργανισμού [18]. 3.4 Μεθοδολογία SOAF Η μεθοδολογία SOAF παρέχει μια συστηματοποιημένη προσέγγιση και διαδικασία για να καθοδηγήσει το σχεδιασμό, την αξιολόγηση και την ανάπτυξη μιας υπηρεσιοστρεφούς αρχιτεκτονικής. Το γενικό σχήμα της μεθοδολογίας φαίνεται στην παρακάτω εικόνα. Οι φάσεις της μεθόδου παρουσιάζονται και αναλύονται στη συνέχεια [16]

64 Εικόνα 19 - Οι φάσεις της μεθοδολογίας SOAF [16] Φάση 1 η Εκμαίευση Πληροφοριών Η μεθοδολογία θεωρεί ότι η υιοθέτηση SOA λύσεων πρέπει να ξεκινάει με μια από πάνω προς τα κάτω σύλληψη και κατανόηση των κύριων επιχειρησιακών διαδικασιών και την αντιστοίχιση τους σε υπάρχουσες εφαρμογές. Για το σκοπό αυτό ακολουθούνται τα παρακάτω βήματα [16]. Μοντελοποίηση διαδικασίας μετάβασης από την υπάρχουσα σε νέο επιχειρησιακό μοντέλο διαδικασιών (As-is and to-be business process modeling) Το κύριο αποτέλεσμα του πρώτου βήματος είναι ο καθορισμός του πεδίου

65 εφαρμογής, των περιορισμών και των επιχειρησιακών και τεχνολογικών κατευθύνσεων (drivers) της χρήσης της υπηρεσιοστρεφούς αρχιτεκτονικής. Στη συνέχεια γίνεται ορισμός των υπαρχόντων και των νέων μοντέλων επιχειρησιακών διαδικασιών (BPM). Τα μοντέλα BPM αποτελούνται από αποσύνθεση του επιχειρησιακού τομέα σε λειτουργικές περιοχές και επιχειρησιακές περιπτώσεις χρήσης. Τα κυριότερα παραδοτέα αυτής της φάσης είναι: Η επικύρωση των επιχειρησιακών και τεχνολογικών λόγων που οδηγούν στην απόφαση για μετάβαση σε SOA. Το υπάρχον μοντέλο επιχειρησιακών διαδικασιών που τεκμηριώνει το πρόβλημα και περιγράφει σε υψηλό επίπεδο το μοντέλο συνεργασίας μεταξύ των τομέων του οργανισμού. Η κριτική αξιολόγηση του υπάρχοντος επιχειρησιακού μοντέλου που υπογραμμίζει κρίσιμα επιχειρησιακά θέματα και τεχνολογικά προβλήματα σε θέματα απόδοσης, ευκολίας ολοκλήρωσης, συντήρησης και παρωχημένων τεχνολογιών. Το νέο επιθυμητό επιχειρησιακό μοντέλο που περιγράφει την λύση που επιδιώκεται και τις προτάσεις που αφορούν τις αλλαγές στις επιχειρησιακές διαδικασίες. Η αναγνώριση των υποψήφιων επιχειρησιακών υπηρεσιών που θα υποστηρίξουν τις νέες επιχειρησιακές περιπτώσεις χρήσης όπως και την επιχειρησιακή λειτουργικότητα της κάθε υπηρεσίας. Οι υπηρεσίες μπορούν να χωριστούν σε δια-επιχειρησιακές, και εστιασμένες σε επιχειρησιακές γραμμές (Line of Businesses). Η αναγνώριση, κατηγοριοποίηση και ταξινόμηση των μη λειτουργικών απαιτήσεων και των επιχειρησιακών συμφωνιών που αναπαριστώνται με μετρήσιμους δείκτες [16]. Χαρτογράφηση διαδικασιών σε εφαρμογές και αξιολόγηση περιουσιακών στοιχείων Στη φάση αυτή εξετάζονται τα υπάρχοντα πληροφοριακά συστήματα του

66 οργανισμού με στόχο να ανακαλυφθεί σε αυτά λειτουργικότητα που μπορεί να χρησιμοποιηθεί για την πραγματοποίηση επιχειρησιακών υπηρεσιών. Για το σκοπό αυτό γίνεται αντιστοίχιση μεταξύ επιχειρησιακών δραστηριοτήτων και εφαρμογών που χρησιμοποιεί ο οργανισμός. Η αντιστοίχιση αυτή αποτελεί τη βάση για την αναγνώριση εφαρμογών που υποστηρίζουν μια συγκεκριμένη επιχειρησιακή διαδικασία. Επιπρόσθετα, μέσω αυτής της διαδικασίας αντιστοίχισης υπογραμμίζονται πλεονάσματα και επικαλύψεις των εφαρμογών, εφαρμογές που παρέχουν υπηρεσίες σε περισσότερες από μία διαδικασίες του οργανισμού, καθώς επίσης και κενά και υπηρεσίες που χρειάζονται νέα υλοποίηση. Το βήμα περιλαμβάνει τρεις δραστηριότητες: 1. Σύνταξη ενός χαρτοφυλακίου υπαρχόντων εφαρμογών του οργανισμού με στόχο την τεκμηρίωση κρίσιμων χαρακτηριστικών των εφαρμογών, όπως μέγεθος, χρησιμοποιούμενες τεχνολογίες και διεπαφές με άλλες εφαρμογές ή εξωτερικές οντότητες. Για την συγκέντρωση των πληροφοριών χρησιμοποιούνται χειρωνακτικές τεχνικές, όπως συνεντεύξεις, αλλά και αυτοματοποιημένα εργαλεία, όπως το IBM's Asset Analyzer. Για κάθε εφαρμογή υπολογίζεται μία βαθμολογία για τους παρακάτω τομείς: Αξία επιχειρησιακής συμμετοχής, η οποία προσδιορίζεται με βάση την κρισιμότητα της εφαρμογής στην επίτευξη επιχειρησιακών στόχων και στην δημιουργία κέρδους για τον οργανισμό. Όταν η επιχειρησιακή κρισιμότητα, αξία, μιας εφαρμογής είναι μεγάλη, αντίστοιχα μεγάλος είναι και ο κίνδυνος για προβλήματα στην προσπάθεια τροποποίησης της. Λειτουργική επαναχρησιμοποίηση, η οποία δηλώνει αν μια εφαρμογή χρησιμοποιείται ή μπορεί να χρησιμοποιηθεί σε διάφορες επιχειρησιακές διαδικασίες. Αντίστοιχα, όσο μεγαλύτερη η επαναχρησιμοποίηση τόσο μεγαλύτερη η αξία της εφαρμογής. Τεχνολογική υγεία, η οποία μετράει την αξιοπιστία της εφαρμογής στην παροχή της απαιτούμενης λειτουργικότητας και αντοχής σε υψηλό φόρτο. Τεχνολογική ευελιξία, που ορίζει την πολυπλοκότητα, τις απαιτήσεις

67 συντήρησης και την δυνατότητας επέκτασης, δηλαδή πόσο εύκολα μπορεί να τροποποιηθεί η εφαρμογή, ώστε να μπορεί να ακολουθεί της μεταβαλλόμενες επιχειρησιακές απαιτήσεις. Κόστος ιδιοκτησίας της υπηρεσιοστραφούς εφαρμογής σε σχέση με την συντήρηση και την αναβάθμιση λογισμικού και υλικού. 2. Τεκμηρίωση του υπάρχοντος τεχνολογικού μοντέλου του οργανισμού. 3. Δημιουργία χαρτοφυλακίου αξιολογήσεων που θα υποστηρίξει την αναζήτηση χρησιμοποιούμενων συστημάτων κατάλληλων για εξόρυξη υπηρεσιών από αυτά. Τα συστήματα αυτά είναι υποψήφια για περαιτέρω ανάλυση και αξιολόγηση του κόστους και της πολυπλοκότητας τροποποίησης τους. Τα κύρια παραδοτέα-αποτελέσματα της φάσης είναι: Η χαρτογράφηση διαδικασιών σε εφαρμογές (Process-to-Application Mapping). Η λίστα με τις υποψήφιες υπηρεσίες που μπορούν να εξαχθούν από το χαρτοφυλάκιο εφαρμογών. Η λίστα με τμήματα εφαρμογών και λογισμικού που είναι ικανά να τροποποιηθούν, ώστε να παρέχουν υπηρεσίες. Αυτό γίνεται αναζητώντας σημεία επαφής της εφαρμογής που έχουν την λειτουργικότητα που χρειάζεται για να χρησιμοποιηθούν ως διεπαφές για την υπηρεσία. Στη συνέχεια καταγράφονται οι ροές δεδομένων και ελέγχων ανάμεσα στα προγράμματα για να οριστούν τα όρια υλοποίησης της επιχειρησιακής δραστηριότητας [16] Φάση 2 η - Αναγνώριση υπηρεσιών και αντιστοίχιση Στόχος της φάσης είναι να οριστούν καλά τα σύνορα ανάμεσα στα συνεργαζόμενα συστήματα, με ταυτόχρονη μείωση των αλληλεξαρτήσεων και περιορισμό των αλληλεπιδράσεων σε καθορισμένα σημεία της αρχιτεκτονικής, χρησιμοποιώντας τόσο από πάνω προς τα κάτω όσο και από κάτω προς τα πάνω ανάλυση, όπως δείχνει η παρακάτω εικόνα [16]

68 Εικόνα 20 Η φάση αναγνώρισης υπηρεσιών στη μεθοδολογία SOAF [16]. Η από πάνω προς τα κάτω ανάλυση αναδεικνύει τις επιχειρησιακές δραστηριότητες που επιτυγχάνουν κοινούς επιχειρησιακούς στόχους και αποτελούν πιθανές επιχειρησιακές υπηρεσίες. Η διάσπαση των διαδικασιών γίνεται μέσω αναγνώρισης υπηρεσιών που αντιπροσωπεύουν σημεία επικοινωνίας μεταξύ των εταίρων και περιγραφή της συμπεριφοράς της υπηρεσίας ως μαύρο κουτί στον εξωτερικό παρατηρητή, όπως φαίνεται και στην παρακάτω εικόνα. Το αποτέλεσμα που προκύπτει είναι η δημιουργία τόσο ενός εννοιολογικού χάρτη επιχειρησιακών διαδικασιών όσο και η αντιστοίχιση στα συστήματα που θα υλοποιήσουν τις υπηρεσίες. Εικόνα 21 Διαδικασία διάσπασης υπηρεσιών [16]. Επίσης, η μεθοδολογία αναγνωρίζει λειτουργικότητα που παρέχεται από την υπάρχουσα υπολογιστική υποδομή του οργανισμού, μέσω της από κάτω προς τα

69 πάνω ανάλυσης (bottom-up analysis). Τα αποτελέσματα είναι λεπτομερή (fine grained) λειτουργικά στοιχεία. Η αντιπαραβολή των στοιχείων (των 2 παραπάνω προσεγγίσεων) δημιουργεί την λίστα με τις λεπτομερείς λειτουργίες που παρέχει το χαρτοφυλάκιο εφαρμογών. Τα στοιχεία πρέπει να ενοποιηθούν σε πιο χοντρόκοκκες δραστηριότητες που μπορούν να χρησιμοποιηθούν για την υλοποίηση υπηρεσιών που εντοπίστηκαν από την από πάνω προς τα κάτω ανάλυση. Το βήμα ονομάζεται functionality impedance rationalization. Τα κριτήρια που ακολουθούνται για την ενοποίηση της λεπτόκοκκης λειτουργικότητας σχετίζονται με : Τους πίνακες βάσης δεδομένων. Ιδιαίτερα σε πολύ μεγάλα πληροφοριακά συστήματα, η αντιπαραβολή των πινάκων που χρησιμοποιούνται από υπάρχοντα προγράμματα ή στοιχεία λογισμικού, παρέχει ένα πρώτο φίλτρο για τον εντοπισμό σχετιζόμενων προγραμμάτων. Βέβαια, χρειάζεται περαιτέρω λειτουργική ανάλυση για να επιβεβαιωθεί η συσχέτιση. Το κοινόχρηστο ή διαμοιραζόμενο κώδικα. Εργαλεία μπορούν να εντοπίσουν προγράμματα που συνεργάζονται με το πρόγραμμα που μελετάται, όπως και προγράμματα με κοινόχρηστο κώδικα με το υπό μελέτη πρόγραμμα. Με αυτό τον τρόπο μπορούμε να εντοπίσουμε εφαρμογές που σχετίζονται μεταξύ τους, έτσι ώστε να τις ενοποιήσουμε. Τα στοιχεία του Κοινού Μοντέλου Πληροφοριών. Πολλοί οργανισμοί χρησιμοποιούν ένα Κοινό Μοντέλο Πληροφοριών ως αναφορά. Προγράμματα που χρησιμοποιούν ίδια στοιχεία από το Κοινό Μοντέλο Πληροφοριών είναι πιθανό να σχετίζονται μεταξύ τους και να μπορούν να ενοποιηθούν σε ποιο χονδρόκοκκες λειτουργικότητες που να ταιριάζουν με τα αποτελέσματα της από πάνω προς τα κάτω ανάλυσης. Ένα τέτοιο παράδειγμα για μια επιχείρηση μπορεί να είναι η έννοια του πελάτη. Προγράμματα που ενημερώνουν ή αναζητούν τα στοιχεία των πελατών θα μπορούσαν να ενοποιηθούν σε μία οντότητα με όνομα Διαχείριση Στοιχείων Πελάτη

70 Έχοντας τα αποτελέσματα από την από πάνω προς τα κάτω και την από κάτω προς τα πάνω ανάλυση γίνεται προσπάθεια αντιστοίχισης των υπηρεσιών που χρειάζονται (από πάνω προς τα κάτω ανάλυση) και των υπηρεσιών που υπάρχουν (από κάτω προς τα πάνω ανάλυση). Η προσπάθεια αυτή θα αναδείξει υπηρεσίες που χρειάζονται υλοποίηση, υπάρχουσες εφαρμογές που δεν χρειάζονται και λειτουργικότητα που παρέχεται από πολλές εφαρμογές, οπότε πρέπει να αποφασιστεί πια εφαρμογή είναι προτιμότερο να διατηρηθεί. Επίσης, γίνεται και η αναγνώριση επαναχρησιμοποιούμενων υπηρεσιών υποδομής (infrastructure) που υποστηρίζονται από μη υπηρεσιοστραφείς εφαρμογές και που στη συνέχεια θα μπορούσαν να μετασχηματιστούν σε υπηρεσιοστραφείς. Οι υπηρεσίες μπορούν να ταξινομηθούν ανάλογα με το βαθμό επαναχρησιμοποίησής τους ή το πεδίο χρήσης τους [16] Φάση 3 η - Ορισμός Υπηρεσιών και Μοντελοποίηση Η φάση της αναγνώρισης και της αντιστοίχισης υπηρεσιών, περιλαμβάνει τον ορισμό και τη μοντελοποίηση των υπηρεσιών για το οποίο θα πρέπει να γίνουν οι παρακάτω ενέργειες. Προσδιορισμός του μοντέλου πληροφοριών, της διεπαφής της υπηρεσίας, όπως και της δομής και τον τύπο δεδομένων των μηνυμάτων που ανταλλάσσονται, χρησιμοποιώντας μια γλώσσα προσδιορισμού σχήματος. Καθορισμός του μοντέλου συμπεριφοράς της διεπαφής της υπηρεσίας που περιλαμβάνει τις λειτουργίες της υπηρεσίας όπως και τα εισερχόμενα και εξερχόμενα μηνύματά της. Επίσης, θα πρέπει να καθορίζει τα υποστηριζόμενα Μοντέλα Ανταλλαγής Μηνυμάτων. Μοντελοποίηση των υποστηριζόμενων συνομιλιών και της χρονικής ακολουθίας ανταλλαγής μηνυμάτων με την υπηρεσία. Για παράδειγμα μία υπηρεσία τοποθέτησης παραγγελιών μπορεί πριν την τοποθέτηση της παραγγελίας να απαιτεί την ανταλλαγή κάποιων μηνυμάτων για την ταυτοποίηση του χρήστη της υπηρεσίας

71 Προσδιορισμός της πολιτικής για τη δημοσίευση των υποστηριζόμενων πρωτοκόλλων, για τους περιορισμούς στο περιεχόμενο των ανταλασσόμενων μηνυμάτων και των χαρακτηριστικών ποιότητας υπηρεσιών, όπως ασφάλεια, αξιοπιστία, θέματα συναλλαγών (transactional) και διαχείρισης [16] Μέγεθος των Υπηρεσιών H λειτουργικότητα υψηλού επιπέδου δια-επιχειρησιακών διαδικασιών εξάγεται με τη μορφή υπηρεσιών μεγάλου μεγέθους. Αυτές οι υπηρεσίες πραγματοποιούνται με την σύνθεση υπηρεσιών μικρού μεγέθους που έχουν συγκεντρωθεί από τα υπάρχοντα συστήματα ή πακέτα λογισμικού. Η κλίμακα ποσοτικοποιείται από τον συνδυασμό του αριθμού των στοιχείων που καλούνται στη διάρκεια μιας λειτουργίας της υπηρεσίας και του αριθμού των αλλαγών κατάστασης των πόρων που χρησιμοποιούνται. Το βέλτιστο μέγεθος των υπηρεσιών είναι κρίσιμο για την εξασφάλιση της μέγιστης επαναχρησιμοποίησης υπηρεσιών. Για παράδειγμα αν μια υπηρεσία επιστρέφει μεγάλο όγκο δεδομένων είναι πιθανόν να μεταφέρονται πληροφορίες που δεν χρειάζονται, αντίθετα αν τα δεδομένα που επιστρέφονται είναι λίγα και πολύ συγκεκριμένα είναι πιθανό να χρειαστούν περισσότερες της μίας κλήσεις της υπηρεσίας. Η επιλογή του κατάλληλου μεγέθους των υπηρεσιών επιτυγχάνεται ακολουθώντας τα παρακάτω κριτήρια: Ευθυγράμμιση με τον οργανισμό. Οι δημοσιευμένες επιχειρησιακές υπηρεσίες πρέπει να προσθέτουν απτή επιχειρησιακή αξία και να υποστηρίζουν επιχειρησιακές περιπτώσεις χρήσης, παρέχοντας αντιστοίχηση ως προς το επιχειρησιακό μοντέλο. Ευκολία σύνθεσης. Η ενθυλακωμένη λειτουργικότητα μιας υπηρεσίας θα πρέπει να μπορεί να χρησιμοποιείται από διαφορετικά πλαίσια με όσο γίνεται λιγότερο κόπο. Η απευθείας δημοσίευση υπαρχόντων συστημάτων ως υπηρεσίες δεν είναι, συνήθως, βέλτιστη επιλογή για την επίτευξη επαναχρησιμοποίησης. Μείωση των παράπλευρων επιρροών από τις αλλαγές των εφαρμογών. Οι υπηρεσίες θα πρέπει να είναι αυτάρκεις και να ενθυλακώνονται με τέτοιο τρόπο ώστε οι εσωτερικές αλλαγές ή ακόμα και η αντικατάσταση ολόκληρης

72 της υλοποίησή τους να γίνονται με την ελάχιστη τροποποίηση των καταναλωτών υπηρεσιών [16] Φάση 4 η - Πραγματοποίηση Υπηρεσιών Σε αυτή τη φάση ορίζονται στρατηγικές μετάβασης από την υπάρχουσα αρχιτεκτονική στη νέα αρχιτεκτονική, μέσω επαναχρησιμοποίησης, εσωτερική υλοποίηση, εξωτερική υλοποίηση (outsourcing) εφαρμογών και χρήση υπηρεσιών από τρίτους. Το κύριο παραγόμενο αποτέλεσμα της φάσης είναι η τεχνολογική αρχιτεκτονική, που ορίζει παραδοτέα σχετικά με την υλοποίηση υπηρεσιών, φιλοξενία υπηρεσιών και διαχείριση υπηρεσιών και κατευθύνσεις, πρότυπα και προϊόντα που θα χρησιμοποιηθούν στην πραγματοποίηση υπηρεσιών

73 Για τις υπηρεσίες που θα πραγματοποιηθούν από υπάρχοντα συστήματα χρειάζονται στρατηγικές μετατροπής σχετικές με τη δημιουργία προσαρμογέων, περιτυλιγμάτων (wrappers). Επιπλέον χρήσιμη είναι η υιοθέτηση προτύπων (design patterns) όπως Mediators, Factories, Facades. Όλα αυτά αντιστοιχίζονται σε τεχνολογίες και προϊόντα υποστρώματος (middleware). Στην παρακάτω εικόνα φαίνονται οι προσεγγίσεις επαναχρησιμοποίησης των υπαρχόντων συστημάτων. Εικόνα 22 - Προσεγγίσεις πραγματοποίησης υπηρεσιών στη μεθοδολογία SOAF [16]. Οι προσεγγίσεις πραγματοποίησης υπηρεσιών χωρίζονται σε δύο κατηγορίες: 1. Οι μη επιθετικές, ευθυγραμμίζουν την υπάρχουσα λειτουργικότητα με τις επιχειρησιακές ανάγκες μέσω περιτυλιγμάτων και ενδιάμεσων στρωμάτων ευέλικτων τεχνολογιών. 2. Οι επιθετικές τεχνικές σκοπεύουν στον εξορθολογισμό, μέσω ανασχεδιασμού, ανακατασκευής και επανεγκατάστασης των εφαρμογών για να διευκολυνθεί η

74 συντήρηση, επέκταση και διαλειτουργικότητα τους. Επιπλέον, χρειάζεται ανάλυση του υπάρχοντα κώδικα όπως και ανάκτηση και εξορθολογισμός του μοντέλου δεδομένων που χρησιμοποιείται. Ακολουθεί μια επαναληπτική εργασία μετασχηματισμών ώστε να γίνει ο κώδικας περισσότερο σπονδυλωτός για την υλοποίηση υπηρεσιών. Οι μετασχηματισμοί απαιτούν τουλάχιστον την αφαίρεση επικαλύψεων και πλεονασμάτων, αλλά και διάσπαση υπαρχόντων εφαρμογών για την εξόρυξη λειτουργικότητας που δεν είναι άμεσα προσβάσιμη [16] Φάση 5 η - Πλάνο Σχεδιασμού Η συγκεκριμένη φάση περιλαμβάνει τη λεπτομερή σχεδίαση των εργασιών που θα πραγματοποιήσουν την μετάβαση του οργανισμού στην νέα υπηρεσιοστραφή υπολογιστική λύση, όπως και την αναγνώριση των επιχειρησιακών και τεχνολογικών δυσκολιών. Τα αποτελέσματα της φάσης είναι: Προσδιορισμός μοντέλου διακυβέρνησης υπηρεσιών. Πλάνο εγκατάστασης με κατάρτιση λίστας έργων τα οποία πρόκειται να υλοποιηθούν όπως και προσδιορισμός της σειράς με την οποία τα έργα αυτά πρόκειται να υλοποιηθούν. Προϋπολογισμός πόρων. Εκτίμηση κινδύνων. Ανάλυση των συνεπειών ανά έργο με στόχο να μην επηρεαστεί η λειτουργία του οργανισμού κατά τη διάρκεια εκτέλεσης των εργασιών. Σχέδιο απόσυρσης των υπαρχόντων εφαρμογών [16]

75 3.5 Μεθοδολογία SODIUM (Service-Oriented Development In a Unified framework) Η μεθοδολογία SODIUM παρέχει μια ολοκληρωμένη λύση που βασίζεται σε γνωστά πρότυπα υποστηρίζοντας οπτική σύνδεση ετερογενών υπηρεσιών (διαδικτύου, p2p, grid) καθώς και ανάλυση, εκτέλεση, διαχείριση και παρακολούθηση των συνδεδεμένων υπηρεσιών, με ένα ανοιχτό και ομογενοποιημένο τρόπο [19]. Η λύση που παράγει η SODIUM αποτελείται από: Το Γενικευμένο μοντέλο υπηρεσιών Τις Γλώσσες της SODIUM όπως: Visual Service Composition Language (VSCL), Unified Service Composition Language (USCL) και Unified Service Query Language (USQL) Την Πλατφόρμα SODIUM που αποτελείται από τη Visual Service Composition Suite και το Περιβάλλον Εκτέλεσης(Run-time environment) Τα βήματα της μεθοδολογίας σύνδεσης των υπηρεσιών που πρέπει να ακολουθηθούν για τη πραγματοποίηση της λύσης. Διαγραμματικά φαίνονται στην παρακάτω εικόνα τα τμήματα της μεθοδολογίας SODIUM

76 Εικόνα 23 - Τα τμήματα της μεθοδολογίας SODIUM [19] Γενικευμένο Μοντέλο Υπηρεσιών (GeSMO) Το γενικευμένο μοντέλο υπηρεσιών περιλαμβάνει την περιγραφή των χαρακτηριστικών και των ιδιοτήτων που έχει κάθε τύπος υπηρεσίας που απευθύνεται η μεθοδολογία. Αποτελεί σημείο αναφοράς για τις VSCL, USQL και USCL προσδιορίζοντας θέματα που είναι κοινά ανάμεσα σε αυτές τις γλώσσες. Η στρωματοποιημένη προσέγγιση του μοντέλου ορίζει τις προδιαγραφές ενός βασικού επιπέδου που περιέχει όλα τα κοινά θέματα σχετικά με το κάθε είδος των υπηρεσιών και προβλέπει για επιπλέον στρώματα πάνω από το βασικό για τα διαφορετικά χαρακτηριστικά του κάθε τύπου υπηρεσίας. Θέματα όπως Σημασιολογία, Ποιότητα Υπηρεσιών (QoS), Εμπιστοσύνης, Ασφάλειας και Διαχείρισης θεωρούνται ορθογώνια στο μοντέλο υπηρεσιών και εφαρμόζονται σε κάθε επίπεδο, όπως δείχνει η παρακάτω εικόνα [19]

77 Εικόνα 24 - Αναπαράσταση του Γενικευμένου Μοντέλου Υπηρεσίας [19]. Το επίπεδο επέκτασης καλύπτει θέματα, που δεν εμφανίζονται στο βασικό μοντέλο, ομαδοποιώντας σε τρία μέρη αντίστοιχα με τους τρεις ετερογενείς τύπους υπηρεσιών. που: Για το γενικευμένο μοντέλο ως υπηρεσία θεωρείται ένα σύστημα λογισμικού έχει λειτουργικές και μη λειτουργικές ιδιότητες προβάλει μια καθορισμένη συμπεριφορά βρίσκεται σε μια συγκεκριμένη δικτυακή διεύθυνση περιγράφεται σε έγγραφα (documented) είναι προσβάσιμο με μηνύματα από τους χρήστες της υπηρεσίας [19] Γλώσσες της SODIUM VSCL Η Visual Service Composition Language είναι μια οπτική (visual) γλώσσα για τον καθορισμό σύνθεσης υπηρεσιών, από ετερογενείς υπηρεσίες. Η VSCL ακολουθεί εννοιολογικό μεταμοντέλο ανεξάρτητο από τη UML και άλλες γραφικές γλώσσες μοντελοποίησης. Τα κύρια σημεία του μεταμοντέλου είναι οι εργασίες και η ροή δεδομένων και ελέγχου ανάμεσα στις εργασίες

78 Η έννοια της εργασίας αποτελείται από ένα αφηρημένο (abstract) τμήμα και ένα συγκεκριμένο τμήμα. Μια εργασία μπορεί να είναι τόσο μεγάλη ώστε μπορεί να περιγραφεί λεπτομερώς ως σύνθεση υποεργασιών. Το αφηρημένο τμήμα είναι ανεξάρτητο υπηρεσίας και μπορεί να χρησιμοποιηθεί ως αρχικό σημείο αναζήτησης διαθέσιμων και σχετικών υπηρεσιών. Το συγκεκριμένο τμήμα έχει πληροφορίες για το ποιες υπηρεσίες εκτελούνται για την εργασία. Το θετικό της έννοιας της εργασίας είναι ότι υπάρχει μόνο ένα διάγραμμα σύνθεσης υπηρεσιών και όχι δυο (αφηρημένο και συγκεκριμένο). Το αφηρημένο τμήμα μπορεί να χρησιμοποιηθεί στη συνέχεια για να ελεγχθεί αν νέες και καταλληλότερες υπηρεσίες αναπτύχθηκαν και μπορούν να χρησιμοποιηθούν για την εργασία. Για την επίτευξη σύνδεσης μεταξύ των υπηρεσιών, με ανταλλαγή δεδομένων, έχει προβλεφθεί η δυνατότητα περιγραφής των μετασχηματισμών των δεδομένων. Η VSCL περιγράφει επίσης θέματα QoS και Σημασιολογίας των εργασιών, δεδομένα που χρησιμοποιούνται από την Unified Service Query Engine στην αναζήτηση υπηρεσιών. Οι ετερογενείς συνθέσεις υπηρεσιών πρώτα μετατρέπονται στη γλώσσα USQL και έπειτα εκτελούνται από την μηχανή εκτέλεσης της μεθοδολογίας [19] USQL Η Unified Service Query Language (USQL) χρησιμοποιείται για να εκφράσει ο χρήστης τις απαιτήσεις που έχει από τις υπηρεσίες με τρόπο ανεξάρτητο υπηρεσιών, ώστε να εντοπιστούν υπάρχουσες, καταχωρημένες υπηρεσίες στο σύστημα. Η USQL έχει σχεδιαστεί για να εντοπίζει υπηρεσίες διαφόρων τύπων, όμως στα πλαίσια υλοποίησης της SODIUM υπάρχει υποστήριξη μόνο για υπηρεσίες διαδικτύου, p2p και grid. Η USQL βασίζεται σε XML και παρέχει φορμαλισμό στην περιγραφή αιτήσεων και αποκρίσεων αναζήτησης υπηρεσιών, με ομογενοποιημένο τρόπο ώστε αυτός που αναζητά μια υπηρεσία να εστιάζει στην λειτουργικότητα που χρειάζεται από την υπηρεσία και όχι σε λεπτομέρειες υλοποίησης της [19]

79 USCL H Unified Service Composition Language, βασιζόμενη και αυτή σε XML, μπορεί να θεωρηθεί ως μια γλώσσα για την περιγραφή και την εκτέλεση συνθέσεων από διάφορων ειδών υπηρεσίες. Εκτός από την περιγραφή των χαρακτηριστικών διεπαφής των υπηρεσιών παρέχει και δυνατότητα μοντελοποίησης του τύπου τους (web, grid. P2p). Με αυτά χτίζεται μια βιβλιοθήκη από επαναχρησιμοποιούμενες περιγραφές υπηρεσιών, προσβάσιμες από ετερογενείς μηχανισμούς και πρωτόκολλα. Μόλις οι υπηρεσίες εντοπιστούν η USCL παρέχει ένα ισχυρό σύνολο εντολών για την σύνδεσή τους. Οι συνθέσεις μοντελοποιούνται ως διαδικασίες, οπότε η USCL περιγράφει την ροή ελέγχου και δεδομένων μεταξύ των υπηρεσιών της διεργασίας. Η περιγραφές των ροών ελέγχου και δεδομένων είναι ορθογώνιες μεταξύ τους. Η γλώσσα USCL υποστηρίζεται από το οπτικό περιβάλλον ανάπτυξης της SODIUM εγγράφων για την εύκολη σύνταξή τους [19] Μεθοδολογία SODIUM Η μεθοδολογία SODIUM σκιαγραφεί τον τρόπο σύνθεσης νέων υπηρεσιών βασιζόμενη σε υπάρχουσες και διαθέσιμες υπηρεσίες με σκοπό την εκτέλεση μιας πιο περίπλοκης εργασίας. Είναι βασισμένη στη UML, και αναπτύσσεται σε τέσσερις επαναληπτικές φάσεις σύμφωνα με το σχήμα

80 Εικόνα 25 - Οι φάσεις της μεθοδολογίας SODIUM [19]. Στη πρώτη φάση ο χρήστης περιγράφει σε αφαιρετικό επίπεδο τις λεπτομέρειες της πολύπλοκης εργασίας και στη δεύτερη φάση χρησιμοποιεί την περιγραφή για να δημιουργήσει επερωτήσεις αναζήτησης υπηρεσιών. Στην τρίτη φάση οι υπηρεσίες που βρέθηκαν, χρησιμοποιούνται για να αντιστοιχιστούν με τις αφηρημένες εργασίες τις οποίες μετατρέπουν σε συγκεκριμένη περιγραφή διαδικασίας. Τόσο η αφηρημένη όσο και η συγκεκριμένη περιγραφή αποθηκεύονται στην σύνθεση. Στη τέταρτη φάση αρκεί η συγκεκριμένη περιγραφή για να μετατραπεί σε εκτελέσιμη και δημοσιευμένη περιγραφή της σύνθεσης που δημιουργήθηκε [19] Πλατφόρμα SODIUM και Εργαλεία Η αρχιτεκτονική της πλατφόρμας SODIUM φαίνεται στην παρακάτω εικόνα

81 Εικόνα 26 - Η πλατφόρμα και τα εργαλεία της SODIUM [19] Visual Service Composition Studio Είναι το περιβάλλον ανάπτυξης για την μοντελοποίηση συνθέσεων υπηρεσιών χρησιμοποιώντας ένα οπτικό συντάκτη. Αποτελείται από τον Visual Editor για την περιγραφή σύνδεσης υπηρεσιών με γραφικό τρόπο με χρήση της VSCL, από τον Language Translator που μετατρέπει την VSCL σε USCL για την δημιουργία εκτελέσιμης περιγραφής, το USQL Dialog με το οποίο οι χρήστες μπορούν να ορίσουν, παρακολουθήσουν, σώσουν και εκτελέσουν USQL επερωτήσεις σχετικές με τις εργασίες στη VSCL σύνθεση και το Visual Composition Graph Analyser που κάνει συντακτικό έλεγχο της σύνθεσης [19] USQL Service Search Engine Είναι το τμήμα υπεύθυνο για την αναζήτηση ετερογενών υπηρεσιών σε διαφορετικούς, πιθανά, μηχανισμούς αρχειοθέτησης τόσο σε χρόνο εκτέλεσης όσο και στην φάση μοντελοποίησης. Παρέχει δυνατότητες αναζήτησης υπηρεσιών, συντακτικού ελέγχου της USQL, διαχείριση τομέα και αρχείου υπηρεσιών [19]

82 USCL Execution Engine Είναι το τμήμα υπεύθυνο για την εκτέλεση και δημοσίευση των συνθέσεων υπηρεσιών που έχουν αποτυπωθεί με την USCL. Διαχειρίζεται την εγκατάσταση, εκτέλεση, καταγραφή και κατάργηση των υπηρεσιών μέσα στην σύνθεση [19] Composition Repository Το συγκεκριμένο τμήμα δίνει την δυνατότητα στο χρήστη να αποθηκεύει και να διαχειρίζεται τις συνθέσεις που έχουν δημιουργηθεί, παρέχοντας αποθηκευτικό χώρο για τις συνθέσεις και μια δικτυακή εφαρμογή για τη διαχείριση του αποθηκευτικού χώρου. Υποστηρίζει αποθήκευση των αρχείων σύνθεσης, έλεγχο των εκδόσεων των συνθέσεων, εύκολο εντοπισμό των συνθέσεων με χρήση μεταδεδομένων, απομακρυσμένη πρόσβαση και έλεγχο πρόσβασης στις συνθέσεις ανάλογα με το ρόλο του χρήστη [19]. 3.6 Μεθοδολογία SOMA (Service Oriented Monteling and Architecture) Η μεθοδολογία SOMA (Service Οriented Μodeling and Αrchitecture) είναι αναπτυγμένη από την εταιρεία ΙΒΜ ως αποτέλεσμα της εμπειρίας που έχει αποκτήσει η εταιρία από τα έργα Πληροφορικής που έχει εκτελέσει σε διάφορες κατηγορίες εταιρειών και οργανισμών. Είναι μια μεθοδολογία που στηρίζεται σε ένα fractal μοντέλο ανάπτυξης λογισμικού και καλύπτει την ανάλυση, το σχεδιασμό, την υλοποίηση και εγκατάσταση-έλεγχο των έργων υπηρεσιοστρεφούς αρχιτεκτονικής, χρησιμοποιώντας όπου χρειάζεται τις βέλτιστες πρακτικές ανάπτυξης λογισμικού. Τα στάδια της μεθοδολογίας SOMA εφαρμόζονται αναδρομικά, με αυτό όμοιο τρόπο στον κύκλο ζωής ενός έργου υπηρεσιοστρεφούς αρχιτεκτονικής [11]

83 3.6.1 Γενική Επισκόπιση Η SOMA ορίζει τις τεχνικές και τους ρόλους των εμπλεκομένων σε ένα υπηρεσιοστραφές έργο. Κατασκευάζει, επίσης μια δομή καταμερισμού εργασιών (WBS) (WorkBreakdownStructure), η οποία περιέχει εργασίες, τις εισόδους - εξόδους των εργασιών καθώς και την καθοδήγηση στην δημιουργία της υπηρεσιοστρεφούς λύσης. Η μέθοδος αποτελείται από επτά fractal φάσεις. Κάθε fractal φάση περιλαμβάνει δραστηριότητες που μπορούν να εφαρμοστούν με διαφορετική σειρά, ανάλογα με τις ανάγκες του οργανισμού, με παρόμοιο τρόπο, σε διαφορετικό στάδιο. Οι δραστηριότητες επαναλαμβάνονται σε κάθε μια από τις εκδόσεις της υπηρεσιοστρεφούς λύσης ή σε μικρούς κύκλους ανάπτυξης. Η SOMA υποστηρίζει τα δύο κυριότερα είδη διακυβέρνησης, αυτό του χρόνου σχεδίασης και αυτό του χρόνου εκτέλεσης. Οι φάσεις της μεθόδου δεν εφαρμόζονται γραμμικά η μία μετά την άλλη. Οι φάσεις εκτελούνται σε μια επαναληπτική και επαυξητική, αλλά ιδιόμορφη προσέγγιση. Η fractal προσέγγιση της μεθόδου στηρίζεται σε δύο αρχές. Η πρώτη αρχή είναι η εφαρμογή δραστηριοτήτων της μεθόδου σε διαφορετικά πεδία της υλοποιούμενης εφαρμογής. Η εφαρμογή των δραστηριοτήτων γίνεται με παρόμοιο τρόπο, προσθέτοντας ενέργειες και λαμβάνοντας υπ' όψη το πεδίο εφαρμογής, αλλά η κεντρική ιδέα της δραστηριότητας παραμένει η ίδια. Επίσης, κάποιες εργασίες μπορεί να επαναλαμβάνονται σε διαφορετικές φάσεις, αλλά όχι σε ίδιο επίπεδο λεπτομερειών, π.χ. απόφαση δημοσίευσης υπηρεσιών τόσο στη φάση Αναγνώρισης όσο και στη φάση Προσδιορισμού. Η δεύτερη αρχή της fractal προσέγγισης είναι οι διαδοχικές επαναλήψεις ανάπτυξης του λογισμικού των υπηρεσιών, σαν το σπειροειδές μοντέλο, εστιάζοντας σε κινδύνους υλοποίησης και εξαρτήσεων μεταξύ των πιθανών προς δημοσίευση υπηρεσιών. Οι κίνδυνοι και οι εξαρτήσεις καθορίζουν την σειρά ανάπτυξης-υλοποίησης των υπηρεσιών και καθορίζουν τις νέες για την επόμενη έκδοση. Οι υπηρεσίες κατατάσσονται σε μια σειρά προτεραιότητας που καθορίζουν την σειρά υλοποίησής τους. Με τις επαναλήψεις νέες πιθανές υπηρεσίες μπορεί να ανακαλυφθούν και να δοκιμαστούν. Η ανάπτυξη της εφαρμογής γίνεται σε επαναλαμβανόμενους κύκλους ανάπτυξης προσθέτοντας και διαφοροποιώντας υπηρεσίες σε κάθε κύκλο ανάπτυξης [11]. Στη συνέχεια γίνεται παρουσίαση των φάσεων της SOMA, και οι οποίες φαίνονται στον παρακάτω πίνακα

84 Διακυβέρνηση χρόνου σχεδίασης ΦΑΣΕΙΣ ΑΠΟΤΕΛΕΣΜΑΤΑ ΕΝΕΡΓΕΙΕΣ Επιχειρησιακή Επιχειρησιακή μοντελοποίηση αρχιτεκτονική και και μοντέλα, μετασχηματισμός προγραμματισμός του μετασχηματισμού, Ωρίμανση της Υπηρεσιοστρεφούς Αρχιτεκτονικής Διαχείριση Υβριδικές λύσεις, έλεγχος Λύσης έργου, επιχειρησιακής αρχιτεκτονικής, επιλογή και ενσωμάτωση λύσης Καθορισμός επιχειρησιακών μοντέλων και αρχιτεκτονικής Έναρξη δραστηριοτήτων διοίκησης έργου Επιλογή προτύπων και λύσεων Επιλογή μεθόδου υιοθέτησης Προσαρμογή μεθόδου παράδοσης

85 Αναγνώριση Αναγνώριση υπηρεσιών, Μοντελοποίηση στόχων- συστατικών, ροών και υπηρεσιών πληροφοριών Επιλογή περιοχών της επιχείρησης Αποσύνθεση τομέων: 1. λειτουργικές περιοχές 2. διεργασίες 3. πληροφορίες 4. κανόνες 5. διαφοροποιήσεις Ανάλυση υπαρχόντων πληροφοριακών συστημάτων Δημιουργία μοντέλου υπηρεσιών Επανέλεγχος και τροποποίηση υπηρεσιών Έλεγχος SLT Προσδιορισμός Υπηρεσιών, συστατικών, Προσδιορισμός υπηρεσιών ροών και πληροφοριών (σύνθεση, ροές, πράξεις, μηνύματα, NFRs) Ανάλυση υποσυστημάτων Προσδιορισμός συστατικών Επανέλεγχος και τροποποίηση υπηρεσιών Υλοποίηση Αποφάσεων, προτύπων Βελτίωση και λεπτομερής λύσεων και προτύπων, περιγραφή συστατικών αναλυτικής SOA Καθορισμός κανόνων αρχιτεκτονικής, εκλογίκευσης πραγματοποιησιμότητας και πρότυπης εφαρμογής Διεξαγωγή ελέγχου πραγματοποιησιμότητας Λεπτομερής περιγραφή των επιπέδων της SOA λύσης

86 Υλοποίηση Δοκιμή Εγκατάσταση, έλεγχος, διαχείριση Κατασκευή, δημιουργία, σύνθεση, ενσωμάτωση, Κατασκευή και σύνδεση υπηρεσιών δοκιμή μονάδων Διεξαγωγή δοκιμής μονάδων Ενσωμάτωση και δοκιμή συστήματος Έκδοση, πρόβλεψη, Εγκατάσταση υπηρεσιών παρακολούθηση Δοκιμές αποδοχής από τους διεργασιών και απόδοσης, χρήστες διαχείριση Παρακολούθηση και διαχείριση διεργασιών και απόδοσης Διακυβέρνηση χρόνου εκτέλεσης Πίνακας 1 - Φάσεις και ενέργειες της μεθοδολογίας SOMA [11] Φάση Μοντελοποίησης Επιχείρησης και Μετασχηματισμού (Business Modeling and Transformation) Στη φάση αυτή η επιχείρηση μοντελοποιείται, προσομοιώνεται και βελτιστοποιείται. Στα πλαίσια των δραστηριοτήτων αυτών εντοπίζεται η περιοχή εστίασης η οποία πρόκειται να μετασχηματιστεί, στην οποία θα τρέξουν τα έργα, χρησιμοποιώντας τα βήματα που παρουσιάζονται στον πίνακα πιο πάνω [11] Διαχείριση Λύσης (Solution Management) Η φάση της διαχείρισης λύσης έχει ως στόχο να υποστηρίξει την δυνατότητα τροποποιήσεων στην υπηρεσιοστρεφή εφαρμογή που θα παραδοθεί στον οργανισμό. Σε έναν οργανισμό οι υπηρεσιοστρεφείς λύσεις μπορεί να υλοποιούνται με διαφορετικούς τρόπους π.χ. υπάρχον σύστημα, νέα υλοποίηση ή ενσωμάτωση έτοιμης λύσης. Για να υποστηρίξει αυτή την υβριδική κατάσταση η SOMA διαχωρίζει τα τμήματα που είναι σταθερά σε έναν τύπο λύσης, από αυτά που δεν είναι κοινά ή σταθερά. Όταν θα παραστεί η ανάγκη για τη χρήση της συγκεκριμένης λύσης, θα μπορούμε εύκολα να χρησιμοποιήσουμε τα σταθερά τμήματα και να συμπληρώσουμε τα μεταβλητά τμήματα. Δημιουργείται έτσι ένα πρότυπο (template) λύσης [11]

87 3.6.4 Φάση Εντοπισμού (Identification Phase) Η φάση αυτή εστιάζει στον προσδιορισμό των υπηρεσιών, των συστατικών (components) και των ροών. Εμπειρικά προκύπτει ότι είναι προτιμότερο να χρησιμοποιηθεί ένα σύνολο συμπληρωματικών τεχνικών για τον εντοπισμό των παραπάνω στοιχείων. Μετά από κάθε ολοκλήρωση της διαδικασίας αναγνώρισης υποψήφιων υπηρεσιών γίνεται έλεγχος και επανασχεδιασμός, ώστε να προκριθούν οι υπηρεσίες για δημοσίευση. Στην διαδικασία αυτή βοηθάει να υπάρχει συνεχής αντιστοίχιση υπηρεσιών και επιχειρηματικών στόχων που αυτές εξυπηρετούν ώστε να αξιολογούνται. Σημαντικό ρόλο έχει η κατανόηση των υπολογιστικών συστημάτων και διαδικασιών που χρησιμοποιεί ήδη ο οργανισμός και των κενών που αυτά δεν καλύπτουν στην λειτουργία του οργανισμού. Αποτέλεσμα είναι η δημιουργία ενός χαρτοφυλακίου πιθανών υπηρεσιών που θα μεταβάλλεται σε κάθε κύκλο εφαρμογής της μεθόδου SOMA. Στη συνέχεια γίνεται αναφορά στις τρεις προσδιορισμού των υπηρεσιών [11]. μεθόδους Διάσπαση Τομέα (Domain Decomposition) Στη τεχνική της διάσπασης τομέα, η μεθοδολογία εστιάζει στην από πάνω προς τα κάτω ανάλυση των επιχειρησιακών τομέων και του μοντέλου των επιχειρησιακών διαδικασιών για να εντοπιστούν υπηρεσίες, συστατικά και ροές. Η ανάλυση γίνεται τόσο στην στατική όσο και στην δυναμική όψη του οργανισμού. Η στατική όψη αποτελείται από γενικές λειτουργικές περιοχές. Μια λειτουργική περιοχή περιγράφεται από τις επιχειρησιακές λειτουργίες για τις οποίες είναι υπεύθυνη, τις επιχειρησιακές οντότητες που συμμετέχουν στην εκπλήρωση των λειτουργιών και τους σχετικούς κανόνες και πολιτικές. Οι τομείς και οι λειτουργικές περιοχές θα είναι οι ιδιοκτήτες των υπηρεσιών. Η δυναμική όψη του οργανισμού περιγράφεται από τις επιχειρησιακές διαδικασίες. Επισημαίνονται διαδικασίες και αναπτύσσεται μία ιεραρχία διαδικασιών για έναν επιχειρησιακό τομέα για να ξεκινήσει η διαδικασία της μοντελοποίησης και της διάσπασης των διαδικασιών. Οι διαδικασίες, οι υποδιαδικασίες και οι δραστηριότητες που γίνονται σε αυτές θεωρούνται υποψήφιες υπηρεσίες για υλοποίηση και δημοσίευση. Ο στόχος της μοντελοποίησης υπηρεσιών είναι η περιγραφή του συστήματος που σχεδιάζεται να υλοποιηθεί με στοιχεία από την υπάρχουσα υποδομή του οργανισμού και γνωστά μοντέλα αναφοράς, καθώς και η βελτιστοποίηση των υπηρεσιών

88 Η διάσπαση τομέα εντοπίζει και τις πληροφορίες που διαρρέουν τον κάθε τομέα. Ο ορολογία των πληροφοριών θα πρέπει να είναι κοινή για όλο τον οργανισμό. Για να συνταχθεί η κοινή ορολογία μελετώνται οι επιχειρησιακές οντότητες του οργανισμού και οι ροές δεδομένων στις επιχειρησιακές διαδικασίες. Όπου ίδιες πληροφορίες αναπαριστώνται με διαφορετικό τρόπο ορίζεται υπηρεσία που θα μετατρέπει τις πληροφορίες στην κοινή δομή για τον οργανισμό. Τα στάδια ζωής των πληροφοριών αναλύονται για πιθανές υπηρεσίες. Οι κανόνες και οι πολιτικές που υπάρχουν σε ένα τομέα του οργανισμού μπορεί να είναι πολύπλοκοι, οπότε πιθανή υπηρεσία θα είναι και αυτή που επιβάλλει και παρακολουθεί τους κανόνες στον τομέα. Η διάσπαση των επιχειρησιακών διαδικασιών εντοπίζει και τις διαφοροποιήσεις στην εκτέλεση μιας επιχειρησιακής διαδικασίας, ώστε να δομηθεί από ποιο λεπτομερή συστατικά που θα βελτιώσουν την επαναχρησιμοποίησή της [11]. Ανάλυση Υπαρχόντων Συστημάτων (Existing Asset Analysis) Στη δεύτερη τεχνική, της ανάλυσης υπαρχόντων συστημάτων γίνεται υψηλού επιπέδου ανάλυση υπαρχόντων συστημάτων, εφαρμογών υπηρεσιών και όποιας άλλης υποδομής διαθέτει ο οργανισμός. Στόχος είναι να αναγνωριστούν υποψήφιες υπηρεσίες, να καταρτιστεί λίστα με τις διαθέσιμες υποδομές και να εντοπιστούν αυτές που πιθανά θα χρησιμοποιηθούν για την υλοποίηση υπηρεσιών από το χαρτοφυλάκιο των υπηρεσιών. Για το σκοπό αυτό γίνεται αντιστοίχηση επιχειρησιακών διαδικασιών και δραστηριοτήτων με τις υπάρχουσες εφαρμογές και τις διεπαφές υπηρεσιών. Πιο συγκεκριμένα, δίνεται προσοχή σε λειτουργίες που παρέχονται από την υπολογιστική υποδομή του οργανισμού, που οδηγούν σε επιχειρησιακές λειτουργίες. Οι επιχειρησιακές αυτές λειτουργίες θεωρούνται υποψήφιες υπηρεσίες [11]. Μοντελοποίηση Επιχειρησιακών Στόχων σε Υπηρεσίες (Goal Service Modeling - GSM)

89 Στην τρίτη τεχνική οι γενικοί στόχοι του οργανισμού διαιρούνται σε μικρότερους στόχους δημιουργώντας μια ιεραρχία. Η αποσύνθεση αυτή των αρχικών στόχων οδηγεί σε ένα σύνολο στόχων ενεργειών οι οποίοι βοηθούν στον εντοπισμό των υπηρεσιών με τις οποίες επιτυγχάνονται οι στόχοι. Είναι σημαντικό να μπορούν αξιολογούνται υπηρεσίες με βάση την αποτελεσματικότητά τους στην επίτευξη του στόχου τους, καθορίζοντας για κάθε στόχο τα κριτήρια επιτυχίας του (KPI Key Performance Indicators). Οι επιχειρησιακοί στόχοι βοηθούν στο να εντοπιστούν ποιες επιχειρησιακές διαδικασίες έχουν την μεγαλύτερη επιρροή στον οργανισμό. Επίσης, επιτρέπει τη διασύνδεση επιχειρησιακών στόχων και υπηρεσιών. Στο GSM γίνεται συνδυασμός των αποτελεσμάτων της αποσύνθεσης τομέα και του προσδιορισμού υπαρχόντων συστημάτων, διότι όλες οι υπηρεσίες θα πρέπει να ικανοποιούν επιχειρησιακούς στόχους του οργανισμού [11]. Αναδόμηση Υπηρεσιών και Εκλογίκευσή (Service Refactoring and Rationalization) Η συγκεκριμένη δραστηριότητα αποτελείται από τρία τμήματα, την αναδόμηση (refactoring) των υπηρεσιών, τον έλεγχο ύπαρξης (service litmus test, SLT) και την εκλογίκευσή (rationalization) τους.. Η αναδόμηση των υπηρεσιών γίνεται με τέτοιο τρόπο ώστε υπηρεσίες χαμηλού επιπέδου που έχουν λογική συγγένεια να ομαδοποιούνται σε μια υψηλότερου επιπέδου υπηρεσία. Δημιουργούνται ιεραρχίες και σχέσεις πατέρα-παιδιού μεταξύ των υπηρεσιών. Όσες υπηρεσίες επιτυγχάνουν στα SLT σχηματίζουν το σύνολο των δημοσιευμένων υπηρεσιών. Το σχέδιο έκδοσης (release plan) της εφαρμογής θα περιλαμβάνει τις εξαρτήσεις μεταξύ υπηρεσιών, ροών, συστατικών και πληροφοριών. Η εκλογίκευση των υπηρεσιών γίνεται με τον επανέλεγχο του μοντέλου υπηρεσιών με τους ενδιαφερόμενους παράγοντες του οργανισμού, ώστε να επιβεβαιωθεί ότι οι υπηρεσίες που πρόκειται να δημοσιευτούν στην επόμενη έκδοση της εφαρμογής είναι αυτές που έχουν σχεδιαστεί, αποφασιστεί και χρηματοδοτηθεί [11]

90 3.6.5 Φάση Προσδιορισμού (Specification Phase) Σε αυτή τη φάση σχεδιάζεται η υπηρεσιοστρεφής αρχιτεκτονική, ολοκληρώνεται η υψηλού επιπέδου σχεδίαση όπως και η λεπτομερής σχεδίαση των πιο σημαντικών συστατικών υπηρεσιών. Με επαναληπτικό και αυξητικό τρόπο, αναλύονται τα υπάρχοντα συστήματα του οργανισμού και επεξεργάζονται οι υπηρεσίες, ροές και συστατικά που εντοπίστηκαν στη φάση της αναγνώρισης ώστε να υπάρχει αρκετή γνώση που θα χρησιμοποιηθεί στη φάση της πραγματοποίησης υπηρεσιών. Η επεξεργασία των υπηρεσιών γίνεται με στόχο την ακόμα μεγαλύτερη μελέτη των εξαρτήσεών τους, των πολιτικών, των λειτουργιών, των μη λειτουργικών απαιτήσεων τους και τα μηνύματα που ανταλλάσσονται. Στην αρχή της φάσης πραγματοποιείται η επεξεργασία και ο καθορισμός του μοντέλου πληροφοριών του οργανισμού και η ανάλυση και προδιαγραφή σε μεγαλύτερο βάθος των υπαρχόντων συστημάτων (assets). Στο κομμάτι της επεξεργασίας του μοντέλου πληροφοριών, το μοντέλο πληροφοριών που δημιουργήθηκε στο στάδιο της αναγνώρισης μετατρέπεται σε λογικό μοντέλο δεδομένων που θα χρησιμοποιηθεί στην υλοποίηση των υπηρεσιών. Επίσης, υιοθετείται ένα κοινό μοντέλο ανταλλαγής μηνυμάτων για όλο τον οργανισμό ώστε να αποφεύγονται μετασχηματισμοί δεδομένων ανάμεσα στις υπηρεσίες. Για το κομμάτι της ανάλυσης των υπαρχόντων συστημάτων γίνεται προσπάθεια λεπτομερούς αντιστοίχισης κάθε υπηρεσίας σε τμήμα (διεργασία ή συναλλαγή) της κληρονομημένης εφαρμογής. Ο προσδιορισμός των υπηρεσιών επικεντρώνεται στην επεξεργασία ενός λεπτομερούς σχεδίου της υπηρεσίας. Οι υπηρεσίες, τα συστατικά και οι εφαρμογές από τις οποίες εξαρτάται μια υπηρεσία όπως επίσης και η ροή εργασιών ανάμεσα στις υπηρεσίες αποτελούν την χορογραφία της υπηρεσίας. Οι λειτουργίες μιας υπηρεσίας που χρησιμοποιούνται για να επιτελέσουν ένα επιχειρησιακό έργο αποτελούν κομβική προσθήκη στο μοντέλο υπηρεσιών. Δεν δημοσιοποιούνται όλες οι λειτουργίες μιας υπηρεσίας αλλά μόνο αυτές που χρειάζονται. Οι λειτουργίες της υπηρεσίας περιγράφονται στο wsdl κατά την υλοποίηση. Εκτός από τις λειτουργίες εντοπίζονται και οι μη λειτουργικές απαιτήσεις της υπηρεσίας

91 Εκτός από την ιεραρχική σύνδεση και συσχέτιση των υπηρεσιών, για τους σκοπούς της μεθοδολογίας για κάθε ομάδα σχετιζόμενων υπηρεσιών κατασκευάζεται διάγραμμα που περιγράφει το οικοσύστημά τους (καταναλωτές υπηρεσιών, παρόχους και ροή μηνυμάτων ανάμεσα σε αυτές και ανάμεσα σε αυτές και τα συστήματα που τις υλοποιούν). Επίσης, αντιστοιχίζονται οι παράμετροι των λειτουργιών των υπηρεσιών με τις παραμέτρους στα υπάρχοντα συστήματα ώστε να μπορούν να υλοποιηθούν από αυτά. Με αυτό τον τρόπο αναδεικνύονται τα κενά που υπάρχουν στην χρησιμοποίηση υπαρχόντων συστημάτων. Τα μηνύματα που μεταφέρουν τις παραμέτρους ανάμεσα στις υπηρεσίες μπορεί να είναι μιας κατεύθυνσης (ο αποστολέας προωθεί το μήνυμα στον παραλήπτη καταβάλλοντας τη βέλτιστη προσπάθεια) ή να είναι ερωταποκρίσεις. Στο πλαίσιο της πιο λεπτομερούς ανάλυσης που γίνεται στη φάση αυτή πραγματοποιείται ο καθορισμός υποσυστημάτων, δηλαδή ορισμός λογικών τεχνικών ορίων για την επιχειρησιακή λειτουργικότητα. Οι λειτουργικές περιοχές και τα υποσυστήματα που υπάρχουν αναπροσαρμόζονται σε ένα σύνολο από γενικών συστατικών(components) υπηρεσιών. Για την καλύτερη αναπαράσταση των υποσυστημάτων δημιουργείται ένας διάγραμμα εξαρτήσεων μεταξύ των υποσυστημάτων και των υπαρχόντων εφαρμογών του οργανισμού. Τα συστατικά των υπηρεσιών προσδιορίζονται με τέτοιο τρόπο ώστε να εκφράζουν ένα σύνολο λειτουργικών συστατικών. Με την χρήση της μεθόδου αντικειμενοστραφούς ανάλυσης και σχεδίασης σε κάθε υποσύστημα είναι δυνατόν να προσδιοριστούν τα συστατικά υπηρεσιών που θα υλοποιήσουν το υποσύστημα [11] Φάση Πραγματοποίησης (Realization Phase) Σε αυτή τη φάση γίνεται μελέτη για το κατά πόσο εφικτή είναι η πραγματοποίηση της λύσης. Για το σκοπό αυτό μελετάται η τεχνική δυνατότητα εφαρμογής της σχεδίασης μέσω των πρωτοτύπων που έχουν κατασκευαστεί νωρίτερα. Τα πρωτότυπα συνεχώς επεκτείνονται. Σε αυτή τη φάση χρησιμοποιούνται πρότυπα λύσεων από διάφορες κατηγορίες για να αντιμετωπιστούν σχετικά προβλήματα, όπως για την ενοποίηση σεναρίων. Μεγάλη προσοχή δίνεται στα τμήματα της αρχιτεκτονικής που έχουν μεγάλη επίπτωση σε μη λειτουργικές απαιτήσεις της εφαρμογής. Κύριο αποτέλεσμα της φάσης είναι να περιγράψει λεπτομερώς και να αρχικοποιήσει την αρχιτεκτονική που θα ακολουθηθεί στην υλοποίηση [11]

92 3.6.7 Φάση Υλοποίησης (Implementation Phase) Στη φάση της υλοποίησης κατασκευάζονται τα συστατικά(components) που υλοποιούν υπηρεσίες, λειτουργικά συστατικά και ροές. Επίσης, κατασκευάζονται και οι απαραίτητοι μηχανισμοί για την ενσωμάτωση των υπαρχόντων συστημάτων στην νέα υπηρεσιοστρεφή εφαρμογή. Επιπλέον, αν απαιτείται, τροποποιούνται υπάρχοντα συστήματα ώστε να συμμετάσχουν στην υλοποίηση μιας υπηρεσίας. Για όλα τα παραπάνω η SOMA χρησιμοποιεί πρότυπα λύσεων που προσφέρουν υποστήριξη για εξειδικευμένη υλοποίηση, ολοκλήρωση με άλλες εφαρμογές, διενέργεια μετασχηματισμών των δεδομένων κλπ. Για την εγκατάσταση και παρακολούθηση της εφαρμογής επίσης χρησιμοποιούνται πρότυπα λύσεων που υποστηρίζουν το πακετάρισμα της εφαρμογής, τις δοκιμές και την εγκατάσταση της εφαρμογής στο παραγωγικό περιβάλλον. Οι τεχνικές εφαρμόζονται σε τμήματα της εφαρμογής και στη συνέχεια επεκτείνονται σε όλο το σύστημα [11]. 3.7 Μεθοδολογία SOSE (Service Oriented Software Engineering) Η μεθοδολογία SOSE έχει ως στόχο να αποτελέσει ένα εργαλείο σχεδίασης λογισμικού είτε για υπηρεσιοστρεφείς, είτε για προσανατολισμένες σε στοιχεία (components), είτε για επιχειρησιακά προσανατολισμένες αρχιτεκτονικές λογισμικού. Επιπλέον παρέχει μια μεθοδολογία η οποία ξεκινώντας από τις επιχειρησιακές απαιτήσεις, τις μετατρέπει σε επιχειρησιακές περιπτώσεις και στη συνέχεια σε λογισμικό υπηρεσιών ή στοιχείων (components). Κλειδί στη μεθοδολογία SOSE είναι η δημιουργία επιχειρησιακών περιπτώσεων λογισμικού (software business case) εφαρμόζοντας μια από πάνω προς τα κάτω προσέγγιση, όπου κάθε επιχειρησιακός τομέας αποτελεί ένα ξεχωριστό πρόβλημα, του οργανισμού. Η προσέγγιση ακολουθεί τα παρακάτω βήματα: Διάσπαση του οργανισμού σε τμήματα και επιχειρησιακές απαιτήσεις. Μετατροπή επιχειρησιακών απαιτήσεων σε απαιτήσεις λογισμικού που περιγράφονται με επιχειρησιακές διαδικασίες, περιπτώσεις χρήσης και μοντελοποίηση υπηρεσιών

93 Σχεδιασμός και υλοποίηση των υπηρεσιών και της κατανεμημένης επικοινωνίας τους. Ως επιχειρησιακή περίπτωση λογισμικού ορίζεται η συλλογή σχετικών επιχειρησιακών πληροφοριών που μπορούν να χρησιμοποιηθούν για να καθοριστούν έννοιες όπως οι ενδιαφερόμενοι φορείς, το εύρος ενός προϊόντος λογισμικού, μία υπηρεσία ή ένα έργο, η ανάλυση της αγοράς, οι ανταγωνιστές, τα κόστη, τα οφέλη και τα ρίσκα [17] Λόγοι Χρήσης Επιχειρησιακών Περιπτώσεων Λογισμικού Η ανάλυση και η δημιουργία επιχειρησιακών περιπτώσεων λογισμικού είναι απαραίτητη για να ελαχιστοποιηθεί το κενό ανάμεσα στους μηχανικούς λογισμικού και στους εκπροσώπους του οργανισμού που καθορίζουν τις επιλογές του. Οι επιχειρησιακές περιπτώσεις λογισμικού μπορεί να περιέχουν διαφορετικές κάθε φορά πληροφορίες ανάλογα με τον οργανισμό. Ωστόσο υπάρχουν, για όλους τους οργανισμού, κάποιες κοινές πληροφορίες, οι οποίες σχετίζονται με το πεδίο της εφαρμογής του λογισμικού, τους κρίσιμους παράγοντες, τις απαιτήσεις πόρων, την ανάλυση κόστους-κέρδους, την ανάλυση αγοράς-ανταγωνιστών, τα επιχειρησιακά κέρδη, την αξιολόγηση πιθανών προμηθευτών, τον υπολογισμό κύκλου ζωής λογισμικού και τις τεχνολογικές πλατφόρμες των πελατών του οργανισμού. Οι επιχειρησιακές περιπτώσεις λογισμικού είναι χρήσιμες και πρέπει να χρησιμοποιούνται από όλους όσους συμμετέχουν στην ανάλυση, σχεδίαση και ανάπτυξη της εφαρμογής, διότι αυτές ουσιαστικά περιγράφουν το στόχο που πρέπει να επιτευχθεί. Η δημιουργία των επιχειρησιακών περιπτώσεων λογισμικού γίνεται στα αρχικά στάδια της μεθόδου όπως δείχνει και η παρακάτω εικόνα [17]

94 Εικόνα 27 Διαδικασία Ανάπτυξης της Μεθοδολογίας SOSE [17]. Αρχικά, οι επιχειρησιακοί αναλυτές συγκεντρώνουν όλες τις σχετικές επιχειρησιακές απαιτήσεις, απαιτήσεις λογισμικού και τις επιχειρησιακές διαδικασίες των πελατών. Στο σημείο αυτό ένας τεχνικός λογισμικού θα μπορούσε να προβάλει μια επιχειρησιακή περίπτωση με την δικιά του άποψη για τις εναλλακτικές τεχνολογικές επιλογές. Έπειτα, από κοινού οι επιχειρησιακοί αναλυτές και οι τεχνικοί λογισμικού μετατρέπουν τις επιχειρησιακές απαιτήσεις σε απαιτήσεις λογισμικού χρησιμοποιώντας περιπτώσεις χρήσεις UML. Οι περιπτώσεις χρήσεις θα χρησιμοποιηθούν και στη συνέχεια για να εντοπιστεί η επαναχρησιμοποίηση λογισμικού και να οργανωθούν δοκιμές συστήματος. Στη συνέχεια γίνεται πιο αναλυτική μελέτη των περιπτώσεων χρήσης αναγνωρίζοντας προαπαιτούμενα, αποτελέσματα, βασικές και εναλλακτικές ροές, που θα πρέπει να ληφθούν υπ' όψη. Τέλος, πραγματοποιείται η διαδικασία κωδικοποίησης, εγκατάστασης ελέγχου της υπηρεσιοστραφής λύσης [17] Μετατροπή Επιχειρησιακών Περιπτώσεων σε Αρχιτεκτονική Λογισμικού Το δεύτερο σημαντικό κομμάτι που προβάλει η μεθοδολογία είναι ο

95 σχεδιασμός υπηρεσιών και συστατικών, ο οποίος πραγματοποιείται μετά την δημιουργία των επιχειρησιακών περιπτώσεων. Για τον σκοπό αυτό γίνονται δύο παράλληλες εργασίες που στο τέλος τα αποτελέσματά τους συνδυάζονται. 1η Εργασία (Γραμμή Λειτουργιών) Στην πρώτη εργασία, γραμμή λειτουργιών, καθορίζονται οι επιχειρησιακές διαδικασίες και οι περιπτώσεις χρήσεις. Η δομή της υπηρεσίας αποκαλύπτεται και περιγράφεται ως χάρτης υπηρεσιών σε επίπεδο συστήματος. Αρχικά, λοιπόν, το σύστημα διασπάται από πάνω προς τα κάτω ξεκινώντας με την περιγραφή των επιχειρησιακών απαιτήσεων ως επιχειρησιακές διαδικασίες. Οι επιχειρησιακές διαδικασίες περιγράφονται ως μία περίπτωση χρήσης, που αντιπροσωπεύει μια επιχειρησιακή διαδικασία και μπορεί να έχει περισσότερες υποπεριπτώσεις χρήσης. Το μοντέλο περιπτώσεων χρήσης αλλάζει στη διάρκεια του χρόνου ανάλογα με τους στόχους του οργανισμού, οπότε πρέπει να υπάρχουν δύο μοντέλα, το τωρινό και αυτό που θέλει να πετύχει ο οργανισμός. Οι κυριότερες διαδικασίες, στη συνέχεια, σχηματίζουν τον χάρτη των επιχειρησιακών διαδικασιών σε επίπεδο συστήματος. Από τον παραπάνω χάρτη σχηματίζεται ο χάρτης των υπηρεσιών, αφού κάθε διαδικασία χρειάζεται μια τουλάχιστον υπηρεσία για να υλοποιηθεί. Έπειτα, οι υπηρεσίες επιχειρησιακού επιπέδου δομούν το πληροφοριακό μοντέλο του οργανισμού και οι υπηρεσίες μοντελοποιούνται πληρέστερα χρησιμοποιώντας σενάρια. Τελικά, οι υπηρεσίες αποτελούνται από διαδικασίες, άλλες υπηρεσίες και υπάρχοντα συστήματα. 2η Εργασία (Γραμμή Πληροφοριών) Στη δεύτερη παράλληλη εργασία περιγράφεται το κύριο και σταθερό πληροφοριακό μοντέλο του οργανισμού, σε αντιστοιχία με τις υπηρεσίες επιχειρησιακού επιπέδου. Για να επιτευχθεί αυτό αναζητούνται τα δεδομένα μέσα στον οργανισμό που θα υποστηρίξουν την λειτουργία των υπηρεσιών και οι επιχειρησιακές οντότητες τοποθετούνται ως δομικά στοιχεία των υπηρεσιών [17] Τελική Σχεδίαση Στο τελικό στάδιο κάθε υπηρεσία μοντελοποιείται ως επιχειρησιακό συστατικό υπηρεσίας, το οποίο αποτελείται από τέσσερα ιεραρχικά επίπεδα, το

96 πρώτο παρέχει την διεπαφή προς άλλες υπηρεσίες, το δεύτερο τα συστατικά διαδικασιών, το τρίτο τις επιχειρησιακές οντότητες και άλλα υπάρχοντα συστήματα που χρησιμοποιεί και τέλος τα τμήματα που παρέχουν υποστηρικτικό ρόλο στη λειτουργία των συστατικών. Για την πρόσβαση στις υποστηρικτικές λειτουργίες χρειάζεται συντονισμός αφού μπορεί να είναι κοινές ανάμεσα σε υπηρεσίες. Αφού σχηματιστούν, τα επιχειρησιακά συστατικά υπηρεσίας ομαδοποιούνται σε συστατικά επιπέδου συστήματος που χρειάζονται στις επιχειρησιακές διαδικασίες. Η εργασία των συστατικών επιτυγχάνεται χρησιμοποιώντας άλλα συστατικά και διαμεσολαβητές σε κληρονομημένα συστήματα του οργανισμού. Έπειτα, αναγνωρίζονται οι επιχειρησιακές οντότητες ώστε να καλύπτονται οι απαιτήσεις του επιχειρησιακού μοντέλου πληροφοριών. Τέλος το σταθερό μοντέλο (platform independent model PIM) σχηματίζεται ώστε να διατηρείται η ακεραιότητα, και πάνω σε αυτό το εξειδικευμένο μοντέλο (Platform specific model PSM). Τα μοντέλα συστατικών βρίσκονται σε τρία επίπεδα: συστήματος, επιχειρησιακών υπηρεσιών και σε χαμηλό επίπεδο συστατικών [17]. 3.8 Μεθοδολογία Papazoglou (WSLD Web Services Lifecycle Development) Η μεθοδολογία Papazoglou (WSLD - Web Services Lifecycle Development) εστιάζει στην ανάλυση, σχεδίαση και στη δημιουργία μίας υπηρεσιοστρεφούς αρχιτεκτονικής, που αντικατοπτρίζει τις αλληλεπιδράσεις των επιχειρησιακών διαδικασιών με τα διάφορα μέρη του οργανισμού αλλά και με μέρη εκτός του οργανισμού, με σκοπό να επιτευχθούν συνήθεις επιχειρησιακοί στόχοι καθώς και μη λειτουργικές επιχειρησιακές απαιτήσεις. Είναι σημαντικό οι στόχοι και οι απαιτήσεις να καθοδηγούν μια προς τα κάτω σχεδίαση, υλοποίηση και έλεγχο ώστε να μετατραπούν οι επιχειρησιακές διαδικασίες σε εφαρμογές που αυτοματοποιούν και ενσωματώνονται στον οργανισμό. Η μεθοδολογία στηρίζεται εν μέρει σε σχετικές και επιτυχημένες μεθοδολογίες ανάπτυξης όπως η Rational Unified Process και Business Process Modeling. Οι φάσεις της μεθοδολογίας είναι Προγραμματισμός (planning), Ανάλυση και Σχεδίαση, Κατασκευή και δοκιμασία, Πρόβλεψη (provisioning), Ανάπτυξη

97 (deployment), Εκτέλεση και Παρακολούθηση. Εκτός από την φάση του Σχεδιασμού οι υπόλοιπες επαναλαμβάνονται κυκλικά πλησιάζοντας κάθε φορά όλο και πιο κοντά στο τελικό πληροφοριακό σύστημα που θα παραδοθεί στον οργανισμό. Στη συνέχεια παρουσιάζονται αναλυτικά οι φάσεις της μεθοδολογίας [14] Φάση 1 η - Προγραμματισμός Η φάση αυτή καθορίζει τη σκοπιμότητα, τη φύση και το πεδίο της πληροφοριακής λύσης που ταιριάζει στο υφιστάμενο περιβάλλον του οργανισμού. Για το σκοπό αυτό γίνεται ανάλυση των επιχειρησιακών αναγκών σε μετρήσιμους στόχους, ελέγχεται η υπάρχουσα πληροφοριακή υποδομή, γίνεται θεώρηση των απαιτήσεων του νέου περιβάλλοντος και αντιστοίχισή τους σε νέα ή υφιστάμενα συστήματα. Τέλος, γίνεται οικονομική ανάλυση και κατάρτιση σχεδίου ανάπτυξης του λογισμικού [14] Φάση 2 η Ανάλυση Στη φάση αυτή γίνεται ανάλυση των υπαρχόντων διαδικασιών ώστε να δημιουργηθεί ένα χαρτοφυλάκιο διαθέσιμων υπηρεσιών και επιχειρησιακών διαδικασιών, όπως και ανάλυση των πιθανών αλλαγών ώστε να υπολογιστεί το κέρδος επένδυσης στη νέα υπηρεσιοστρεφή λύση. Οι πιθανές αλλαγές καθορίζουν και το μοντέλο διαδικασιών που τελικά θα δημιουργηθεί στον οργανισμό. Σημαντικό αποτέλεσμα της ανάλυσης είναι η επαναχρησιμοποίηση επιχειρησιακής λειτουργικότητας του οργανισμού για την νέα λύση. Για το σκοπό αυτό γίνεται αναγνώριση διαδικασιών, αναγνώριση του πεδίου των διαδικασιών, ανάλυση επιχειρησιακού κενού και ανάλυση της πραγματοποίησης διεργασιών. Στη συνέχεια θα γίνει παρουσίαση των παραπάνω βημάτων [14]

98 Αναγνώριση Διαδικασιών Όταν γίνεται ο σχεδιασμός μιας εφαρμογής, πρέπει πρώτα να αναλυθεί η λειτουργικότητα της εφαρμογής και να αναπτυχθεί σε ένα λογικό μοντέλο του τι κάνει ο οργανισμός, σε επίπεδο επιχειρησιακών διαδικασιών. Επίσης πρέπει να αναζητηθούν και οι υπηρεσίες(λειτουργίες, τι ακριβώς προσφέρουν) που απαιτεί από αυτές ο οργανισμός. Οπότε, σκοπός του βήματος είναι η συνάθροιση των υπηρεσιών σε επιχειρησιακές διαδικασίες. Κλειδί είναι ο εντοπισμός της λειτουργικότητας η οποία είναι αυτάρκης στα πλαίσια μια επιχειρησιακής διαδικασίας όπως και ο διαχωρισμός της λειτουργικότητας που θα πρέπει να αποτελέσει κάποια άλλη επιχειρησιακή διαδικασία. Σε αυτή την προσπάθεια μπορούν να χρησιμοποιηθούν οι σχεδιαστικές αρχές της σύζευξης και της συνοχής. Η αναγνώριση διαδικασιών μπορεί να ξεκινήσει με τη σύγκριση του χαρτοφυλακίου των επιχειρησιακών διαδικασιών με αυτές που ορίζονται από κάποιο πρότυπο (π.χ. RosettaNet's Manage Purchase Order ) [14] Εύρος Διαδικασιών Ως εύρος μιας διαδικασίας προσδιορίζει το που αρχίζει και το που τελειώνει η διαδικασία, τους χρήστες της, τα δεδομένα εισόδου και εξόδου, τις εξωτερικές οντότητες με τις οποίες αλληλεπιδρά η διαδικασία και τέλος τα γεγονότα που προκαλούν την έναρξη της διαδικασίας. Η αναγνώριση του πεδίου της επιχειρησιακής διαδικασίας αποσκοπεί στο να μην δημιουργηθεί μια μονολιθική διαδικασία μιμούμενη μια ολόκληρη εφαρμογή και η οποία θα είναι δύσκολο να συντηρηθεί. Στόχος είναι η λειτουργικότητα να διαμοιραστεί σε διαδικασίες που θα είναι διακριτές αλλά και θα έχουν χαλαρή σύνδεση μεταξύ τους [14] Ανάλυση Επιχειρηματικού Κενού (Business Gap Analysis ) Η ανάλυση επιχειρησιακού κενού αρχίζει με την σύγκριση λειτουργιών, που θα υλοποιηθούν ως υπηρεσίες, με τις λειτουργίες που παρέχει το υπάρχον πληροφοριακό σύστημα του οργανισμού, ώστε τμήματα του πληροφοριακού συστήματος να επαναχρησιμοποιηθούν. Η λειτουργικότητα που δεν καλύπτεται προστίθεται στις αφηρημένες διεπαφές υπηρεσιών/διεργασιών, ως λεπτομέρειες υλοποίησης. Στο τέλος το χαρτοφυλάκιο υπηρεσιών που θα δημιουργηθεί θα είναι συμπλήρωμα ή και θα καλύψει τις υπάρχουσες πληροφοριακές εφαρμογές του οργανισμού [14]

99 Ανάλυση Υλοποίησης Διαδικασιών Στο βήμα αυτό θα πρέπει να αποφασιστεί, με βάση το κόστος, τα κέρδη, το ρίσκο και την απόδοση της επένδυσης για το νέο πληροφοριακό σύστημα, με ποιον τρόπο θα γίνει η υλοποίηση των επιχειρησιακών διαδικασιών. Οι επιλογές είναι: Πρώτα υλοποίηση της υπηρεσίας (Green Field development). Σε αυτήν την επιλογή υλοποίησης πρώτα γίνεται η υλοποίηση της υπηρεσίας και μετά, βάσει της υλοποίησης της, εξάγεται η διεπαφή της. Επιπλέον, γίνεται επιλογή των κατάλληλων τεχνολογιών. Ανάπτυξη από πάνω προς τα κάτω. Σε αυτή την επιλογή υλοποίησης πρώτα διαμορφώνεται η διεπαφή μίας υπηρεσίας και στη συνέχεια χρησιμοποιώντας τη διεπαφή γίνεται υλοποίηση της υπηρεσίας. Το κέρδος της ανάπτυξης υπηρεσιών από πάνω προς τα κάτω είναι η συνοχή της εφαρμογής και των μηχανισμών ενσωμάτωσης στον οργανισμό. Επίσης, είναι, σχετικά, εύκολο να αναπτυχθεί η υπηρεσιοστρεφής λύση ακολουθώντας τον τρόπο που αναπτύσσεται ο οργανισμός. Προβλήματα της συγκεκριμένης επιλογής υλοποίησης είναι πιθανώς το αυξημένο κόστος ανάπτυξης της λύσης καθώς και η δυσκολία να διατηρηθεί η υπηρεσιοστρεφής αρχιτεκτονική σε όλο το βάθος του οργανισμού. Ανάπτυξη από κάτω προς τα πάνω. Η συγκεκριμένη επιλογή υλοποίησης υιοθετείται όταν μία νέα διεπαφή υπηρεσίας δημιουργείται από μία υπάρχουσα εφαρμογή του οργανισμού. Η ανάπτυξη αυτή βοηθά στην περίπτωση που υπάρχει ένα ετερογενές τεχνολογικά πληροφοριακό περιβάλλον στον οργανισμό ή χρησιμοποιούνται γρήγορα αναπτυσσόμενες τεχνολογίες. Συνάντηση στη μέση (meet in the middle), όταν υπάρχει ήδη υλοποιημένη μια υπηρεσιοστρεφής διεπαφή και υπηρεσία που καλύπτει τμήματα του οργανισμού και αυτή αντιστοιχίζεται μερικώς σε μια νέα ορισμένη υπηρεσία ή διαδικασία. Δημιουργούνται για το σκοπό περικαλύμματα (wrappers) για τα υπάρχοντα συστήματα. H μέθοδος προσπαθεί να υπερκεράσει τα προβλήματα των 2 προηγούμενων επιλογών

100 Για να αποφασιστεί από ποιες διεργασίες πρέπει να αρχίσει η μεθοδολογία, η μέθοδος πρέπει να επικεντρωθεί σε συγκεκριμένα σημεία και κοινές πρακτικές από άλλα μοντέλα (π.χ. το RosetaNet). Η επιτυχία του σταδίου αυτού θα φανεί στην φάση Πρόβλεψης (provisioning) των υπηρεσιών και στην δυνατότητα επαναχρησιμοποίησης των υπηρεσιών. Αποτέλεσμα της ανάλυσης υλοποίησης διαδικασιών είναι η αναπαράσταση του οργανισμού ως επιχειρησιακές διαδικασίες και ένα σύνολο κανονικοποιημένες επιχειρησιακές λειτουργίες προερχόμενες από αυτές τις διαδικασίες. Για κάθε σενάριο υλοποίησης διαδικασιών μετρώνται χαρακτηριστικά χρησιμοποιώντας μοντέλα όπως το IBM Rational Portofolio Manager [14] Φάση 3 η Σχεδίαση Υπηρεσιών Στη φάση αυτή θα πρέπει για όλα τα συστατικά στοιχεία (components) των υπηρεσιών να προσδιοριστεί ένα σύνολο από συνδεδεμένες, ανεξάρτητες πλατφόρμας, διεπαφές, πριν την κατασκευή των υπηρεσιών. Προσοχή δίνεται τόσο στη δημιουργία και στις προδιαγραφές των ίδιων των υπηρεσιών όσο και στη σύνδεση μεταξύ τους. Οι προδιαγραφές των υπηρεσιών αποτελούνται από: Προδιαγραφές δομής και συμπεριφοράς για τον προσδιορισμό των οποίων πρέπει η διεπαφή υπηρεσίας να αποτελείται από λειτουργίες (port types) που είναι λογικά σχετικές ή λειτουργικά συνεκτικές. Τα μηνύματα σε μια λειτουργία θα πρέπει να συνδέονται με το πρωτόκολλο επικοινωνίας και με την αναπαράσταση πληροφοριών. Η σύζευξη μεταξύ των υπηρεσιών θα πρέπει να είναι ελάχιστη. Επιπρόσθετα, θα πρέπει καθοριστεί το προγραμματιστικό είδος που θα ακολουθηθεί. Γενικά, η επικοινωνία που στηρίζεται στην ανταλλαγή αρχείων (documents) παρέχει χαμηλή σύζευξη αφού ο χρήστης της υπηρεσίας δεν χρειάζεται να γνωρίζει ποια λειτουργία της υπηρεσίας θα πρέπει να χρησιμοποιήσει, την γνώση την έχει και την χρειάζεται μόνο η υπηρεσία που έχει την λειτουργικότητα (το είδος του εγγράφου καθορίζει την λειτουργία)

101 Προδιαγραφές πολιτικών οι οποίες αναφέρονται σε μη λειτουργικές απαιτήσεις των υπηρεσιών και σε θέματα QoS. Τα μη λειτουργικά χαρακτηριστικά της υπηρεσίας περιγράφουν το γενικό πλαίσιο της υπηρεσίας [14] Σύνδεση Υπηρεσιών (Specifying Business Processes) Αφού καθοριστούν οι προδιαγραφές των υπηρεσιών η μεθοδολογία προχωράει στη σύνδεση των υπηρεσιών, εντός του οργανισμού αλλά και με συνεταίρους οργανισμούς. Η σύνδεση γίνεται με βάση της επιχειρησιακές διεργασίες που αυτές θα ικανοποιούν. Επίσης, βελτιώσεις που γίνονται σε ένα κομμάτι του οργανισμού θα πρέπει να γίνονται εκμεταλλεύσιμες και από άλλα τμήματα του οργανισμού με τις κατάλληλες τροποποιήσεις όπου χρειάζεται. Μόλις καθοριστούν οι επιχειρησιακές διαδικασίες και τα όρια τους, θα πρέπει να περιγραφούν θεωρητικά. Για το σκοπό αυτό πρέπει: Να αναδειχθεί η δομή και λειτουργία της διαδικασίας, το πως δηλαδή ο πάροχος των υπηρεσιών να συνδέσει λειτουργίες διαφορετικών υπηρεσιών μεταξύ τους για να πραγματοποιηθεί μια επιχειρησιακή διαδικασία. Η επιχειρησιακές διεργασίες μπορούν να γραφούν με BPEL. Η θεωρητική περιγραφή διαδικασιών περιλαμβάνει την αναγνώριση, ομαδοποίηση και περιγραφή των δραστηριοτήτων που μαζί υλοποιούν μια επιχειρησιακή διαδικασία, με σκοπό να βρεθούν οι υπηρεσίες που θα πρέπει να συνδυαστούν και να συνδεθούν με την διεπαφή της επιχειρησιακής διαδικασίας. Επίσης, χρειάζεται να περιγραφούν εξαρτήσεις, συνθήκες και συγχρονισμός μεταξύ των ενεργειών όπως και η υλοποίηση της επιχειρησιακής διαδικασίας με χρήση BPEL. Να καθοριστεί η σύνδεση της με επιχειρησιακούς ρόλους, ενέργειες και ποιοι επιχειρησιακοί ρόλοι επιδρούν με αυτές, δημιουργώντας με αυτό τον τρόπο την βάση για τη υλοποίηση επιχειρησιακών πολιτικών. Τα μοντέλα διαδικασιών καθοδηγούν την κατασκευή υπηρεσιών ως μέρος των επιχειρησιακών διαδικασιών. Να καθοριστούν τα μη λειτουργικά χαρακτηριστικά, όπως απόδοση, μοντέλο πληρωμής, μοντέλο ασφαλείας και συμπεριφορά συναλλαγών. Οι συμφωνίες

102 επιπέδου υπηρεσιών μπορούν να χρησιμοποιηθούν για τον καθορισμό των χαρακτηριστικών των διαδικασιών. Χωρίς την γνώση των παραπάνω χαρακτηριστικών θα υπήρχαν μη αποδεχτά αποτελέσματα στη σύνδεση και διαχείριση των υπηρεσιών [14] Φάση 4 η Κατασκευή και Δοκιμή Υπηρεσιών Η φάση περιλαμβάνει την περιγραφή της διεπαφής και την περιγραφή της υλοποίησης της υπηρεσίας. Επίσης, σε αντίθεση με τις προηγούμενες φάσεις οι οποίες επικεντρώνονταν στον παραγωγό της πληροφορίας, η φάση αυτή επικεντρώνεται και στους καταναλωτές της. Κατά την δοκιμή των υπηρεσιών επιβεβαιώνονται αν οι απαιτήσεις ικανοποιούνται από το σύστημα και αν τα παραδοτέα βρίσκονται σε αποδεκτό επίπεδο σε σχέση με τα πρότυπα(standards) που έχουν επιλεγεί. Η δοκιμή μπορεί να αναφέρεται σε λειτουργικό έλεγχο ώστε να επιβεβαιωθεί ότι οι υπηρεσίας δίνουν τα αποτελέσματα που αναμένονται, σε δοκιμή που έχει ως επίκεντρο τον έλεγχο της απόδοσης την υπηρεσίας σε on-line συστήματα και την συμπεριφορά της σε περιπτώσεις ανταγωνισμού λόγω ελλιπών πόρων. Επίσης, μπορεί να αναφέρεται σε έλεγχο της σωστής σύνδεσης της υπηρεσίας με τις άλλες και ότι οι ενσωματωμένες σε άλλες υπηρεσίες λειτουργούν σωστά ανεξάρτητα από την υπηρεσία που τις περικλείει [14] Φάση 5 η Πρόβλεψη Υπηρεσιών Η πρόβλεψη υπηρεσιών είναι ένα μείγμα τεχνικών και επιχειρησιακών πτυχών που υποστηρίζουν την χρήση υπηρεσιών από πελάτες και περιλαμβάνουν επιλογές σχετικά με: Διακυβέρνηση υπηρεσιών. Ο στόχος της διακυβέρνησης υπηρεσιών είναι να ευθυγραμμίσει τις στρατηγικές και τις επιταγές του οργανισμού με την τεχνολογική λύση που χρησιμοποιείται. Στη περίπτωση της υπηρεσιοστρεφούς αρχιτεκτονικής αυτό περιλαμβάνει αναφορές και αξιολογήσεις από τα έργα που αναπτύσσονται εσωτερικά και εξωτερικά από την πλευρά των παρόχων υπηρεσιών. Η εσωτερική κριτική μπορεί να αφορά

103 το αν έχουν επιλεχθεί οι κατάλληλες υπηρεσίες για υλοποίηση και αν επιτελούν σωστά την λειτουργία τους. Η διακυβέρνηση των υπηρεσιών θα πρέπει να γίνεται με δομημένο τρόπο, και να περιγράφει κανόνες, διεργασίες, μετρικές για την σωστή διαχείριση των υπηρεσιών σύμφωνα με τους στόχους του οργανισμού. Η διακυβέρνηση μπορεί να είναι κεντρική όπου συμμετέχουν εκπρόσωποι όλων των τμημάτων του οργανισμού ή κατανεμημένη όπου το κάθε τμήμα είναι υπεύθυνο για τις υπηρεσίες που του ανήκουν. Πιστοποίηση υπηρεσιών, η οποία αναγνωρίζει ιδιότητες υπηρεσιών όπως η απόδοση, η ασφάλεια και η επεκτασιμότητα σε μετρικές που καθορίζουν τις υπηρεσίες. Μέτρηση και βαθμονόμηση σε περίπτωση χρέωσης χρήσης των υπηρεσιών. Αυτό μπορεί να γίνεται περιοδικά χρησιμοποιώντας κάποιο μοντέλο μέτρησης. Με βάση τη βαθμονόμηση της υπηρεσίας θα γίνεται και διαφορετική χρέωση στον κάθε χρήστη, ανάλογα με το είδος του, με βάση την συμφωνία παροχής υπηρεσιών που έχει συναφθεί. Στρατηγικές χρέωσης, όπως χρέωση με κάθε χρήση, χρέωση με βάση συνδρομή, με βάση μίσθωση, δωρεάν χρήση, δωρεάν χρήση με κρυφές χρεώσεις και χρέωση για όλη τη διάρκεια ζωής [14] Φάση 6 η Εγκατάσταση (Deployment) Γίνεται εγκατάσταση των υπηρεσιών και δημοσιεύονται οι διεπαφές και οι ορισμοί υλοποίησης τους στον οργανισμό, στους πελάτες και στους συνεργαζόμενους οργανισμούς. Η φάση θεωρείται ξεχωριστή από την υλοποίηση των υπηρεσιών [14] Φάση 7 η Εκτέλεση και Παρακολούθηση

104 Η εκτέλεση επιβεβαιώνει ότι η υπηρεσία χρησιμοποιείται από όλους τους συμμετέχοντες και ο χρήστης της υπηρεσίας μπορεί να αναζητήσει την υπηρεσία και να χρησιμοποιήσει όλες τις λειτουργίες της. Σκοπός της παρακολούθησης, είναι να παρέχει ικανοποιητικά επίπεδα εξυπηρέτησης από την υπηρεσία εντοπίζοντας πιθανή πτώση απόδοσης, αποτρέποντας την ποιότητα να πέσει κάτω από αποδεκτά επίπεδα. Τα μετρικά στοιχεία της ποιότητας της υπηρεσίας (Quality of Service) συγκεντρώνονται με βάση τη συμφωνία επιπέδου της υπηρεσίας (Service Level Agreement) και ο βαθμός εξυπηρέτησης είναι ανάλογος του κάθε χρήστη [14]. 3.9 Μεθοδολογία Chang Η μεθοδολογία του Chang στηρίζεται και προσπαθεί να ικανοποιήσει τα παρακάτω κριτήρια: Mοντελοποίηση της μεταβλητότητας της υπηρεσίας ανάλογα με τον πελάτη της υπηρεσίας και το πλαίσιο χρήσης της. Mοντελοποίηση της αναντιστοιχίας μεταξύ δημοσιευμένων και αναμενόμενων υπηρεσιών. Σχεδιασμός μηχανισμών προσαρμογής στα συστατικά στοιχεία των υπηρεσιών. Υποστήριξη δυναμικής σύνθεσης υπηρεσιών. Στη μεθοδολογία Chang, οι πάροχοι υπηρεσιών δημοσιεύουν υπηρεσίες με το πρότυπο WSDL και οι καταναλωτές υπηρεσιών αναζητούν υπηρεσίες σε αποθετήρια που έχουν υλοποιηθεί με το πρότυπο UDDI. Οι υπηρεσίες σχηματίζουν συνθέσεις υπηρεσιών με χρήση του προτύπου BPEL. Για την μεθοδολογία, η υπηρεσία από την πλευρά του καταναλωτή-χρήστη είναι μια μονάδα λειτουργικότητας με συμφωνημένο επίπεδο εξυπηρέτησης και ποιότητας, ανάμεσα στον καταναλωτή και τον πάροχο. Ο καταναλωτής, δηλαδή την αντιλαμβάνεται ως Υπηρεσία Στόχο. Από τη άλλη για τον πάροχο η υπηρεσία είναι ένα κομμάτι υλοποιημένης λειτουργικότητας, δημοσιευμένη με την WSDL και ονομάζεται Δημοσιευμένη Υπηρεσία. Η Διεπαφή Υπηρεσίας είναι ο αφαιρετικός προσδιορισμός της Δημοσιευμένης Υπηρεσίας δηλαδή ο ορισμός της σημασιολογίας και των υπογραφών των λειτουργιών της. Η υλοποίηση της Διεπαφής της Υπηρεσίας

105 ονομάζεται Συστατικό Στοιχείο (component) της Υπηρεσίας. Η υπηρεσιοστρεφής εφαρμογή αποτελείται από ένα σύνολο λογισμικού και υλισμικού που υποστηρίζει την υπηρεσιοστρεφή αρχιτεκτονική και ονομάζεται Σύστημα Υπηρεσιών. Οι παραπάνω έννοιες που χρησιμοποιούνται στην μεθοδολογία και οι μεταξύ τους σχέσεις παρουσιάζονται στην παρακάτω εικόνα [15]. Εικόνα 28 - Η έννοια της υπηρεσίας στην Chang [15]. Η αρχιτεκτονική αποτελείται από το επίπεδο επιχειρησιακών διαδικασιών, το επίπεδο μονάδων υπηρεσιών, το επίπεδο διεπαφών υπηρεσιών και το επίπεδο συστατικών υπηρεσιών, όπως παρουσιάζεται στην παρακάτω εικόνα. Το επίπεδο επιχειρησιακών διαδικασιών περιγράφει τις επιχειρησιακές διαδικασίες όπως τις αναμένουν οι χρήστες των υπηρεσιών και όχι οι τεχνικοί. Οι επιχειρησιακές διαδικασίες αποτελούνται από μονάδες υπηρεσιών στο επίπεδο μονάδων υπηρεσιών. Η μονάδα υπηρεσίας είναι η μονάδα λειτουργίας (ενέργεια) που αντιστοιχεί σε μία δραστηριότητα της επιχειρησιακής διαδικασίας. Οι μονάδες υπηρεσίας ορίζονται από την πλευρά των τεχνικών και αντιστοιχούν σε ενέργειες αντιληπτές από τον χρήστη της υπηρεσίας. Το επίπεδο διεπαφής υπηρεσιών περιέχει τις περιγραφές WSDL των υπηρεσιών, ώστε αυτές να διαχωρίζονται από τις υλοποιήσεις τους. Το επίπεδο συστατικών υπηρεσιών περιέχει την υλοποίηση της λειτουργικότητας που υπάρχει πίσω από τις διεπαφές

106 Εικόνα 30Τα στρώματα της αρχιτεκτονικής [15]. Εικόνα 29 - Αρχιτεκτονική Διαστρωμάτωση [15]. Η μεθοδολογία επιμένει στην μελέτη των αλλαγών και τροποποιήσεων των υπηρεσιών. Οι υπηρεσίες χρησιμοποιούνται από διάφορους πελάτες, σε διαφορετικές περιπτώσεις και σε διαφορετικό τομέα. Οι διαφοροποιήσεις μπορεί να αντιστοιχούν σε αλλαγές στη ροή εργασιών, στη σύνθεση των υπηρεσιών, ακόμα, και στην επιχειρησιακή λογική της υπηρεσίας. Επίσης, μια χαμηλού επιπέδου υπηρεσία μπορεί να χρησιμοποιείται από μια γενικότερη υπηρεσία αλλά ανάμεσα στις δύο να μην υπάρχει συμφωνία σε επίπεδο λειτουργιών και πλαισίου χρήσης. Το κενό ανάμεσα στις δύο υπηρεσίες μπορεί να οριστεί είτε ως αναντιστοιχία διεπαφών είτε ως αναντιστοιχία λειτουργιών είτε ως αναντιστοιχία μη λειτουργικών αναγκών που έχουν οι υπηρεσίες. Τα δύο παραπάνω στοιχεία οδηγούν στην ανάγκη να προβλέπεται η δυνατότητα προσαρμογής των υπηρεσιών στο ευμετάβλητο περιβάλλον του οργανισμού [15] Οι φάσεις της μεθοδολογίας Η μεθοδολογία στηρίζεται στη κοινή ροή των SOΑD μεθοδολογιών. Αποτελείται από έξι φάσεις που φαίνονται στο παρακάτω σχήμα και παρουσιάζονται

107 στη συνέχεια. Εικόνα 31 Οι φάσεις της μεθοδολογίας Chang [15] Φάση 100. Ανάλυση Υπηρεσιών Στόχων Στόχος της πρώτης φάσης είναι να βρεθούν οι υπηρεσίες στόχοι που θα υλοποιηθούν αργότερα ως στοιχεία υπηρεσιών. Το πρώτο βήμα της φάσης είναι η εύρεση των απαιτήσεων των υπηρεσιών στόχων από τους διάφορους ενδιαφερομένους. Οι υπηρεσίες θα χρησιμοποιηθούν από διάφορους καταναλωτές για αυτό θα πρέπει να οριστεί ένα περιεκτικό σύνολο απαιτήσεων υπηρεσιών τυποποιημένες γύρω από την έννοια της υπηρεσίας (επιχειρησιακό επίπεδο) και όχι της λειτουργικότητας λογισμικού. Το επόμενο βήμα είναι η κατανόηση και η σύγκριση των υπηρεσιακών απαιτήσεων και η εύρεση υπηρεσιών στόχων. Οι υπηρεσίες θα πρέπει να ορίζονται εφαρμόζοντας αποδεκτούς κανόνες ανάλυσης επιχειρησιακών περιπτώσεων ώστε να είναι σωστά ορισμένες και να εξυπηρετούν την επαναχρησιμοποίησή τους. Το τρίτο και τελευταίο βήμα είναι η ανάλυση των επιχειρησιακών διαδικασιών των υπηρεσιών στόχων. Το βήμα περιλαμβάνει τον προσδιορισμό των επιχειρησιακών διαδικασιών (διάγραμμα δραστηριοτήτων) που διεξάγονται σε μια υπηρεσία στόχο. Στη διάρκεια του βήματος είναι σημαντικό να βρεθούν διαφοροποιήσεις της επιχειρησιακής διαδικασίας, διαφορετικές ροές ή προαιρετικές εργασίες. Με την αποτύπωση αυτών των διαφοροποιήσεων στην υλοποίηση των

108 υπηρεσιών αυξάνεται η επαναχρησιμοποίηση και οι δυνατότητες χρήσης των υπηρεσιών [15] Φάση 200. Ορισμός Μονάδων Υπηρεσιών Στόχος της επόμενης φάσης είναι ο εντοπισμός μονάδων υπηρεσιών των επιχειρησιακών διαδικασιών. Αποτελείται από πέντε βήματα και έχει ως αποτέλεσμα δύο παραδοτέα, τις προδιαγραφές των μονάδων υπηρεσιών και την σύνθεση των υπηρεσιών. Στο πρώτο βήμα, οι απορρέουσες μονάδες υπηρεσιών χαρακτηρίζονται από δύο πτυχές τους, την ομοιότητα και τη συνεκτικότητα. Η μονάδα υπηρεσίας θα πρέπει να είναι συνεκτική με τα δεδομένα που χειρίζεται και να μπορεί να χρησιμοποιηθεί σε περισσότερες επιχειρησιακές διαδικασίες. Η δυνατότητα χρήσης της μονάδας σε περισσότερες διαδικασίες, ορίζει και την οικονομική αξία της. Για να πραγματοποιηθεί το βήμα αναλύονται και συγκρίνονται οι προδιαγραφές των επιχειρησιακών διαδικασιών της προηγούμενης φάσης. Το επόμενο βήμα είναι ο προσδιορισμός των μονάδων υπηρεσιών και ορισμός των διεπαφών τους. Οι διεπαφές ορίζονται με αφαιρετικό τρόπο, ανεξάρτητο τεχνολογιών και τελικά μετατρέπονται σε WSDL διεπαφές. Επίσης με χρήση αντικειμενοστρεφούς σχεδιασμού ορίζεται η δομική και συμπεριφοριακή όψη των υπηρεσιών. Επιπλέον, μοντελοποιείται το πλαίσιο των μονάδων υπηρεσιών χρησιμοποιώντας σημασιολογικές αναπαραστάσεις. Το τέταρτο βήμα είναι η σύνθεση των επιχειρησιακών διαδικασιών από τις μονάδες υπηρεσίας. Οι επιχειρησιακές διαδικασίες εκφράζονται με τη γλώσσα BPEL. Οι επιχειρησιακές διαδικασίες προέρχονται από την οπτική του χρήστη των υπηρεσιών, ενώ οι μονάδες υπηρεσιών από την οπτική των τεχνικών. Το βήμα είναι πολύ σημαντικό διότι γίνεται προετοιμασία για την επίκληση των μονάδων υπηρεσιών από τις επιχειρησιακές διαδικασίες. Το πέμπτο βήμα είναι ο προσδιορισμός του μοντέλου απόφασης υπηρεσιών, το οποίο καθορίζει τη μεταβλητότητα των υπηρεσιών ως προς τα σημεία μεταβλητότητας, καταστάσεις, διαφοροποιήσεις και μεθόδων προσαρμογής [15]

109 3.9.4 Φάση 300. Σχεδιασμός της απόκτησης συστατικών υπηρεσιών Στόχος της φάσης είναι η υλοποίηση των συστατικών υπηρεσιών που ικανοποιούν τις μονάδες υπηρεσιών και των μηχανισμών προσαρμογής των υπηρεσιών. Τα βήματα της φάσης είναι τα παρακάτω: Αρχικά, γίνεται αναζήτηση σε υπάρχουσες δημοσιευμένες υπηρεσίες και υπάρχοντα συστήματα καθώς και καθορίζονται οι μέθοδοι για την απόκτηση των υπηρεσιών, είτε μέσω των κληρονομημένων συστημάτων ή αναπτύσσοντας νέες υλοποιήσεις. Παράγοντες που επηρεάζουν την επιλογή είναι το κόστος απόκτησης, το ταίριασμα της λειτουργικότητας, το κόστος προσαρμογής και η ιδιοκτησία υπαρχόντων συστημάτων και υπηρεσιών. Έπειτα, πραγματοποιείται ο προσδιορισμός σημείων - λεπτομερειών που δεν συμπίπτουν μεταξύ μονάδων υπηρεσιών και συστατικών υπηρεσιών σε τεχνικό επίπεδο. Τέλος, γίνεται ο σχεδιασμός της αρχιτεκτονικής του συστήματος προσδιορίζοντας τα συστατικά των υπηρεσιών στόχων, τα συστατικά υπηρεσιών που απαιτούνται από τις υπηρεσίες στόχων και τις αλληλεπιδράσεις τους [15] Φάση 400. Απόκτηση Συστατικών Υπηρεσιών Υλοποιείται το πλάνο απόκτησης των μονάδων υπηρεσιών που δημιουργήθηκε στην προηγούμενη φάση. Οι διεπαφές υπηρεσιών που ήδη είναι δημοσιευμένες συνδέονται σε στοιχεία υπηρεσιών με τη γλώσσα BPEL. Γίνεται ορισμός διεπαφών για τα κληρονομημένα συστήματα σε WSDL, με πιθανή μετατροπή τους λόγο πιθανών αναντιστοιχιών. Τέλος, γίνεται η δημιουργία νέων συστατικών υπηρεσιών που θα σχηματίσουν μονάδες υπηρεσιών [15] Φάση 500. Ανάπτυξη Προσαρμογέα Υπηρεσιών Η φάση ασχολείται με την σχεδίαση μεθόδων δυναμικής προσαρμογής των υπηρεσιών λόγω της μεταβλητότητας και της αναντιστοιχίας τους. Προτείνεται η χρήση ενός Χειριστή Δυναμικών Συνθέσεων και ενός Μετατροπέα Διεπαφών για

110 δυναμική προσαρμογή. Ένας Χειριστής Δυναμικών Συνθέσεων προσφέρει λειτουργίες κλήσης υπηρεσιών, προσαρμογής υπηρεσιών και δέσμευσης δημοσιευμένων υπηρεσιών σε χρόνο εκτέλεσης. Αποτελείται από τον Παρατηρητή Γεγονότων, τον Δρομολογητή Υπηρεσιών, τον Αναλυτή Κατάστασης και τον Μετατροπέα Διεπαφών σύμφωνα με την παρακάτω εικόνα. Η υλοποίηση μετατροπέων που σχεδιάστηκαν σε προηγούμενα στάδια γίνεται επίσης σε αυτή τη φάση. Εικόνα 32 Η αρχιτεκτονική του Χειριστή Δυναμικών Συνθέσεων [15] Φάση 600. Επαλήθευση Σύνθεσης Υπηρεσιών Αφού ολοκληρωθεί η υλοποίηση των δομικών στοιχείων των υπηρεσιών, θα πρέπει να γίνει μία επαλήθευση έλεγχος των συνθέσεων τους. Η επαλήθευση αποτελείται από την επαλήθευση των κλήσεων των συστατικών υπηρεσιών, την επαλήθευση του προσαρμογέα σύνθεσης και την επαλήθευση συνολικά της σύνθεσης ως λειτουργία [15]