Αξιοποιώντας τα ενορατικά/οπτικά (visual) εργαλεία και τη γενικότερη διάδραση και ευχρηστία που παρέχουν τα περιβάλλοντα Eclipse αλλά και NetBeans (μέσω του πακέτου OpenESB), ακολουθούμε και σε αυτό το κεφάλαιο τη μέθοδο εκπαίδευσης από παράδειγμα (example-based learning) για να παρουσιάσουμε σημαντικές έννοιες και τεχνικές σχετικές με την ανάπτυξη, την επιλογή και τη σύνθεση Υπηρεσιών Ιστού (ΥΙ).

Συγκεκριμένα, θα παρουσιαστεί μια μεθοδολογία ανάπτυξης εφαρμογών REST, μέσω του RESTlet framework, μια μέθοδος επιλογής ΥΙ που βασίζεται στην AHP καθώς και η μέθοδος σύνθεσης ΥΙ μέσω του γραφικού περιβάλλοντος που παρέχει το OpenESB και με τη χρήση της γλώσσας BPEL. Η γνώση αυτών των εργαλείων και τεχνικών είναι πολύ σημαντική καθώς, όπως έγινε φανερό και στο προηγούμενο κεφάλαιο, η αξιοποίηση και η χρήση ΥΙ αλλά και συνθέσεων αυτών, καθιστά δυνατή την υποστήριξη τόσο απλών όσο και πιο σύνθετων συναλλαγών Ηλεκτρονικού Εμπορίου.

2. Ανάπτυξη Υπηρεσιών Ιστού REST

2.1. Εισαγωγή στο RESTlet framework

Στην πρώτη ενότητα αυτού του κεφαλαίου θα ασχοληθούμε με τη χρήση ενός framework για την ανάπτυξη RESTful εφαρμογών Ιστού. Το Restlet Framework (http://restlet.com) είναι ένα ανοιχτού κώδικα framework, για την ανάπτυξη API (application programming interface) σε Java (Louvel, J. et al.., 2012). Με τη χρήση του συγκεκριμένου framework, είναι δυνατή η ανάπτυξη εφαρμογών τόσο από την πλευρά του πελάτη, όσο και από την πλευρά του εξυπηρετητή. Παράλληλα, το συγκεκριμένο framework, επιτρέπει την ανάπτυξη εφαρμογών που θα μπορούν να αξιοποιήσουν μια πληθώρα πρωτοκόλλων μετάδοσης, όπως είναι τα HTTP και SMTP αλλά και προτύπων σύνδεσης βάσεων δεδομένων (με κυριότερο το JDBC client).

Το framework αποτελείται από δύο συστατικά μέρη, το Restlet API και το Restlet Engine. Το πρώτο τμήμα προσφέρει την υποστήριξη των εντολών χειρισμού REST κλήσεων ενώ παράλληλα διαχειρίζεται τις κλήσεις για τις client-side και τις server-side εφαρμογές. Το Restlet Engine είναι υπεύθυνο για την εκτέλεση των REST μεθόδων και υποστηρίζει το Restlet API. Συνολικά απαρτίζουν το framework και ενσωματώνονται σε ένα JAR, το “org.restlet.jar”.

Σχήμα 10.1 Αρχιτεκτονική του RESTlet framework

2.2. Ανάπτυξη ΥΙ διαχείρισης λογαριασμών χρηστών

Εκφώνηση:

Αναπτύξτε ΥΙ που να επιτρέπει τον χειρισμό αναπαραστάσεων πόρων. Συγκεκριμένα, θα επιτρέπει τη λήψη, την τροποποίηση και τη διαγραφή στοιχείων μιας λίστας, μέσω HTTP requests.

Για την ανάπτυξη της ΥΙ προτείνεται η χρήση του περιβάλλοντος Eclipse IDE (έκδοση Luna) και του RESTlet framework («http://restlet.com/downloads/current/»).

Σημείωση: Καθώς από έναν απλό φυλλομετρητή είναι δύσκολο να γίνουν HTTP κλήσεις πέραν της GET, είναι απαραίτητη η χρήση κάποιου browser plugin, έτσι ώστε να είστε σε θέση να επιτελείτε όλα τα επιθυμητά HTTP requests (GET, POST, PUT, DELETE). Το προτεινόμενο plugin για τον Mozilla Firefox είναι το HttpRequester, το οποίο είναι διαθέσιμο στη διεύθυνση https://addons.mozilla.org/el/ firefox/addon/httprequester/?src=api και το οποίο εγκαθίσταται σαν toolbar button στον Firefox. Πατώντας το εικονίδιο που δημιουργείται μετά την εγκατάσταση του, είναι δυνατή η κλήση HTTP requests, αλλά και η διατήρηση ιστορικού αυτών.

Υποδειγματική λύση:

Δημιουργία Java Project. Επιλογή File –> New –> Java Project.

Εικόνα 10.1 Δημιουργία νέου Java project

Ονομασία του project: restlestapplication. Ως execution environment, επιλέγουμε το JavaSE-1.7.
Κάνουμε δεξί κλικ στο project μας, επιλέγουμε New->Package και προχωρούμε σε δημιουργία package με την ονομασία client.

Εικόνα 10.2 Δημιουργία νέου package

Επαναλαμβάνουμε τη διαδικασία για 2 ακόμα packages, τα common και server.
Κάνουμε δεξί κλικ στο package client και επιλέγουμε New-> class. Προχωράμε έτσι στη δημιουργία της κλάσης MailClient.

Εικόνα 10.3 Δημιουργία νέας Java class

MailClient.java

package client;

import org.restlet.Client;

import org.restlet.Context;

import org.restlet.data.Protocol;

import common.AccountResource;

import common.AccountsResource;

import common.RootResource;

import org.restlet.resource.ClientResource;

public class MailClient {

public static void main(String[] args) throws Exception {

Client client = new Client(new Context(), Protocol.HTTP);

ClientResource service = new ClientResource("http://localhost:8111");

service.setNext(client);

RootResource mailRoot = service.getChild("/", RootResource.class);

System.out.println(mailRoot.represent());

System.out.println("\n1) Λίστα Ενεργών Χρηστών\n");

AccountsResource mailAccounts = service.getChild("/accounts/",

AccountsResource.class);

String list = mailAccounts.represent();

System.out.println(list == null ? "<Άδεια λίστα>\n" : list);

System.out.println("2) Πρόσθεση νέων χρηστών\n");

mailAccounts.add("Χρήστος Γεωργιάδης");

mailAccounts.add("Νικόλαος Παπαδόπουλος");

mailAccounts.add("Αναστασία Παπαδοπούλου");

mailAccounts.add("Μαρία Γεωργίου");

mailAccounts.add("Κωνσταντίνος Κωνσταντίνου");

mailAccounts.add("Γιώργος Δημητρίου");

mailAccounts.add("Παναγιώτης Παναγιώτου");

mailAccounts.add("Αλίκη Παναγιώτου");

System.out.println("Οκτώ νέοι χρήστες προστέθηκαν!");

System.out.println("\n3) Ενημερωμένη λίστα χρηστών\n");

System.out.println(mailAccounts.represent());

System.out.println("4) Εμφάνιση 5^ου χρήστη\n");

AccountResource mailAccount = service.getChild("/accounts/4",

AccountResource.class);

System.out.println(mailAccount.represent());

System.out.println("\n5) Αλλαγή στοιχείων χρήστη\n");

mailAccount.store("Κωνσταντίνα Κωνσταντίνου");

System.out.println(mailAccount.represent());

System.out.println("\n6) Διαγραφή του 8^ου χρήστη και ανανέωση προβολής της λίστας\n");

mailAccount = service.getChild("/accounts/7", AccountResource.class);

mailAccount.remove();

System.out.println(mailAccounts.represent());

}

Η κλάση MailClient.java, η οποία μπορεί να εκτελεστεί αυτόνομα ως Java application, επιτελεί αυτόματα ενέργειες δημιουργίας – αναβάθμισης – διαγραφής λογαριασμών.

Δημιουργία με την ίδια μέθοδο των κλάσεων AccountResource, AccountsResource και RootResource στο package common.

AccountResource.java

package common;

import org.restlet.resource.Delete;

import org.restlet.resource.Get;

import org.restlet.resource.Put;

public interface AccountResource {

@Get("txt")

public String represent();

@Put ("txt")

public void store(String account);

@Delete

public void remove();

}

AccountsResource.java

package common;

import org.restlet.resource.Get;

import org.restlet.resource.Post;

public interface AccountsResource {

@Get("txt")

public String represent();

@Post("txt")

public String add(String account );

}

RootResource.java

package common;

import org.restlet.resource.Get;

public interface RootResource {

@Get("txt")

public String represent();

}

· Δημιουργία των κλάσεων AccountServerResource, AccountsServerResource, RootServerResource στο package server.

· Δημιουργία της κλάσης MailServerApplication στο package server. Η συγκεκριμένη κλάση είναι η εκτελέσιμη κλάση της εφαρμογής.

AccountServerResource.java

package server;

import common.AccountResource;

import org.restlet.resource.ResourceException;

import org.restlet.resource.ServerResource;

public class AccountServerResource extends ServerResource implements

AccountResource {

private int accountId;

@Override

protected void doInit() throws ResourceException {

this.accountId = Integer.parseInt(getAttribute("accountId"));

}

public String represent() {

return AccountsServerResource.getAccounts().get(this.accountId);

}

public void store(String account) {

AccountsServerResource.getAccounts().set(this.accountId, account);

}

public void remove() {

AccountsServerResource.getAccounts().remove(this.accountId);

}

AccountsServerResource.java

package server;

import java.util.List;

import java.util.concurrent.CopyOnWriteArrayList;

import common.AccountsResource;

import org.restlet.resource.ServerResource;

public class AccountsServerResource extends ServerResource implements

AccountsResource {

private static final List<String> accounts = new CopyOnWriteArrayList<String>();

public static List<String> getAccounts() {

return accounts;

}

public String represent() {

StringBuilder result = new StringBuilder();

for (String account : getAccounts()) {

result.append((account == null) ? "" : account).append('\n');

}

return result.toString();

}

public String add(String account) {

getAccounts().add(account);

return Integer.toString(getAccounts().indexOf(account));

}

RootServerResource.java

package server;

import org.restlet.resource.Get;

import org.restlet.resource.Options;

import org.restlet.resource.ServerResource;

public class RootServerResource extends ServerResource {

@Get ("txt")

public String represent(){

return " ";

}

@Options ("txt")

public String describe(){

throw new RuntimeException("Not yet implemented");

}

MailServerApplication.java

package server;

import org.restlet.Application;

import org.restlet.Restlet;

import org.restlet.Server;

import org.restlet.data.Protocol;

import org.restlet.routing.Router;

public class MailServerApplication extends Application {

public static void main(String[] args) throws Exception {

Server mailServer = new Server(Protocol.HTTP, 8111);

mailServer.setNext(new MailServerApplication());

mailServer.start();

}

@Override

public Restlet createInboundRoot() {

Router router = new Router(getContext());

router.attach("http://localhost:8111/",

RootServerResource.class);

router.attach("http://localhost:8111/accounts/",

AccountsServerResource.class);

router.attach("http://localhost:8111/accounts/{accountId}",

AccountServerResource.class);

return router;

}

Όπως βλέπουμε το IDE μας ενημερώνει για ένα πλήθος σφαλμάτων, που οφείλονται στη χρήση πακέτων που ορίζει το restlet framework. Για να λυθούν λοιπόν θα πρέπει να εισάγουμε το συγκεκριμένο framework στο project.

Προσθήκη της βιβλιοθήκης org.restlet.jar ως external jar file: Αφού κατεβάσουμε το restlet framework από τον σύνδεσμο «http://restlet.com/downloads/current/», και αποσυμπιέσουμε το αρχείο zip, κάνουμε δεξί κλικ στο JRE System Library->Build Path->Configure Build Path->Add external JARs, και επιλέγουμε το org.restlet.jar από τον υπολογιστή μας.

Εικόνα 10.4 Εισαγωγή του org.restlet.jar ως external jar

Εκτέλεση της εφαρμογής στο Eclipse σαν Java Application. Δεξί κλικ στην κύρια κλάση της εφαρμογής (MailServerApplication.java) και επιλέγουμε Run As-> Java Application. Ξεκινάει ο server στο port 8111. Είναι πλέον σε θέση να δεχτεί HTTP requests (GET, POST, PUT, DELETE)

Εκτέλεση με τον ίδιο τρόπο της MailClient.java. Αυτόματα εκτελούνται οι λειτουργίες που ορίσαμε στην κλάση. Συγκεκριμένα:

o Παρουσίαση της λίστας χρηστών (αρχικά κενή) με χρήση ενός GET request (AccountsResource.java) στο http://localhost:8111/accounts/

o Προσθήκη 8 νέων χρηστών που έχουν οριστεί στην κλάση με χρήση POST request (AccountsResource.java) στο http://localhost:8111/accounts/

o Εμφάνιση της ενημερωμένης λίστας χρηστών με τους 8 χρήστες με χρήση GET (AccountsResource.java) στο http://localhost:8111/accounts/

o Εμφάνιση του 5^ου χρήστη http://localhost:8111/accounts/4 ( Καθώς η αρίθμηση ξεκινά από το 0).

o Επικαιροποίηση του 5^ου χρήση με τη χρήση PUT request (AccountResource.java)

o Διαγραφή του 8^ου χρήστη στη σειρά (ξεκινώντας από το 0) με DELETE (AccountResource.java)

Προβολή λίστας χρηστών με GET

o Εισαγωγή του URL http://localhost:8111/accounts/ στον Mozilla Firefox. Εμφάνιση της λίστας χρηστών

o Εναλλακτικά, επιλογή μέσω του HttpRequester plugin, από το drop-down menu της επιλογής GET και αποστολή του HTTP request πατώντας το πλήκτρο Submit. Με τον τρόπο αυτό βλέπουμε την απάντηση στο request μας.

Πρόσθεση χρήστη με κλήση POST

Εικόνα 10.5 Αποτελέσματα προβολής χρηστών μέσω GET (μετά τη διαγραφή του 8^ου χρήστη)

o Στην διεύθυνση http://localhost:8111/accounts/ εισαγωγή στο παράθυρο Content ονόματος χρήστη και επιλογή από το drop-down menu (κάτω από τη γραμμή διεύθυνσης) το POST. Σαν επιλογή στο Content Type επιλέγουμε text/plain και πατάμε το πλήκτρο Submit για την αποστολή του HTTP request.

o Βλέπουμε στο Content το όνομα λογαριασμού που επιλέξαμε. Στο response τμήμα γίνεται φανερό πως ο νέος χρήστης θα έχει ως νούμερο το 7, καθώς είναι ο 8^ος χρήστης και η αρίθμηση ξεκινάει από το 0.

Εικόνα 10.6 Εκτέλεση POST request μέσω HttpRequester plugin

o Για επιβεβαίωση αν ζητήσουμε ένα GET θα λάβουμε τη συνολική λίστα των 8 λογαριασμών.

Διαγραφή λογαριασμού χρήστη με το DELETE

o Επιλέγουμε να διαγράψουμε τον 3^ο λογαριασμό οπότε πληκτρολογούμε στο URL τη διεύθυνση http://localhost:8111/accounts/2.

o Επιλογή του DELETE και πατάμε το πλήκτρο Submit

o Πλέον στη λίστα χρηστών δε θα υπάρχει ο τρίτος χρήστης.

Τροποποίηση λογαριασμού χρήστη με το PUT

o Επιλέγουμε να τροποποιήσουμε τον 1^ο λογαριασμό, οπότε πληκτρολογούμε στο URL τη διεύθυνση http://localhost:8111/accounts/0.

o Πληκτρολογούμε στο πεδίο Content το νέο όνομα του χρήστη και επιλέγουμε PUT και πατάμε το πλήκτρο Submit.

3. Υπολογιστική Νέφους (Cloud Computing) και σχετικά Ζητήματα Ασφάλειας για Εφαρμογές Ηλεκτρονικού Εμπορίου

Τα τελευταία χρόνια η «υπολογιστική νέφους» έχει γίνει κοινά αποδεκτή και υιοθετείται από ολοένα και περισσότερους οργανισμούς, καθώς παρέχει μια εναλλακτική μέθοδο για επιχειρήσεις (αλλά και απλούς χρήστες) αποθήκευσης δεδομένων, επικοινωνίας και λειτουργικότητας. Η τεχνολογία cloud προσφέρει τη δυνατότητα ελαχιστοποίησης των εξόδων μιας επιχείρησης, αφού με το λεγόμενο Software as a Service (SaaS), προσφέρει ένα εναλλακτικό μοντέλο παροχής λογισμικού, αφού τόσο η εφαρμογή όσο και τα δεδομένα προς επεξεργασία μπορούν να αποθηκευθούν και να εκτελεστούν στους servers του cloud παρόχου.

Σε αυτή την ενότητα θα παρουσιαστούν σύντομα ζητήματα ασφαλείας που σχετίζονται με τη χρήση υπηρεσιών «υπολογιστικής νέφους», ενώ παράλληλα θα γίνει επίδειξη του τρόπου μεταφοράς μιας Υπηρεσίας Ιστού σε έναν cloud πάροχο.

3.1. Ζητήματα ασφαλείας στην υπολογιστική νέφους

Η εμφάνιση της τεχνολογίας του «υπολογιστικού νέφους», έχει δημιουργήσει την ανάγκη λήψης επιπλέον μέτρων ασφαλείας, για τη διασφάλιση ευαίσθητων δεδομένων, καθώς νέες προκλήσεις κάνουν την εμφάνιση τους (Subashini & Kavitha, 2011). Ακόμη και προκλήσεις ασφαλείας που είναι πάγιες σε υπολογιστικά συστήματα, όπως είναι η αυθεντικοποίηση, η αδειοδότηση και η διαθεσιμότητα, μεγεθύνονται ραγδαία σε συστήματα «υπολογιστικού νέφους». Για παράδειγμα, στα ζητήματα αυθεντικοποίησης και αδειοδότησης, νέες ανησυχίες εγείρονται από τις πολιτικές και τα πρωτόκολλα που χρησιμοποιεί ο εκάστοτε πάροχος. Αντίστοιχα στο ζήτημα της διαθεσιμότητας, καθώς τα υλικά τμήματα των υποδομών πολλών επιχειρήσεων ανήκουν πλέον στην ευθύνη τρίτων, μια πιθανή μηχανική βλάβη ή αστοχία υλικού μπορεί να έχει αντίκτυπο σε περισσότερους τελικούς χρήστες σε σχέση με την περίπτωση που δε χρησιμοποιείται η «υπολογιστική νέφους» (Vesyropoulos et al., 2014).

Πιο αναλυτικά, μερικά από τα κυριότερα ζητήματα ασφαλείας που προκύπτουν είναι τα παρακάτω:

Ζητήματα εμπιστευτικότητας (Confidentiality):

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

Πέρα όμως από την εμπιστευτικότητα δεδομένων, σε περιβάλλοντα «υπολογιστικής νέφους» είναι ιδιαίτερα σημαντική και η εμπιστευτικότητα λογισμικού. Καθώς για την πρόσβαση σε ευαίσθητα δεδομένα γίνεται χρήση λογισμικού του παρόχου, ο τελικός χρήστης πολλές φορές δεν μπορεί να είναι ενημερωμένος για τα πρωτόκολλα και τις λειτουργίες αυτών των προγραμμάτων και δεν είναι σε θέση να επιλέξει το λογισμικό που προτιμά. Για τον λόγο αυτό είναι σημαντικό οι εφαρμογές αυτός να παρέχουν εγγυήσεις σχετικά με τα πρωτόκολλα ασφαλείας που προσφέρουν, ενώ παράλληλα είναι θεμιτό να γίνεται καταγραφή των αλλαγών που πραγματοποιούνται σε κάθε έκδοση των προγραμμάτων αυτόν σε αρχεία καταγραφής (log files).

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

Τέλος, σχετικά με το ζήτημα της εμπιστευτικότητας στην «υπολογιστική νέφους», εγείρονται επιπρόσθετες προκλήσεις που οφείλονται στην πολυμίσθωση (multitenancy και στην παραμένουσα μαγνήτιση των σκληρών δίσκων του παρόχου, κάτι που μπορεί να οδηγήσει σε ανάκτηση διαγραμμένων δεδομένων (Data remanence):

Η πολυμίσθωση αναφέρεται στον διαμοιρασμό πόρων ανάμεσα σε πολλούς χρήστες. Τέτοιοι πόροι μπορεί να περιλαμβάνουν εφαρμογές, ευαίσθητα δεδομένα, αποθηκευτικούς χώρους και μνήμη. Καθώς οι διάφοροι χρήστες μπορεί να χειρίζονται διαφορετικά «στιγμιότυπα» των ίδιων πόρων, κάνουν και χρήση των ίδιων συσκευών υλικού. Έτσι είναι, υπό προϋποθέσεις, εφικτή η μη-εξουσιοδοτημένη πρόσβαση ενός χρήστη στις πληροφορίες ενός άλλου χρήστη, όταν γίνεται ταυτόχρονα χρήση του ίδιου υλικού.

Η παραμένουσα μαγνήτιση αναφέρεται στην ύπαρξη «ίχνους» διαγραμμένων δεδομένων από έναν σκληρό δίσκο, τα οποία μέσω ειδικού λογισμικού μπορούν να ανακτηθούν. Καθώς λοιπόν ένας χρήστης αποκτά πρόσβαση σε ένα τμήμα ενός σκληρού δίσκου ενός παρόχου, είναι δυνατό μέσω ενός τέτοιου ίχνους να αποκτήσει πρόσβαση σε πληροφορίες που φαινομενικά είχαν διαγραφεί και που ανήκαν σε κάποιον προηγούμενο χρήστη.

Ζητήματα Ακεραιότητας (Integrity)

Με τον όρο αυτό αναφερόμαστε στη διασφάλιση ότι τα μη εξουσιοδοτημένα άτομα δεν έχουν δυνατότητες τροποποίησης σε δεδομένα αλλά και σε ρυθμίσεις του υλικού στο οποίο αυτά αποθηκεύονται. Και ενώ μια επιχείρηση είναι σε θέση να ελέγχει την πρόσβαση στους τοπικούς υπολογιστές και στα δεδομένα της από το προσωπικό της (μέσω της καταγραφής log files), αυτό είναι σαφώς δυσκολότερο σε σενάρια χρήσης «υπολογιστικής νέφους».

Οι πιθανές παραβιάσεις δεδομένων και υλικού, όταν αυτά αποθηκεύονται απομακρυσμένα μπορούν να είναι τόσο από εσωτερικές όσο και από εξωτερικές πηγές. Συγκεκριμένα μπορεί να οφείλονται σε κακοπροαίρετη συμπεριφορά των εργαζομένων ενός παρόχου αλλά και σε ενέργειες χρηστών και προγραμμάτων που έχουν ως στόχο την παραποίηση ευαίσθητων πληροφοριών.

Ζητήματα Διαθεσιμότητας (Availability)

Με τον όρο διαθεσιμότητα αναφερόμαστε στη δυνατότητα πρόσβασης σε έναν συγκεκριμένο πόρο τη στιγμή που αυτός ζητείται από τον χρήστη (on-demand). Ένα υψηλό επίπεδο διαθεσιμότητας από έναν πάροχο, θα σήμαινε πως ο πάροχος είναι θέση να προσφέρει κρίσιμες λειτουργίες και πρόσβαση σε πόρους, ακόμη κι αν έχει προηγηθεί μια βλάβη υλικού ή μια εξωτερική επίθεση. Κι ενώ σε παραδοσιακά τοπικά συστήματα υπολογιστών, η διαθεσιμότητα αφορά κυρίως τη συχνότητα εμφάνισης βλαβών υλικού/λογισμικού, σε περιβάλλοντα «υπολογιστικής νέφους» το ζήτημα αυτό μετατοπίζεται στη συχνότητα εμφάνισης προβλημάτων στη δομή του δικτύου, στα πρωτόκολλα που χρησιμοποιούνται και στο εύρος ζώνης που διατίθεται από τον πάροχο. Καθώς ένα πολύ μεγάλο πλήθος πληροφοριών ανταλλάσσεται καθημερινά, ανάμεσα σε έναν σημαντικά μεγάλο αριθμό χρηστών, ο πάροχος θα πρέπει να λάβει τα κατάλληλα μέτρα έτσι ώστε να μπορεί να ανταπεξέλθει στη μεγάλη αυτή ζήτηση για εύρος ζώνης, ενώ παράλληλα θα πρέπει να είναι προετοιμασμένος για εξωτερικές επιθέσεις από κακόβουλους χρήστες που θα προσπαθήσουν να προκαλέσουν βλάβη στο δίκτυο (πχ. μέσω επιθέσεων DDOS).

Ζητήματα εμπιστοσύνης (Trust)

Ο όρος εμπιστοσύνη σε μια συναλλαγή αναφέρεται στην προσδοκία από πλευράς του κάθε εμπλεκόμενου πως τα υπόλοιπα εμπλεκόμενα μέλη της συναλλαγής θα έχουν την αναμενόμενη συμπεριφορά κατά τη διάρκεια της. Από την πλευρά των χρηστών, η εμπιστοσύνη σε σενάρια χρήσης της τεχνολογίας «υπολογιστικής νέφους» αφορά την υπόθεση πως ο πάροχος θα είναι σε θέση να παραδώσει τις αναμενόμενες υπηρεσίες και τα προϊόντα. Παράλληλα όμως αφορά και την υπόθεση πως ο πάροχος θα πάρει όλα εκείνα τα μέτρα και τις προφυλάξεις που απαιτούνται για τη διασφάλιση των δεδομένων του χρήστη. Ανάμεσα λοιπόν στα εμπλεκόμενα μέλη της συναλλαγής θα πρέπει να δημιουργείται η αίσθηση πως οι συναλλαγές θα διενεργούνται με μεγάλο επίπεδο ασφάλειας.

Παρόλα αυτά κατά τη χρήση της «υπολογιστικής νέφους» η ευθύνη για τους μηχανισμούς ασφαλείας μεταφέρεται σε μεγάλο βαθμό στην πλευρά του παρόχου. Έτσι ο τελικός χρήστης έχει περιορισμένη πρόσβαση σε πληροφορίες σχετικά με τους μηχανισμούς αυτούς και με τον τρόπο που αυτοί χρησιμοποιούνται από τον πάροχο, κάτι που μπορεί να μειώσει το αίσθημα ασφαλείας που νιώθει ο χρήστης με αποτέλεσμα να μειωθεί και το επίπεδο εμπιστοσύνης του προς τον πάροχο.

3.2. Εφαρμογή Restlet στο Google App Εngine

Εκφώνηση:

Αναπτύξτε μια εφαρμογή προβολής πληροφοριών χρηστών, με χρήση του RESTlet framework και «ανεβάστε» τη σε πάροχο υπηρεσιών υπολογιστικής νέφους. Προτείνεται η χρήση του Google App Engine.

Υποδειγματική λύση:

Πρέπει να κατεβάσουμε το Google App Engine SDK (έκδοση για Java), από τη διεύθυνση https://cloud.google.com/appengine/downloads?csw=1. Αποσυμπιέζουμε το αρχείο που κατέβηκε.
Πρέπει επίσης να κατεβάσουμε το απαραίτητο plugin της Google μέσω του περιβάλλοντος Eclipse. Πατάμε Help > Install New Software, δίνουμε ως διεύθυνση την «https://dl.google.com/eclipse/plugin/4.4» και από τη λίστα που μας επιστρέφεται επιλέγουμε το Google plugin for eclipse.
Δημιουργία ενός νέου Web Application Project, με την ονομασία RestletGAE, με ονομασία package example.restlet, και App Id, το efarmogirestlet. Επιλέγουμε File->New->Project->Google->Web Application Project.
Ρυθμίζουμε το Google App Engine πατώντας την επιλογή Configure SDK, και επιλέγοντας τον φάκελο που προέκυψε από την αποσυμπίεση του αρχείου. Δίνουμε τις επιλογές που φαίνονται στην εικόνα 10.7 και πατάμε Finish.
Διαγράφουμε την sample code κλάση RestletGAEServlet.java που δημιουργήθηκε αυτόματα.
Δημιουργούμε τις κλάσεις της εφαρμογής μας.

o Αρχικά δημιουργούμε την RESTLet.java που δημιουργεί ένα Restlet component και συνδέει έναν HTTP server connector σε αυτό. Ο HTTP server μας είναι ο 8888.

RESTLet.java

package userRest;

import org.restlet.Component;

import org.restlet.data.Protocol;

public class RESTLet {

public static void main(String[] args) throws Exception {

// Create a new Restlet component and add a HTTP server connector to it

Component component = new Component();

component.getServers().add(Protocol.HTTP, 8888);

// Attach the application to the component and start it

component.getDefaultHost().attach(new RouterApplication());

component.start();

}

Εικόνα 10.7 Δημιουργία Web application project

Στη συνέχεια δημιουργούμε την RouterApplication.java η οποία θα λαμβάνει τις εισερχόμενες REST κλήσεις.

RouterApplication.java

package userRest;

import org.restlet.Application;

import org.restlet.Restlet;

import org.restlet.routing.Router;

public class RouterApplication extends Application{

// Creates a root Restlet that will receive all incoming calls.

@Override

public synchronized Restlet createInboundRoot() {

// Create a router Restlet that routes each call to a new respective instance of resource.

Router router = new Router(getContext());

// Define three routes

router.attach("/user/{uid}", UserResource.class);

router.attach("/user/{uid}/complete", UserCompleteResource.class);

router.attach("/user/{uid}/pending", UserPendingResource.class);

return router;

}

Τέλος ορίζουμε τις επόμενες 3 κλάσεις που περιγράφουν την ιδιότητα ενός χρήστη, το πλήθος τον αγορών που έχει κάνει και το πλήθος των παραγγελιών που εκκρεμούν.

UserResource.java

package userRest;

import org.restlet.resource.Get;

import org.restlet.resource.ServerResource;

public class UserResource extends ServerResource {

@Get

public String toString() {

String uid = (String) getRequestAttributes().get("uid");

return "Ο χρήστης \"" + uid + "\" είναι: εγγεγραμμένος χρήστης";

}

UserCompleteResource.java

package userRest;

import org.restlet.resource.Get;

import org.restlet.resource.ServerResource;

public class UserCompleteResource extends ServerResource {

@Get

public String toString() {

String uid = (String) getRequestAttributes().get("uid");

return "Οι ολοκληρωμένες παραγγελίες του χρήστη \"" + uid + "\" είναι: 12";

}

UserPendingResource.java

package userRest;

import org.restlet.resource.Get;

import org.restlet.resource.ServerResource;

public class UserPendingResource extends ServerResource {

@Get

public String toString() {

String uid = (String) getRequestAttributes().get("uid");

return "Οι εκκρεμείς παραγγελίες του χρήστη \"" + uid + "\" είναι: 2";

}

Προσθέτουμε το org.restlet.jar και το org.restlet.ext.servlet.jar στα External JARs όπως κάναμε και στην τοπική εκτέλεση.

Κάνοντας αντιγραφή-επικόλληση των αρχείων org.restlet.jar και org.restlet.ext.servlet.jar από τον υπολογιστή μας τα προσθέτουμε και στο /RestletGAE/war/WEB-INF/lib
Έλεγχος του αρχείου appengine-web.xml (βρίσκεται στο RestletGAE/war/WEB-INF/appengine-web.xml). Θέλουμε να βεβαιωθούμε πως αναφέρεται στο σωστό όνομα εφαρμογής με τη σωστή έκδοση
Τροποποίηση του αρχείου web.xml (βρίσκεται στο /RestletGAE/war/WEB-INF/web.xml). Θέλουμε να βεβαιωθούμε πως αναφέρεται στην κύρια εκτελέσιμη κλάση της εφαρμογής, την «RouterApplication» και έτσι να έχει τη μορφή:

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE web-app PUBLIC

"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">

<display-name>restlet servlet</display-name>

<servlet>

<servlet-name>RestletServlet</servlet-name>

<servlet-class>org.restlet.ext.servlet.ServerServlet</servlet-class>

<init-param>

<param-name>org.restlet.application</param-name>

<param-value>tutorial.restlet.RouterApplication </param-value>

</init-param>

</servlet>

<servlet-mapping>

<servlet-name>RestletServlet</servlet-name>

<url-pattern>/*</url-pattern>

</servlet-mapping>

</web-app>

Τροποποιούμε το αρχείο index.html που βρίσκεται στο /RestletGAE/war/index.html δίνοντάς του όποια μορφή θέλουμε να εμφανίζεται σαν αρχική σελίδα της εφαρμογής μας.
Εκτέλεση της εφαρμογής μας τοπικά

o Εκτελούμε την εφαρμογή μας τοπικά με δεξί κλικ – Run As – Web Application.

o Από το μήνυμα που λαμβάνουμε στην Console του Eclipse φαίνεται να τρέχει κανονικά ο server στο http://localhost:8888/

o Δοκιμάζουμε τα παρακάτω URI:

§ http://localhost:8888/user/1

§ http://localhost:8888/user/2/pending

§ http://localhost:8888/user/1234/complete

Ανέβασμα και εκτέλεση της εφαρμογής στο Google App Engine.

(Προαιρετικά) Κάνουμε δεξί κλικ – Google – App Engine Settings, βλέπουμε τις ρυθμίσεις της εφαρμογής για ανέβασμα στο Google App Engine, και ελέγχουμε αν θέλουμε να κάνουμε αλλαγές στο όνομα της εφαρμογής.

Εικόνα 10.8 Τοπική εκτέλεση ενός GET request

Εικόνα 10.9 Οθόνη προαιρετικής παραμετροποίησης στοιχείων εφαρμογής πριν το deploy

Κάνουμε δεξί κλικ στο project μας – Google – Deploy to App Engine – Deploy
Είναι απαραίτητη η χρήση ενός λογαριασμού Google. Στην κονσόλα του Eclipse βλέπουμε ότι το deployment έγινε επιτυχώς.
Εκτελούμε τα παραπάνω URI αντικαθιστώντας το «http://localhost:8888» με το «efarmogirest.appspot.com» και βλέπουμε πως η εφαρμογή λειτουργεί κανονικά στο Google App Engine, δίνοντας τα ίδια αποτελέσματα με την τοπική εκτέλεση.

4. Δημιουργία Ενορχήστρωσης BPEL για τη σύνθεση ΥΙ

Εκφώνηση:

Δημιουργείστε μια ενορχήστρωση BPEL, για τον έλεγχο της τιμής μιας string μεταβλητής που θα δίνεται από ένα partner link προς ένα BPEL module.

Για την υλοποίηση της ενορχήστρωσης προτείνεται η χρήση του πακέτου OpenESB 2.3.1, το οποίο συμπεριλαμβάνει το περιβάλλον ανάπτυξης NetBeans (έκδοση 7) μαζί με τον Glassfish Server και παρέχει υποστήριξη για σύνθεση ΥΙ μέσω BPEL.

Υποδειγματική λύση:

· Δημιουργία BPEL module

o Από το περιβάλλον NetBeans IDE, επιλέγουμε File → New Project.

o Στο μενού Categories, επιλέγουμε Service Oriented Architecture.

o Στο μενού Projects, επιλέγουμε BPEL Module και μετά Next.

Εικόνα 10.10 Δημιουργία BPEL module

o Στα Name και Location, δίνουμε το όνομα και την τοποθεσία στην οποία θέλουμε να αποθηκευθεί το project μας (σε αυτό το παράδειγμα ονομάζουμε το αρχείο CompareStrings).

o Τώρα στα projects εμφανίζεται το BPEL module όπως φαίνεται στην εικόνα 10.12.

Δημιουργία του XML Schema

Γενικά, όταν δημιουργούμε ένα BPEL module project ακολουθούμε τα παρακάτω βήματα:

Δημιουργούμε ένα νέο BPEL Project
Δημιουργούμε το XML Schema ή το XSD αρχείο
Δημιουργούμε το WSDL αρχείο
Δημιουργούμε την BPEL διαδικασία

Το αρχείο XSD (XML Schema) βοηθά να ορίσουμε τη δομή μηνυμάτων του project. Σύνθετες δομές μηνυμάτων ορίζονται στο XSD αρχείο και στη συνέχεια εισάγονται στο αρχείο WSDL.

Σε αυτή την ενότητα προσθέτουμε ένα νέο αρχείο XML schema στο BPEL Module και προσθέτουμε components στο schema.

Εικόνα 10.11 Ρύθμιση παραμέτρων του BPEL module

Εικόνα 10.12 Εμφάνιση του BPEL module στη λίστα αρχείων του project

Για να δημιουργήσουμε το CompareStrings.xsd

o Στο παράθυρο Projects, κάνουμε expand το CompareStrings κόμβο, και στη συνέχεια κάνουμε δεξί κλικ στον κόμβο Process Files και επιλέγουμε New -> Other.

o Στο παράθυρο που ανοίγει:

Στη σελίδα Choose File Type, στη λίστα Categories, επιλέγουμε XML , και στη λίστα File Types, επιλέγουμε XML Schema και πατάμε Next.
Σαν όνομα στο πεδίο File Name, βάζουμε το CompareStrings.
Πατάμε Finish.

o Στο παράθυρο Projects, ο κόμβος Process Files πλέον περιέχει έναν υποκόμβο που ονομάζεται CompareStrings.xsd. Ο Source Editor περιέχει μια καρτέλα για το XML schema.

o Στο Schema view, κάντε κλικ στο κουμπί Design για να ανοίξει το Design view του XML schema editor.

Προσθήκη ενός αντικειμένου τύπου string στο XML schema (τύπου global):

Στο τμήμα XML Components της παλέτας επιλέξτε το εικονίδιο Element και σύρετε την επιλογή σας στο design area, ακριβώς κάτω από τον κόμβο Elements. Το IDE αυτόματα προσθέτει ένα στοιχείο με την ονομασία newElement κάτω από τον κόμβο Elements στο schema design.

Εικόνα 10.13 Δημιουργία του XML schema

Στην περιοχή του schema design του Design view, επιλέξτε τον κόμβο newElement.
Στο παράθυρο Properties window, επιλέξτε το πεδίο ονόματος και δώστε σαν όνομα Name.
Στο ίδιο παράθυρο, στο πεδίο Definition κάντε κλικ στο κουμπί της έλλειψης.
Από τη λίστα επιλέξτε Built-in Types-> string και πατήστε OK.

Εικόνα 10.14 Προσθήκη νέου αντικειμένου τύπου string

Στο design view, to IDE πλέον δείχνει το επιλεγμένο Name και δίπλα τον τύπο string.

Εικόνα 10.15 Εμφάνιση του νέου αντικειμένου τύπου string

Επαναλαμβάνουμε την παραπάνω διαδικασία για τη δημιουργία ενός ακόμα κόμβου που θα δέχεται το αποτέλεσμα της σύγκρισης, τον MatchResult, επίσης τύπου string.

Εικόνα 10.16 Εμφάνιση του αντικειμένου MatchResult

Για να αποθηκεύσουμε την εργασία μας, από το παράθυρο Projects, επιλέγουμε το compareStrings project κόμβο και από την μπάρα στο πάνω μέρος της οθόνης επιλέγουμε File > Save All.

Δημιουργία του WSDL Document

Στο παράθυρο Projects, κάνουμε expand τον κόμβο compareStrings project, και στη συνέχεια με δεξί κλικ στον κόμβο Process Files και επιλέγουμε New -> WSDL Document.

Στη συνέχεια:

Σαν όνομα δίνουμε compareStrings.
Επιλέγουμε ως WSDL Type την επιλογή Concrete WSDL Document.
Στην επιλογή Binding επιλέγουμε SOAP.
Στην επιλογή Type δίνουμε την τιμή Document Literal.
Πατάμε Next.

Εικόνα 10.17 Δημιουργία νέου WSDL αρχείου

Ανοίγει η σελίδα Abstract Configuration.

Σε αυτή τη σελίδα:

Στη στήλη Message Part Name, κάνουμε διπλό κλικ πάνω στο προεπιλεγμένο όνομα (part1) για να γίνει το πεδίο editable.
Δίνουμε σαν όνομα inputType και πατάμε Enter.
Στη στήλη Element Or Type, κάνουμε κλικ στο κουμπί της έλλειψης.
Επιλέγουμε By File > Elements > Name

Στο πεδίο Output:

Στο τμήμα ονομασίας του Message Part Name, κάνουμε διπλό κλικ στην default τιμή (part1).
Δίνουμε σαν όνομα resultType και πατάμε Enter.
Στη στήλη Element Or Type, κάνουμε κλικ στο κουμπί της έλλειψης.
ΕπιλέγουμεBy File > Elements > MatchResult

Εικόνα 10.18 Επιλογή τύπου μεταβλητής μέσω του γραφικού περιβάλλοντος

Εικόνα 10.19 Η οθόνη Abstract Configuration

Πατάμε Next. Ανοίγει η σελίδα Concrete Configuration.
Πατάμε Finish.

Στο Projects window, ο κόμβος Process Files, πλέον περιέχει έναν υποκόμβο με την ονομασία compareStrings.wsdl. Ο Source Editor περιέχει μια καρτέλα για το WSDL αρχείο, την compareStrings.wsdl

Προσθήκη ενός Partner Link στην BPEL διαδικασία

Στο παράθυρο Projects, κάνουμε κλικ στον φάκελο Process Files για να φανούν τα περιεχόμενα του και επιλέγουμε το wsdl αρχείο (compareStrings.wsdl).
Σύρουμε (drag n’ drop) το αρχείο wsdl από το παράθυρο Projects, στην αριστερή πλευρά του καμβά του Design view. Ο BPEL Editor προσθέτει με αυτόν τον τρόπο ένα partner link στον καμβά.

Εικόνα 10.20 Αρχική οθόνη ενορχήστρωσης BPEL, με ένα Partner Link

Προσθέστε μια δραστηριότητα Receive στο BPEL Process

Από το μενού Web Service του Palette window, επιλέγουμε τη δραστηριότητα Receive.
Σύρουμε τη δραστηριότητα αυτή στο κουτί (process box) στον καμβά του Design view,ανάμεσα στο Process Start και το Process End.
Κάνουμε κλικ στο εικονίδιο Edit του Receive1. Ανοίγει ο Property Editor.
Στο tab Main, αλλάζουμε το όνομα σε start.
Από το drop-down μενού του Partner Link, επιλέγουμε PartnerLink1. Το IDE προσθέτει στο πεδίο Operation το compareStringsOperation.
Επιλέγουμε το κουμπί Create δίπλα στο Input Variable, έτσι ώστε να εμφανιστεί το μενού New Input Variable. Κάνουμε κλικ στο OK για να την αποδοχή των default τιμών.
Κάνουμε κλικ στο OK ώστε να κλείσει ο Property Editor. Φαίνεται πλέον στο Design view η νέα σύνδεση ανάμεσα στο PartnerLink1 και τη δραστηριότητα Start.

Εικόνα 10.21 Το palette window, με επιλογές Web Services και Activities

Εικόνα 10.22 Εισαγωγή ενός receive activity

Εικόνα 10.23 Ρύθμιση του receive activity και ορισμός της μεταβλητής εισόδου

Εικόνα 10.24 Η παραμετροποιημένη receive activity με την ονομασία start

Προσθήκη μιας δραστηριότητας Reply στο BPEL Process

Επιλέγουμε τη δραστηριότητα Reply στο τμήμα Web Service της παλέτας. Σύρουμε τη δραστηριότητα Reply ανάμεσα στο start και το Process End στον καμβά. Μια δραστηριότητα Reply1 εμφανίζεται στο design view.
Κάνουμε κλικ στο κουμπί edit του Reply1. Θα ανοίξει Ο Reply1 Property Editor.
Στην καρτέλα Main, αλλάζουμε το όνομα σε end.
Από την drop-down λίστα του Partner Link, επιλέγουμε PartnerLink1. Το IDE προσθέτει στο Operation field το compareStringsOperation.
Για να δημιουργήσουμε μια νέα μεταβλητή τύπου output, επιλέγουμε Normal Response, και κάνουμε κλικ στο πλήκτρο Create δίπλα στο Input Variable πεδίο. Το μενού New Input Variable ανοίγει. Κάνουμε κλικ στο OK για αποδοχή των default τιμών.
Κάνουμε κλικ στο OK για να κλείσουμε τον Reply1 Property Editor. Στο Design view πλέον φαίνεται η σύνδεση ανάμεσα στη δραστηριότητα end και το PartnerLink1.

Προσθήκη μιας δραστηριότητας If στο BPEL Process

o Επιλέγουμε τη δραστηριότητα If στο Structured Activities τμήμα της παλέτας (Palette). Σύρουμε τη δραστηριότητα If ανάμεσα στο start και το end στον καμβά. Μια δραστηριότητα If1 εμφανίζεται στο design view.

Κάντας διπλό κλικ στη δραστηριότητα If1, εμφανίζεται ο BPEL Mapper.
Από τη γραμμή ενεργειών επιλέγουμε operator->Equal

o Στη συνέχεια από τη γραμμή ενεργειών επιλέγουμε String->String Literal

Στο τμήμα String Literal που εμφανίζεται δίνουμε το string με το οποίο θα συγκρίνουμε την είσοδο της ΥΙ. Για τις ανάγκες αυτού του παραδείγματος δίνουμε “Georgiadis”.
Στη συνέχεια κάνουμε τη σύνδεση των μεταβλητών, όπως φαίνεται στην εικόνα 10.29, με τη χρήση drag n’ drop.

Εικόνα 10.25 Παραμετροποίηση της reply activity

Εικόνα 10.26 Αλληλεπίδραση με το partner link και ανταλλαγή μηνυμάτων

Εικόνα 10.27 Λίστα διαθέσιμων operators

Εικόνα 10.28 Λίστα διαθέσιμων επιλογών που σχετίζονται με τον τύπο string

Προσθήκη μιας δραστηριότητα Assign στο BPEL Process

Επιλέγουμε τη δραστηριότητα Assign στο Basic Activities τμήμα της παλέτας (Palette). Σύρουμε τη δραστηριότητα Assign στο εσωτερικό της If1, δηλαδή στην περίπτωση που ισχύει η συνθήκη. Μια δραστηριότητα Assign1 εμφανίζεται στο design view.
Επιλέγουμε τη δραστηριότητα Assign1 και κάνουμε κλικ στο πλήκτρο Mapper στο editors toolbar. Εμφανίζεται ο BPEL Mapper.

Από τη γραμμή ενεργειών επιλέγουμε String->String Literal
Δίνουμε σαν τιμή “Strings Match” και τη συσχετίζουμε με την τιμή CompareStringsOperationOutresultType

Έτσι αντιγράφεται η τιμή του string στην έξοδο.

Στη συνέχεια θα προσθέσουμε ένα νέο assign activity για την περίπτωση που το string εισόδου δεν είναι το αναμενόμενο.

o Επιλέγουμε τη δραστηριότητα Assign στο Basic Activities τμήμα της παλέτας (Palette). Σύρουμε τη δραστηριότητα Assign στο δεξί τμήμα της If1, δηλαδή στην περίπτωση που δεν ισχύει η συνθήκη. Μια δραστηριότητα Assign2 εμφανίζεται στο design view.

Κάντε κλικ για επαναληψη της κινησης στην παρακάτω εικόνα:

Εικόνα 10.29 Σύγκριση του string εισόδου με ένα προεπιλεγμένο string, μέσω του εργαλείου mapper

Κάντε κλικ για επαναληψη της κινησης στην παρακάτω εικόνα:

Εικόνα 10.30 Εισαγωγή ενός string στη μεταβλητή εξόδου, μέσω του εργαλείου mapper

Εικόνα 10.31 Η ενορχήστρωση BPEL, μετά την εισαγωγή μιας If structured activity

o Επιλέγουμε τη δραστηριότητα Assign1 και κάνουμε κλικ στο πλήκτρο Mapper στο editors toolbar. Εμφανίζεται ο BPEL Mapper.

o Από τη γραμμή ενεργειών επιλέγουμε String->String Literal

o Δίνουμε σαν τιμή “Strings Do Not Match” και τη συσχετίζουμε με την τιμή CompareStringsOperationOutresultType

Εικόνα 10.32 Εισαγωγή ενός string στη μεταβλητή εξόδου, μέσω του εργαλείου mapper

Κάνουμε κλικ στο εικονίδιο Save All στο κεντρικό μενού του IDE.

Δημιουργία ενός Composite Application Project

Ένα BPEL Module project δεν μπορεί να γίνει άμεσα deploy. Πρέπει πρώτα να προσθέσουμε το BPEL Module project, ως ένα JBI module, σε ένα σύνθετο project (Composite Application project). Στη συνέχεια μπορούμε να κάνουμε deploy το σύνθετο project. Κάνοντας Deploy το project κάνουμε την υπηρεσία διαθέσιμη και επιτρέπουμε στα συστατικά της μέρη να τρέξουν.

Δημιουργία ενός νέου σύνθετου project (Composite Application Project)

Επιλέγουμε File → New Project (ή εναλλακτικά πατάμε Ctrl-Shift-N).
Στη λίστα Categories επιλέγουμε Service Oriented Architecture, στη λίστα Projects επιλέγουμε Composite Application, και πατάμε Next.

Εικόνα 10.33 Δημιουργία Composite Application

Στη σελίδα Name and Location, αλλάζουμε το όνομα του project σε CompareStringsApplication.

Εικόνα 10.34 Ορισμός των τιμών Name και Project Location

Αφήνουμε επιλεγμένο το Set as Main Project checkbox και πατάμε Finish.
Για να προσθέσουμε το BPEL Module σαν JBI module στο σύνθετο project, κάνουμε δεξί κλικ στο Composite Application και επιλέγουμε Add JBI Module. Έτσι ανοίγει το παράθυρο Select Project.

Εικόνα 10.35 Εισαγωγή του BPEL module, στο composite application ως JBI module

Επιλέγουμε το CompareStrings project που δημιουργήσαμε νωρίτερα και κάνουμε κλικ στο Add Project JAR Files. Έτσι κλείνει το παράθυρο Select Project και το αρχείο compareStrings.jar προστίθεται στον κόμβο JBI Modules του CompareStringsApplication Composite Application.

Πως γίνεται το Build και Deploy του σύνθετου project (Composite Application Project)

Κάνοντας Build ένα project γίνεται αυτόματα μεταγλώττιση (compile) του αρχείου BPEL και γίνεται προσθήκη όλων των αρχείων (BPEL,WSDL,XSD) σε ένα JAR archive.

Κάνοντας Deploy ένα project γίνονται όλα τα παραπάνω και επιπρόσθετα στέλνονται τα αρχεία για εκτέλεση στον Application Server.

Build και Deploy

Κάνουμε δεξί κλικ στον κόμβο Composite Application project και επιλέγουμε Build. Όταν ολοκληρωθεί αυτή η διαδικασία θα εμφανιστεί στο παράθυρο Output το μήνυμα "Build Successful."
Κάνουμε δεξί κλικ στον ίδιο κόμβο και πατάμε Deploy.
Επιλέγουμε το tab Services και ανοίγουμε (expand) την επιλογή Servers → GlassFish V2 → JBI → Service Assemblies για να δούμε σχηματικά το αποτέλεσμα του deploy.

Εικόνα 10.36 Η εμφάνιση της εφαρμογής στην καρτέλα services, ως αποτέλεσμα του deploy αυτής

Δοκιμάζοντας το Composite Application

Μπορούμε να δοκιμάσουμε το Composite Application project, προσθέτοντας σενάρια (test cases).

Δοκιμή του CompareStringsApplication Composite Application Project

Στο παράθυρο Projects, ανοίγουμε (expand) τον κόμβο CompareStringsApplication, κάνουμε δεξί κλικ στον κόμβο Test, και επιλέγουμε New Test Case.
Αφήνουμε το προκαθορισμένο όνομα (TestCase1), και πατάμε Next.
Από τη σελίδα Select the WSDL Document, κάνουμε expand τον κόμβο CompareStrings- Process Files, επιλέγουμε CompareStrings.wsdl, και πατάμε Next.
Από τη σελίδα Select the Operation to Test, επιλέγουμε CompareStringsOperation και πατάμε Finish.

Εικόνα 10.37 Επιλογή WSDL αρχείου για τη διενέργεια test

Ένας κόμβος TestCase1 προστίθεται κάτω από τον κόμβο Test, που περιέχει δύο υποκόμβους, τον Input και Output.

Εμφανίζεται ο Source Editor που περιέχει το αρχείο Input.xml

Στην καρτέλα Input.xml του Source Editor, κάνουμε τα ακόλουθα:

Εντοπίζουμε τη γραμμή:

<com:Name>?string?</com:Name>

Αντικαθιστούμε το ?string? με τη λέξη Georgiadis, έτσι ώστε να πάρει την ακόλουθη μορφή:

<com:Name>Georgiadis </com:Name>

Από τη menu bar, κάνουμε κλικ στην επιλογή Save All.
Στο παράθυρο Projects, κάνουμε διπλό κλικ στον κόμβο Output κάτω από το Test → TestCase1.
Ανοίγει το Output.xml στον Source Editor. Αρχικά το αρχείο είναι άδειο, μέχρι το πρώτο τεστ να το γεμίσει με δεδομένα.
Στο παράθυρο Projects, κάνουμε δεξί κλικ στον κόμβο TestCase1 και επιλέγουμε Run.
Θα εμφανιστεί ένα παράθυρο που θα ρωτάει αν επιθυμούμε να κάνουμε Overwrite, πατάμε Yes. Το πρώτο τεστ γεμίζει στοιχεία το αρχείο Output.xml.

Κάθε φορά το τεστ συγκρίνει τα αποτελέσματα με το περιεχόμενο του output file. Επειδή την πρώτη φορά το αρχείο αυτό είναι άδειο το πρώτο τεστ θα βγάλει αποτυχία. Τρέξτε κι άλλα τεστ το οποία θα πρέπει να βγάλουν σαν μήνυμα την επιτυχία.

Εικόνα 10.38 Αποτελέσματα του TestCase1

Ανοίγοντας το αρχείο Output.xml θα δούμε πως αφού η είσοδος ήταν η αναμενόμενη, ως έξοδος περάστηκε το string “Strings Match”.

Εικόνα 10.39 Το επιστρεφόμενο μήνυμα «Strings Match»

Δημιουργούμε ένα δεύτερο Test (το ονομάζουμε TestCase2) ακολουθώντας την ίδια διαδικασία.
Αυτή τη φορά στην καρτέλα Input.xml του Source Editor, εντοπίζουμε τη γραμμή:

o <com:Name>?string?</com:Name>

o και αντικαθιστούμε το ?string? με τη λέξη Papadopoulos, έτσι ώστε να πάρει την ακόλουθη μορφή:

o <com:Name>Papadopoulos </com:Name>

Από την menu bar, κάνουμε κλικ στην επιλογή Save All.
Στο παράθυρο Projects, κάνουμε δεξί κλικ στον κόμβο TestCase2 και επιλέγουμε Run, δύο φορές ώστε να γίνει σύγκριση των αποτελεσμάτων της δεύτερης φοράς με την πρώτη.
Θα δούμε πάλι πως το τεστ θα δώσει επιτυχία. Αυτή τη φορά όμως ανοίγοντας το αρχείο Output.xml θα δούμε πως θα έχει περαστεί ως απάντηση το string “Strings Do Not Match”.

Εικόνα 10.40 Το επιστρεφόμενο μήνυμα «Strings Do Not Match»

5. Επιλογή ΥΙ με χρήση τεχνικών πολυκριτήριας ανάλυσης αποφάσεων

Για την επιλογή και σύνθεση ΥΙ, σε περιπτώσεις όπου υφίσταται πληθώρα υπηρεσιών με παρόμοια λειτουργικότητα (οι οποίες όμως διαφέρουν στα ποιοτικά χαρακτηριστικά τους), έχουν προταθεί πολλές μέθοδοι στη βιβλιογραφία. Στην πηγή (Vesyropoulos & Georgiadis, 2015) έχει παρουσιαστεί μια μέθοδος επιλογής με βάση τη μεθοδολογία Analytical Hierarchy Process (AHP), η οποία ανήκει στην κατηγορία των πολυκριτηριακών μεθόδων.

Η AHP έχει προταθεί το 1980 (Saaty, 1980) και έχει εφαρμοσθεί σε μια πληθώρα πεδίων όπως είναι η επιχειρησιακή έρευνα, η διαχείριση πόρων ενέργειας, η τραπεζική και άλλες. Μέσω ενός ιεραρχικού μοντέλου, παρέχει βοήθεια κατά την επιλογή μεταξύ πλήθους εναλλακτικών, με βάση κάποια προκαθορισμένα κριτήρια. Η μέθοδος μπορεί να χειριστεί τόσο ποιοτικές όσο και ποσοτικές τιμές. Για την εφαρμογή της μεθόδου ακολουθούνται κάποια συγκεκριμένα βήματα:

i) Σχεδιασμός της ιεραρχίας του προβλήματος όπως φαίνεται στο σχήμα 10.2.

ii) Θέσπιση της προτεραιότητας των κριτηρίων με την εισαγωγή συγκρίσεων ανά ζεύγη, κάνοντας χρήση της κλίμακας από το 1 ως το 9. Με τον τρόπο αυτό φαίνονται τα βάρη που ορίζει ο χρήστης για κάθε κριτήριο, δηλαδή το πόσο σημαντικό το θεωρεί σε σχέση με τα υπόλοιπα.

iii) Βαθμολόγηση των εναλλακτικών ως προς το κάθε κριτήριο, με χρήση συγκρίσεων ανά ζεύγη

iv) Υπολογισμός της συνολικής βαθμολογίας για κάθε εναλλακτική και ταξινόμηση τους, ξεκινώντας από την πλησιέστερη προς το επιθυμητό αποτέλεσμα, και με φθίνουσα σειρά.

Έτσι λοιπόν γίνεται φανερό πως η AHP λαμβάνει ως εισόδους τιμές για διαφορετικά κριτήρια και έχει τη δυνατότητα υπολογισμού μιας συνολικής τιμής που αντιπροσωπεύει τη συνολική βαθμολογία κάθε εναλλακτικής επιλογής.

Όπως είναι φυσικό, η μεθοδολογία μπορεί να χρησιμοποιηθεί και για την επιλογή της κατάλληλης ΥΙ, μέσω ποιοτικών κριτηρίων, η οποία θα αποτελέσει τμήμα μιας σύνθεσης ΥΙ. Το μεγαλύτερο πλεονέκτημα που προκύπτει από την υιοθέτηση της μεθοδολογίας αυτής από μια μηχανή σύνθεσης, είναι η παροχή προσωποποιημένων συνθέσεων σε μεγαλύτερο βαθμό από άλλες μεθόδους καθώς μέσω των διαφόρων κριτηρίων η σύνθεση ανταποκρίνεται πλήρως στις ανάγκες του τελικού χρήστη ή της επιχείρησης. Είναι παράλληλα δυνατή η επιτάχυνση της διαδικασίας σύνθεσης, ειδικότερα σε συστήματα που θα ενσωματώνουν παράλληλα και αλγόριθμους τεχνητής νοημοσύνης, όπου επιτρέπεται η αυτόματη συμπλήρωση κάποιων συγκρίσεων από τη μηχανή σύνθεσης, καθώς αυτή θα «μαθαίνει» τις προτιμήσεις κάθε χρήστη.

Παρακάτω θα παρουσιαστεί η εφαρμογή της μεθοδολογίας για την επιλογή ΥΙ, με βάση τα κριτήρια αλλά και τα βάρη που εισάγει ο τελικός χρήστης. Τελικό στόχο αποτελεί η βέλτιστη σύγκλιση ΥΙ, με βάση τα χαρακτηριστικά ποιότητας. Επιπρόσθετα στη συγκεκριμένη εφαρμογή λαμβάνονται υπ’όψιν και εξωτερικές αξιολογήσεις ΥΙ που προκύπτουν από προηγούμενους χρήστες των ΥΙ, οι οποίοι βαθμολογούν την εμπειρία τους από τη χρήση των ΥΙ.

Σχήμα 10.2 Η ιεραρχική δομή στην AHP, σε ένα παράδειγμα σύνθεσης βάσει ποιοτικών χαρακτηριστικών

5.1. Εξατομικευμένη επιλογή και σύνθεση με βάση κριτήρια ποιότητας παρεχόμενων υπηρεσιών

Η συγκεκριμένη μεθοδολογία έχει βασιστεί σε μεγάλο βαθμό στις ΥΙ τύπου REST, τόσο λόγω της μεγάλης απήχησης που λαμβάνουν τα τελευταία χρόνια (Pautasso 2014), όσο και λόγω του γεγονότος πως για την πρόσβαση σε πληροφορίες που προκύπτουν από «έξυπνες» συσκευές, μέσω κλήσεων HTTP, είναι επιβεβλημένη η χρήση τους (Want et al, 2015; Gubbi et al, 2013; Guinardn et al, 2011).

Καθώς όμως οι ΥΙ τύπου SOAP προσφέρουν οφέλη σε επίπεδο χειρισμού επιχειρηματικών κανόνων, και καθώς είναι δυνατή η ενσωμάτωση τους σε Web 2.0 mashups (βλ. http://www.ibm.com/developerworks/xml/library/x-mashups.html), η μεθοδολογία δεν αποκλείει τη χρήση και ΥΙ αυτού του τύπου.

Παράλληλα, σύμφωνα με τις αρχές του κοινωνικού ιστού (social web), και καθώς τα σχόλια και γενικότερα η ανάδραση χρηστών σχετικά με προϊόντα και υπηρεσίες είναι πλέον σήμερα περισσότερο προσβάσιμα από ποτέ, ο χρήστης και η μηχανή σύνθεσης θα πρέπει να μπορούν να λάβουν υπόψη αξιολογήσεις προηγούμενων χρηστών.

Μοντέλο συστήματος

Το προτεινόμενο μοντέλο αποτελείται από τις παρακάτω μεταβλητές:

UsQoS:

Μια λίστα με τα αρχικά κριτήτια QoS που έχει ζητήσει ο χρήστης.

ProvQoS:

Μια λίστα τιμών για συγκεκριμένα κριτήρια QoS, όπως π.χ. ο βαθμός ιδιωτικότητας, που παρέχεται από τους παρόχους των ΥΙ. Αυτές είναι προκαθορισμένες, σταθερές τιμές και αποτελούν ένα είδος αυτο-αξιολόγησης από την πλευρά των παρόχων.

EvQoS:

Μια λίστα από τιμές για συγκεκριμένα κριτήρια QoS, που προσφέρονται από αξιολογήσεις προηγούμενων χρηστών.

UserWeights:

Μια λίστα από βάρη, με τα οποία ο χρήστης καθορίζει τον βαθμό σημαντικότητας που δίνει σε διάφορα κριτήρια QoS και που βοηθούν στη λήψη εξατομικευμένων απαντήσεων από τη μηχανή σύνθεσης.

Όπως θα αναλυθεί παρακάτω η επιλογή των βαρών των κριτηρίων αποτελεί μια διαδικασία 2 βημάτων. Αρχικά, ο χρήστης επιλέγει ένα σύνολο λειτουργικών χαρακτηριστικών που επιθυμεί αλλά και ένα σύνολο χαρακτηριστικών ποιότητας, για τα οποία καθορίζει και τον βαθμό σημαντικότητας (βάρη).

Ως αποτέλεσμα η μηχανή σύνθεσης επιστρέφει ένα σύνολο από ΥΙ, οι οποίες ικανοποιούν τα απαιτούμενα λειτουργικά χαρακτηριστικά, ενώ μπορεί παράλληλα να ικανοποιούν μερικά ή όλα τα απαιτούμενα χαρακτηριστικά ποιότητας. Επιπρόσθετα, ενδέχεται να προσφέρουν και άλλα χαρακτηριστικά ποιότητας για τα οποία δεν έχει ορίσει βάρη ο χρήστης αλλά ενδεχομένως να αποτελούν χαρακτηριστικά που να τον ενδιαφέρουν. Σε αυτό το βήμα ο χρήστης έχει τη δυνατότητα να δώσει βάρη σε αυτά τα νέα κριτήρια και να κάνει αναπροσαρμογή των προηγούμενων βαρών.

Σχήμα 10.3 Το μοντέλο σύνθεσης εξατομικευμένων υπηρεσιών

Εφαρμογή

Η μεθοδολογία αποτελείται από συγκεκριμένες φάσεις. Η πρώτη φάση αφορά την εισαγωγή των λειτουργικών χαρακτηριστικών. Οι επόμενες δύο φάσεις αφορούν τον ορισμό των βαρών, ενώ οι τελευταίες φάσεις αφορούν την εφαρμογή της AHP μεθόδου.

Εδώ θα πρέπει να αναφερθεί πως ενώ η AHP δέχεται μόνο αριθμητικές τιμές για τις αξιολογήσεις των κριτηρίων, είναι δυνατή και η χρήση μη-αριθμητικών τιμών οι οποίες μπορούν να μετατραπούν σε αριθμητικές, μέσω κανονικοποίησης.

Το χαρακτηριστικό αυτό επιτρέπει μια πιο φιλική προς τον χρήστη προσέγγιση καθώς οι πιθανές επιλογές μπορούν να αποτελούν μέρος μιας κλίμακας Likert.

Φάση πρώτη:

Ο τελικός χρήστης ορίζει τα λειτουργικά χαρακτηριστικά που επιθυμεί να υφίστανται από την τελική σύνθεση. Η μηχανή σύνθεσης επιστρέφει ένα πλήθος από ΥΙ που ικανοποιούν τις λειτουργικές αυτές ανάγκες του χρήστη.

Φάση δεύτερη:

Ο χρήστης δίνει ως είσοδο ένα πλήθος από χαρακτηριστικά ποιότητας υπηρεσιών (UsQoS), μέσα από μια προκαθορισμένη λίστα χαρακτηριστικών QoSi (όπου i=1, 2…n) και τα οποία είναι καταχωρημένα στο μητρώο. Ο χρήστης επιπρόσθετα δίνει τις κατά-ζεύγη συγκρίσεις που προσδιορίζουν τα βάρη (UserWeights) των κριτηρίων. Έτσι για παράδειγμα για UsQoSi, όπου i = 3 ο χρήστης μπορεί να δώσει τις παρακάτω επιλογές:

{(UsQoS1, UsQoS2, PwC12), (UsQoS2, UsQoS3, PwC23), (UsQoS1, UsQoS3, PwC13)}, όπου τα πεδία UsQoS(a) και UsQoS(b) αντιστοιχούν στις ονομασίες παραμέτρων ποιότητας, ενώ το πεδίο PwC(ab) αντιστοιχεί σε μια τιμή που προσδιορίζει την προτίμηση του χρήστη στην παράμετρο ποιότητας UsQoSa σε σχέση με την παράμετρο UsQoSb.

Με βάση τις τιμές των βαρών αλλά και των αρχών της AHP μεθοδολογίας, ένας αρχικός πίνακας Eigenvector υπολογίζεται, ο οποίος φανερώνει ποια είναι τα κριτήρια τα οποία είναι πιο σημαντικά για τον χρήστη.

Επιπρόσθετα, ο χρήστης επιλέγει το πόσο αυστηρή επιθυμεί να είναι η μηχανή σύνθεσης σε ότι αφορά τις ΥΙ που έχει βαθμολογίες μόνο σε έναν αριθμό από τα ζητούμενα QoS κριτήρια και όχι σε όλα. Η επιστρεφόμενη απάντηση, με βάση και το βαθμό αυστηρότητας, μπορεί να είναι της μορφής:

ProvQoSWS1 = {(QoS1, value1), (QoS3, value3), (QoS4, value4)}

…..

ProvQoSWSm = {(QoS1, value1), (QoS4, value4), (QoS6, value6)}

Οι τιμές αυτές αποτελούν μια λίστα ΥΙ (πλήθους m) που έχουν τιμές ορισμένες από τους παρόχους (ProvQoS) για κάποια ή για όλα τα απαιτούμενα QoS χαρακτηριστικά. Τυπικά επιλέγουμε να απορρίψουμε ΥΙ που δεν έχουν βαθμολογήσεις σε χαρακτηριστικά με τη μεγαλύτερη βαρύτητα όπως αυτή προκύπτει από τον Eigenvector.

Φάση τρίτη:

Η επιστρεφόμενη λίστα ΥΙ μπορεί να διαφοροποιηθεί ως ακολούθως: κάποια κριτήρια μπορούν να εμφανίζονται στις επιστρεφόμενες ΥΙ, τα οποία να μην είχαν ληφθεί υπόψη από τον τελικό χρήστη στο προηγούμενο στάδιο. Έτσι, σε αυτή τη φάση ο χρήστης μπορεί να ενισχύσει τις προηγούμενες επιλογές του με κάποια επιπλέον QoS κριτήρια.

Είναι σημαντικό να τονιστεί πως τόσο τα ProvQoS κριτήρια όσο και τα UsQoS κριτήρια είναι υποσύνολα του συνολικού QoS, ενώ αντιπροσωπεύουν υποκειμενικές βαθμολογήσεις κριτηρίων από διαφορετικές σκοπιές, κι έτσι η τομή τους ισοδυναμεί με το μηδέν.

ProvQoS ⊆ QoS
UsQoS ⊆ QoS
UsQoS ∩ ProvQoS = ∅

Φάση τέταρτη:

Σε κάθε σενάριο που ενσωματώνει τις τεχνολογίες του Web 2.0, είναι καθοριστικής σημασίας η αξιοποίηση των αξιολογήσεων των χρηστών. Προηγούμενοι χρήστες των ΥΙ που συμμετέχουν σε μια σύνθεση, μπορούν να δώσουν αξιολογήσεις σχετικές με το επίπεδο της ικανοποίησης τους. Αυτές οι αξιολογήσεις, όπως είναι φυσικό, είναι υποκειμενικές και διαφέρουν σημαντικά από τις ProvQoS και UsQoS τιμές. Έτσι, για παράδειγμα, το επίπεδο της ασφάλειας έτσι όπως το αντιλαμβάνεται κάποιος τελικός χρήστης, είναι ένα EvQoS χαρακτηριστικό, που διαφέρει από το ProvQoS χαρακτηριστικό της ασφάλειας. Σε αυτή τη φάση ένα πλήθος EvQoS προστίθενται.

Φάση πέμπτη:

Σε αυτή τη φάση η AHP μεθοδολογία εφαρμόζεται. Τα βήματα είναι τα ακόλουθα:

Βήμα 1

Σαν αποτέλεσμα της προσθήκης των ProvQoS και EvQoS κριτηρίων, ο δισδιάστατος πίνακας έχει συμπληρωθεί μερικώς με αξιολογήσεις. Στη συνέχεια θα πρέπει να συμπληρωθεί με τις επιπρόσθετες κατά-ζεύγη συγκρίσεις. Σε ένα παράδειγμα που περιλαμβάνει 3 UsQoS, 2 ProvQoS και 2 EvQoS κριτήρια, ο πίνακας συγκρίσεων διαμορφώνεται ως εξής:

Πίνακας 10.1 Πίνακας συγκρίσεων κατά-ζεύγη

Βήμα 2

Στο επόμενο βήμα γίνεται ο υπολογισμός του eigenvector έτσι ώστε να ληφθούν οι προτεραιότητες (τα βάρη) των κριτηρίων. Σύμφωνα με τη μεθοδολογία της AHP, μετά τη μετατροπή των κλασμάτων σε δεκαδικούς αριθμούς, ο δισδιάστατος πίνακας υψώνεται στο τετράγωνο. Ο παρακάτω πίνακας Xij (πίνακας 10.2) συμβολίζει το αποτέλεσμα:

Πίνακας 10.2 Το αποτέλεσμα ύψωσης στο τετράγωνο, του δυαδικού πίνακα συγκρίσεων

Στη συνέχεια γίνεται υπολογισμός του αθροισμάτων των σειρών του πίνακα Xij με βάση τον τύπο (1)

για i=1,2,…n, όπου στο συγκεκριμένο παράδειγμα το n είναι ίσο με 7, καθώς αυτός είναι ο αριθμός των κριτηρίων.
Ο πίνακας eigenvector υπολογίζεται με βάση τον τύπο (2):

Η διαδικασία αυτή επαναλαμβάνεται υψώνοντας στο τετράγωνο τον πίνακα Xij και υπολογίζοντας το νέο πίνακα eigenvector, μέχρις ότου να μην υπάρχουν σημαντικές διαφορές ανάμεσα στους πίνακες eigenvectors.

Βήμα 3

Στο τρίτο βήμα σχηματίζεται ένας δυαδικός πίνακας κατά-ζεύγη συγκρίσεων, για κάθε ένα από τα κριτήρια, όπου κάθε πίνακας περιέχει συγκρίσεις των εναλλακτικών ΥΙ, ως προς το συγκεκριμένο κριτήριο.

Σε περίπτωση λοιπόν που η μηχανή σύνθεσης επιστρέψει τέσσερις ΥΙ που ικανοποιούν τα λειτουργικά κριτήρια και καθώς έχουμε επτά κριτήρια ποιότητας που λαμβάνουμε υπόψη στο συγκεκριμένο παράδειγμα, συνολικά θα δημιουργηθούν επτά δισδιάστατοι πίνακες AltEVk (για k=1,2,3,4) μεγέθους 4x4. Οι πίνακες αυτοί θα είναι της μορφής:

Πίνακας 10.3 Ενδεικτικός δισδιάστατος πίνακας κατά-ζεύγη συγκρίσεων για ένα κριτήριο

Στον παραπάνω πίνακα οι θέσεις C₁₁, C₂₂, C₃₃ και C₄₄ είναι ίσες με τη μονάδα καθώς δεν μπορεί να γίνει σύγκριση μιας ΥΙ με τον εαυτό της. Το βήμα ολοκληρώνεται με τον υπολογισμό του eigenvector (με χρήση του τύπου (1)) για κάθε έναν πίνακα AltEVk, κάτι που τελικά επιτρέπει τον υπολογισμό των βαρών για κάθε εναλλακτική ΥΙ για κάθε κριτήριο.

Βήμα 4

Το σχήμα 10.4 παρουσιάζει την ιεραρχική δομή του προβλήματος μετά την τοποθέτηση των τιμών του κάθε eigenvector (eigenvalues)

Το τελευταίο βήμα αυτής της διαδικασίας είναι ο υπολογισμός του πίνακα κατάταξης των εναλλακτικών AR[i], με χρήση του τύπου (3):

Η ΥΙ με τη μεγαλύτερη βαθμολογία στον πίνακα AR[i] είναι η βέλτιστη ΥΙ σε σχέση με τα μη-λειτουργικά κριτήρια ποιότητας.

Σχήμα 10.4 Εφαρμογή των Eigenvalues στο ιεραρχικό δέντρο

5.2. Περίπτωση χρήσης μεθοδολογίας επιλογής ΥΙ στα πλαίσια χρήσης εντός ενός εμπορικού καταστήματος

Μελέτη περίπτωσης (Case study)

Η ενσωμάτωση των ιδεών του Web of Things (WoT) έχει ιδιαίτερο ενδιαφέρον σε σενάρια που περιλαμβάνουν συναλλαγές ηλεκτρονικού εμπορίου, μέσω φορητών συσκευών, σε συνδυασμό με τη φυσική παρουσία του χρήστη στο χώρο των συναλλαγών. Στο παρακάτω παράδειγμα θεωρούμε πως σε ένα εμπορικό κέντρο προσφέρονται πληροφορίες και συστάσεις μαζί με ένα πλήθος αποκλειστικών υπηρεσιών σε επισκέπτες που κάνουν χρήση της εφαρμογής (application) του εμπορικού καταστήματος για έξυπνες συσκευές. Οι επισκέπτες έχουν τη δυνατότητα χρήσης τόσο «φυσικών» όσο και «εικονικών» ΥΙ. «Φυσικές» ΥΙ μπορούν να είναι υπηρεσίες που προέρχονται από τη λειτουργικότητα φυσικών αντικειμένων, για παράδειγμα κάποιοι ψυγειοκαταψύκτες σε ένα κατάστημα προσφέρουν πληροφορίες για την κατάσταση των προϊόντων που περιέχουν, πληροφορίες οι οποίες συνδυάζονται εύκολα με πληροφορίες «εικονικών» ΥΙ που δείχνουν π.χ. μια έκπτωση στα προϊόντα αυτά. Σε ένα τέτοιο παράδειγμα μπορεί να γίνει χρήση τόσο ΥΙ τύπου SOAP όσο και ΥΙ τύπου REST.

Εκφώνηση:

Αξιοποιώντας τη μεθοδολογία που περιεγράφηκε στην προηγούμενη ενότητα, να περιγραφεί ένα σενάριο επιλογής ΥΙ, με βάση συγκεκριμένα κριτήρια ποιότητας, στα πλαίσια χρήσης ενός εμπορικού καταστήματος.

Υποδειγματική λύση:

Φάση Πρώτη:

o Στην πρώτη φάση υποθέτουμε πως ο χρήστης εισάγει μια λίστα από λειτουργικές απαιτήσεις, βασισμένες στις ανάγκες του αλλά και σε συστάσεις που δέχεται από τα καταστήματα. Έτσι λαμβάνει μια λίστα από πέντε ΥΙ (WSi για i=1, 2, ..,5) που ικανοποιούν τα λειτουργικά κριτήρια.

Φάση Δεύτερη:

o Ο χρήστης καλείται να επιλέξει τα χαρακτηριστικά ποιότητας που τον ενδιαφέρουν και να δώσει τις κατά-ζεύγη συγκρίσεις του, που καθορίζουν τα βάρη των κριτηρίων. Η μορφή εισόδου είναι του τύπου {(UsQoSi, UsQoSj, PwCij), …}

o Σε αυτό το σενάριο ο χρήστης επιλέγει τα κριτήρια ‘ασφάλεια’ (Security - UsQoS1), ‘διαθεσιμότητα’ (Αvailability - UsQoS2) και ‘αξιοπιστία’ (Reliability - UsQoS3) ως εξής:{(Security, Availability - 6), (Security, Reliability - 8), (Reliability, Availability – 2)}

o Μια λίστα από ΥΙ που έχουν βαθμολογήσεις (από τους παρόχους) για τις τιμές αυτές επιστέφονται στον χρήστη.

ProvQoSWS1 = {(Security, 8), (Availability, 6), (Reliability, 7), (Capacity, 6)}

ProvQoSWS2 = {(Security, 7), (Reliability, 6), (Performance, 7), (Robustness, 4)}

ProvQoSWS3 = {(Security, 7), (Availability, 7)}

ProvQoSWS4 = {(Security, 9), (Availability, 8), (Reliability, 7)}

ProvQoSWS5 = {(Availability, 8), (Performance, 8)}

o Η ΥΙ WS5 θα παραλειφθεί καθώς από αυτήν απουσιάζουν βαθμολογήσεις για τα πιο σημαντικά κριτήρια με βάση τα βάρη που δόθηκαν πριν.

Φάση Τρίτη και φάση Τέταρτη:

o Σε περίπτωση μη επιλογής επιπρόσθετων κριτηρίων ποιότητας από τον χρήστη, γίνεται η ενσωμάτωση των εξωτερικών βαθμολογήσεων από άλλους χρήστες.

o Σε αυτό το παράδειγμα ο χρήστης λαμβάνει τιμές για την εκλαμβανόμενη από τους χρήστες ασφάλεια (EvSecurity) και την εκλαμβανόμενη από τους χρήστες αξιοπιστία (EvReliability).

Φάση Πέμπτη:

o Βήμα 1: Αφού προστεθούν τα ProvQoS και EvQoS κριτήρια, ο δισδιάστατος πίνακας των κατά-ζεύγη συγκρίσεων πρέπει να συμπληρωθεί από τον χρήστη. Σε αυτό το παράδειγμα ο πίνακας έχει ως εξής:

Πίνακας 10.4 Συνολικός πίνακας κατά-ζεύγη συγκρίσεων

o Βήμα 2: Με τη μετατροπή των κλασμάτων σε δεκαδικούς αριθμούς και με την ύψωση του πίνακα στο τετράγωνο σχηματίζεται ο επόμενος πίνακας.

Πίνακας 10.5 Ο πίνακας μετά την ύψωση στο τετράγωνο

o Κάνοντας χρήση των τύπων (1) και (2) γίνεται υπολογισμός του Eigenvector, όπου:

Ev = [0.4962, 0.1183, 0.1709, 0.0482, 0.0243, 0.1115, 0.0306]

o Βήμα 3: Σε αυτό το βήμα ο χρήστης καλείται να συμπληρώσει τιμές σε επτά πίνακες συγκρίσεων, έναν για κάθε ένα από τα επιλεχθέντα κριτήρια

Πίνακας 10.6 Ενδεικτικοί πίνακες κατά-ζεύγη συγκρίσεων για 2 κριτήρια

o Ακολουθώντας τη διαδικασία που είδαμε παραπάνω γίνεται υπολογισμός των επτά eigenvectors

o Βήμα 4: Με βάση τις πληροφορίες που συλλέχθηκαν στα προηγούμενα βήματα, γίνεται ο υπολογισμός της τελικής κατάταξης των εναλλακτικών ΥΙ με βάση τον (3): AR = [0.564, 0.263, 0.125, 0.048]

o Το σχήμα 10.5 δείχνει την τελική βαθμολόγηση και κατάταξη των τεσσάρων εναλλακτικών ΥΙ καθώς και την τιμή overall inconsistency όπως αυτή υπολογίζεται από το εργαλείο Expert Choice, και φανερώνει το κατά πόσο έχει γίνει με σωστό τρόπο η βαθμολόγηση των κριτηρίων και των εναλλακτικών, δηλαδή την ύπαρξη συνοχής. Η τιμή αυτή θα πρέπει να είναι ίση ή και μικρότερη του 0.10.

Σημείωση: Στον Ιστότοπο του συγγράμματος (http://ec-tech.uom.gr/WT-ECOM), θα βρείτε το πηγαίο κώδικα για όλες τις υποδειγματικά λυμένες ασκήσεις

Σχήμα 10.5 Ταξινόμηση ΥΙ όπως αυτή υπολογίζεται μέσω του εργαλείου Expert Choice

6. Συμπεράσματα

Στο κεφάλαιο αυτό παρουσιάστηκε ένα σύνολο εργαστηριακών ασκήσεων, με σκοπό την κατανόηση τεχνικών ανάπτυξης, επιλογής και σύνθεσης ΥΙ, ενώ ιδιαίτερη έμφαση δόθηκε στις ΥΙ τύπου REST. Οι ασκήσεις αυτές έχουν υποδειγματικά επιλυθεί στα περιβάλλοντα Eclipse IDE (με χρήση του RESTlet framework) και NetBeans 7 (όπως αυτό περιλαμβάνεται στο πακέτο OpenESB 2.3.1) και χρησιμοποιούν ως βασικές γλώσσες προγραμματισμού την Java και την BPEL. Επίσης, παρουσιάστηκε αναλυτικά μια μεθοδολογία επιλογής ΥΙ η οποία κάνει χρήση τεχνικών πολυκριτήριας ανάλυσης αποφάσεων. Στόχος του κεφαλαίου ήταν η ανάπτυξη δεξιοτήτων εκ μέρους των αναγνωστών, πάνω σε τεχνολογίες που έχουν ευρεία αποδοχή για την ανάπτυξη εφαρμογών και τεχνικών που υποστηρίζουν συναλλαγές Ηλεκτρονικού Εμπορίου.

7. Τεστ αξιολόγησης

Σημείωση: Η διαβάθμιση δυσκολίας των κριτηρίων αξιολόγησης δίνεται με το πλήθος των αναγραφόμενων αστερίσκων.

8. Βιβλιογραφία

Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M. (2013). Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems, 29(7), 1645-1660.

Guinard, D., Trifa, V., Mattern, F., & Wilde, E. (2011). From the internet of things to the web of things: Resource-oriented architecture and best practices. In Architecting the Internet of Things (pp. 97-129). Springer Berlin Heidelberg.

Louvel, J., Templier T., & Boileau, T. (2012). Restlet in Action: Developing RESTful Web APIs in Java. Manning Publications Co., 2012.

Pautasso, C. (2014). RESTful web services: principles, patterns, emerging technologies. Web Services Foundations. Springer New York, 2014. 31-51.

Saaty, T. L. (1980). The analytic hierarchy process: planning, priority setting, resources allocation. New York: McGraw.

Subashini, S., & Kavitha, V. (2011). A survey on security issues in service delivery models of cloud computing. Journal of network and computer applications 34.1: 1-11.

Vesyropoulos, N., Georgiadis C.K., & Pimenidis E. (2014). Ensuring Cloud Security: Current Concerns and Research Challenges. E-Democracy, Security, Privacy and Trust in a Digital World. Springer International Publishing, 3-10.

Vesyropoulos, N., Georgiadis, C. K. (2015). Customized QoS-based Mashups for the Web of Things: An Application of AHP. Computer Science and Information Systems, Vol. 12, No. 1, 115–133.

Want, R., Schilit, B. N., & Jenson, S. (2015). Enabling the Internet of Things. Computer, (1), 28-35.

Τέλος Κεφαλαίου

Περιεχόμενα

1. Εισαγωγή

2. Ανάπτυξη Υπηρεσιών Ιστού REST

2.1. Εισαγωγή στο RESTlet framework

2.2. Ανάπτυξη ΥΙ διαχείρισης λογαριασμών χρηστών

3. Υπολογιστική Νέφους (Cloud Computing) και σχετικά Ζητήματα Ασφάλειας για Εφαρμογές Ηλεκτρονικού Εμπορίου

3.1. Ζητήματα ασφαλείας στην υπολογιστική νέφους

3.2. Εφαρμογή Restlet στο Google App Εngine

4. Δημιουργία Ενορχήστρωσης BPEL για τη σύνθεση ΥΙ

Δημιουργία του WSDL Document

5. Επιλογή ΥΙ με χρήση τεχνικών πολυκριτήριας ανάλυσης αποφάσεων

5.1. Εξατομικευμένη επιλογή και σύνθεση με βάση κριτήρια ποιότητας παρεχόμενων υπηρεσιών

5.2. Περίπτωση χρήσης μεθοδολογίας επιλογής ΥΙ στα πλαίσια χρήσης εντός ενός εμπορικού καταστήματος

6. Συμπεράσματα

7. Τεστ αξιολόγησης

8. Βιβλιογραφία