ΣΔΥ50 - ΓE3 2011-2012 -Ενδεικτικές απαντήσεις.pdf

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Σ∆Υ50 – Βασικές τεχνολογίες δικτύων και λογισµικού

ΟΝΟΜΑΤΕΠΩΝΥΜΟ:

ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

1

ΕΝΔΕΙΚΤΙΚΗ ΕΠΙΛΥΣΗ

ΤΡΙΤΗ ΓΡΑΠΤΗ ΕΡΓΑΣΙΑ (ΓΕ3)

Θέμα 1 – Πολυ-νηματικές Αρχιτεκτονικές Εξυπηρετητών (30 μονάδες)

Ερώτημα Α. Υλοποίηση ταυτόχρονου εξυπηρετητή με Java Sockets (20 μονάδες)

Θέλουμε να αναπτύξουμε έναν ταυτόχρονο εξυπηρετητή αριθμητικών υπολογισμών σε Java

χρησιμοποιώντας sockets για την διαδιεργασιακή επικοινωνία. Ο πελάτης δημιουργεί μια διεπαφή

χρήστη για την επιλογή των τεσσάρων βασικών αριθμητικών πράξεων : πρόσθεση, αφαίρεση,

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

επιλέξει την αριθμητική πράξη και εισάγει δύο αριθμούς, το πρόγραμμα πελάτη στέλνει τα

δεδομένα στον εξυπηρετητή. Ο εξυπηρετητής εκτελεί την πράξη και επιστρέφει πίσω στον πελάτη

το αποτέλεσμα. Το αποτέλεσμα τυπώνεται στην οθόνη του πελάτη. Να ορίσετε εκτός των άλλων και

μια κλάση CalculatorLogistics, αντικείμενα της οποίας θα χρησιμοποιούνται για τη διακίνηση της

πληροφορίας μεταξύ του προγράμματος του πελάτη και του εξυπηρετητή (είδος αριθμητικής

πράξης, αριθμούς και αποτέλεσμα). Υποθέστε ότι ο server εκτελείται στο port 18500.

Να δώσετε μια σύντομη περιγραφή του ρόλου της κάθε κλάσης που θα υλοποιήστε.

Να παρέχετε οδηγίες για την εκτέλεση τόσο του πελάτη όσο και του εξυπηρετητή.

Απάντηση 1.Α

Η κατανεμημένη εφαρμογή υλοποιήθηκε σε περιβάλλον Netbeans. Περιλαμβάνει ένα project

(sdy50_2011_2012_erg3_Q1) που οργανώνεται σε 3 πακέτα:

• client: υλοποιεί τον client ως ένα Java Desktop Application και περιλαμβάνει τις κλάσεις:

App, View, ClientAppLogic και AboutBox.

• server: υλοποιεί έναν ταυτόχρονο εξυπηρετητή (concurrent server) σύμφωνα με τις

προδιαγραφές της άσκησης και περιλαμβάνει τις κλάσεις: App και CalculatorService.

• common: περιλαμβάνει κοινές κλάσεις που χρησιμοποιούνται τόσο από τον client όσο και

από τον server : NetCommBase, CalculatorConstants και

CalculatorLogistics.

Οι κλάσεις CalculatorService και ClientAppLogic υλοποιούν το απλό request/reply πρωτόκολλο της

εφαρμογής. Και οι δύο κλάσεις κάνουν extend την κλάση NetCommBase και υλοποιούν την

διασύνδεση CalculatorConstants.

Για την αναπαράσταση της δομής των μηνυμάτων υλοποιήθηκε η κλάση CalculatorLogistics. Όταν ο

πελάτης θέλει να ζητήσει την εκτέλεση μιας λειτουργίας, «πακετάρει» την πληροφορία σε ένα

αντικείμενο τύπου CalculatorLogistics και το αποστέλλει ως μήνυμα-αντικείμενο στον εξυπηρετητή.

Ένα CalculatorLogistics αντικείμενο περιλαμβάνει τον κωδικό της πράξης (ορίζεται στην διασύνδεση

CalculatorConstants) και τα δύο ορίσματα της πράξης. Το ίδιο αντικείμενο χρησιμοποιείται και από

την πλευρά του εξυπηρετητή για τα μηνύματα απάντησης που αποστέλλονται προς τον πελάτη. Η

κλάση CalculatorLogistics πρέπει να υλοποιεί το Serializable interface.



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

2

H κλάση View υλοποιεί το main GUI του client και εν μέρει παράγεται σε design mode κατά την

σχεδίαση της διεπαφής του client (Java Desktop Application1).

Η εφαρμογή τρέχει μέσα από το Netbeans. Αρχικά τρέχουμε τον server (κλάση server.App). Για

να τρέξουμε έναν ή περισσότερους clients τρέχουμε την main class στο client πακέτο (δεξί κλικ στο

client.App και επιλογή Run File).

Επισυνάπτεται ο κώδικας σε μορφή Netbeans project.

Ερώτημα Β. Πολλαπλές διεργασίες έναντι πολυνηματικής διεργασίας (5 μονάδες)

Η ανάπτυξη ενός ταυτόχρονου εξυπηρετητή με δυνατότητα γέννησης νέων διεργασιών παρουσιάζει

μερικά πλεονεκτήματα, αλλά και μειονεκτήματα σε σύγκριση με τους πολυνηματικούς

εξυπηρετητές. Να αναφέρετε ένα τουλάχιστον πλεονέκτημα και δύο τουλάχιστον μειονεκτήματα.

(Απαντήσεις ~ 120 λέξεις).

Απάντηση 1.Β

Ένα σημαντικό πλεονέκτημα είναι ότι οι διαφορετικές διεργασίες είναι η κάθε μια προστατευμένη

έναντι της άλλης, το οποίο μπορεί να είναι απολύτως απαραίτητο, όπως για παράδειγμα στην

περίπτωση ενός σύνθετου εξυπηρετητή που παρέχει ανεξάρτητες υπηρεσίες σε διαφορετικούς

χρήστες. Από την άλλη πλευρά, η γέννηση διεργασιών είναι μια δαπανηρή λειτουργία που μπορεί

να αποφευχθεί όταν χρησιμοποιούμε πολυνηματικούς εξυπηρετητές. Επιπλέον, εάν απαιτείται οι

διεργασίες να επικοινωνήσουν μεταξύ τους, τότε η υλοποίηση με νήματα κοστίζει λιγότερο σε

επιβάρυνση καθώς σε πολλές περιπτώσεις μπορούμε να αποφύγουμε την διαμεσολάβηση του

πυρήνα του Λειτουργικού Συστήματος για την επικοινωνία (κάτι που δεν συμβαίνει με την

διαδιεργασιακή επικοινωνία).

Ερώτημα Γ – Απόδοση (5 μονάδες)

Ένας file server που υλοποιείται με νήματα επιπέδου χρήστη μπορεί να τρέξει σε ένα πολυ-

επεξεργαστικό σύστημα με Ν επεξεργαστές. Πόσα νήματα θεωρητικά θα πρέπει να

χρησιμοποιηθούν ώστε να μεγιστοποιηθεί η απόδοση του server με την αξιοποίηση των διαθέσιμων

επεξεργαστών; Αιτιολογήστε σύντομα την απάντησή σας. Θεωρήστε ότι δεν υπάρχει ανταγωνισμός

από άλλες διεργασίες.


Απάντηση 1.Γ

Ένας πoλυνηματικός server που υλοποιείται με νήματα επιπέδου χρήστη δεν μπορεί να αξιοποιήσει

ταυτόχρονα τους διαφορετικούς επεξεργαστές σε ένα πολυπεξεργαστικό σύστημα. Το Λειτουργικό

Σύστημα βλέπει μόνο μια διεργασία και δεν μπορεί να δρομολογήσει τα διαφορετικά νήματα της

1 Το Swing Application Framework δεν υποστηρίζεται στο Netbeans 7.1 ως προς την παραγωγή εφαρµογών,

αλλά η εκτέλεση SAF-based εφαρµογών γίνεται κανονικά.



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

3

διεργασίας σε ξεχωριστούς επεξεργαστές. Κατά συνέπεια, δεν υπάρχει βελτίωση της απόδοσης από

την εκτέλεση αυτού του server στο πολυεπεξεργαστικό σύστημα.

Θέμα 2 – Java RMI (34 μονάδες)

Ζητείται η υλοποίηση με Java RMI μιας απομακρυσμένης υπηρεσίας η οποία θέλουμε να υπολογίζει

την Ευκλείδεια απόσταση μεταξύ δύο σημείων του επιπέδου. Αν δεν οριστεί το ένα σημείο,

χρησιμοποιείται ως προεπιλεγμένο σημείο η αρχή των αξόνων αναφοράς. Για την αναπαράσταση

ενός σημείου θα πρέπει να οριστεί σχετική κλάση. Ο εξυπηρετητής δημιουργεί ένα αντικείμενο

εξυπηρέτησης, ενώ ο πελάτης ζητά την απομακρυσμένη υπηρεσία. Να δημιουργήσετε μια απλή

διεπαφή χρήστη για την είσοδο του/των σημείου/σημείων.

Ερώτημα Α – Υλοποίηση απομακρυσμένης υπηρεσίας (25 μονάδες)

• Να υλοποιήσετε με Java RMI όλες τις κλάσεις/διασυνδέσεις που απαιτούνται.

• Να δώσετε μια σύντομη περιγραφή του ρόλου της κάθε κλάσης/διασύνδεσης που θα

υλοποιήστε.

• Να παρέχετε οδηγίες για την εκτέλεση τόσο του πελάτη όσο και του εξυπηρετητή.


Η υλοποίηση της εφαρμογής έγινε στο περιβάλλον Netbeans. Η διαμόρφωση της εφαρμογής

ακολουθεί παρόμοια λογική με αυτή της εφαρμογής του θέματος 1.Α. Έχουμε δηλαδή ένα project

(sdy50_2011_2012_erg3_Q2) που οργανώνεται σε 3 πακέτα:

• client: υλοποιεί τον client ως ένα Java GUI application και περιλαμβάνει τις κλάσεις: App,

GUI και DistanceClient.

• server: υλοποιεί έναν απομακρυσμένο εξυπηρετητή σύμφωνα με τις προδιαγραφές της

άσκησης και περιλαμβάνει τις κλάσεις: DistanceServer και

DistanceCalculatorServant.

• common: περιλαμβάνει κοινές κλάσεις που χρησιμοποιούνται τόσο από τον client όσο και

από τον server: DistanceCalculator, Point και MyRMISecurityManager (από

ερώτημα 2.Β).

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

Point.java : H κλάση αυτή περιγράφει ένα σημείο του επιπέδου. Η κλάση Point χρησιμοποιείται ως

παράμετρος των κλήσεων απομακρυσμένων μεθόδων, άρα θα πρέπει να υλοποιεί την διεπαφή

java.io.Serializable.

DistanceCalculator.java : H κλάση αυτή ορίζει την απομακρυσμένη διασύνδεση (remote interface)

της υπηρεσίας η οποία υπολογίζει την Ευκλείδεια απόσταση μεταξύ δύο σημείων του επιπέδου.

DistanceCalculatorServant.java : Η κλάση αυτή υλοποιεί την απομακρυσμένη διασύνδεση

DistanceCalculator. Η κλάση υλοποιεί τις μεθόδους μόνον της διασύνδεσης, χωρίς να προσθέτει

άλλες επιπλέον μεθόδους (οι οποίες δεν θα ήταν προσπελάσιμες απομακρυσμένα). Η κλάση αυτή



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

4

στην πραγματικότητα χρησιμοποιείται για να δημιουργηθεί το αντικείμενο εξυπηρέτησης (servant)

της κατανεμημένης εφαρμογής.

DistanceServer.java : Η κλάση αυτή υλοποιεί έναν απλό εξυπηρετητή ο οποίος φιλοξενεί την

απομακρυσμένη υπηρεσία RMI. O εξυπηρετητής φιλοξενεί παροδικά απομακρυσμένα αντικείμενα

και είναι υπεύθυνος για την δημιουργία του ενός αντικειμένου εξυπηρέτησης (servant) και την

εγγραφή αυτού του αντικείμενου στον δεσμευτή (RMIregistry).

DistanceClient.java : H κλάση αυτή υλοποιεί τον κώδικα του πελάτη. Ο πελάτης αποκτά μια

αναφορά προς το απομακρυσμένο αντικείμενο με το να συνδεθεί με το απομακρυσμένο μητρώο και

να ζητήσει το αντικείμενο με το όνομά του.

Αρχικά θα πρέπει να μεταγλωττίσουμε όλες τις παραπάνω κλάσεις.

Ακολούθως, θα πρέπει να χρησιμοποιήσουμε τον μεταγλωττιστή RMI, rmic, για να πάρουμε τις

κλάσεις σκελετού (skeleton) και πληρεξούσιου (proxy ή stub).

Χρησιμοποιούμε το script που δημιουργήσαμε στον root φάκελο του Netbeans project με όνομα

“create_stub_class_and_start_rmiregistry” το οποίο εκτός από την παραγωγή των

κλάσεων ξεκινά και το μητρώο RMI υπηρεσιών στον εξυπηρετητή (rmiregistry). Σαν

αποτέλεσμα θα παραχθούν τα αρχεία DistanceCalculatorServant_Stub.class και DistanceCalculatorServant_Skel.class2

Κατόπιν ξεκινάμε διαδοχικά την εκτέλεση του εξυπηρετητή (κλάση server.DistanceServer)

και του πελάτη (κλάση client.App).

Επισυνάπτεται ο κώδικας σε μορφή Netbeans project.

Ερώτημα B – Ασφάλεια (9 μονάδες)

Κατά την ανάπτυξη κατανεμημένων προγραμμάτων με RMI μας ενδιαφέρει να μπορούμε να

περιορίσουμε τις ενέργειες που εκτελούνται από κλάσεις που μεταφορτώνονται από το δίκτυο (π.χ.

από έναν πληρεξούσιο που παρέχει την διασύνδεση ενός απομακρυσμένου αντικειμένου σε RMI

υλοποίηση). Σε αντίθετη περίπτωση μπορεί η εφαρμογή μας να είναι εκτεθειμένη σε μη ασφαλή

κώδικα που μπορεί να αποκτήσει πρόσβαση σε πόρους του τοπικού συστήματος. Πως μπορούμε να

αντιμετωπίσουμε το πρόβλημα αυτό σε Java RMI; Δώστε μια σύντομη περιγραφή της προσέγγισης

για διαχείριση ασφάλειας που προτείνετε.

Στη συνέχεια να επεκτείνετε την εφαρμογή που υλοποιήσατε με βάση την προσέγγιση που

προτείνετε έτσι ώστε να επιτρέπονται σε κλάσεις όπως οι πληρεξούσιοι μόνον οι σχετικές με sockets

λειτουργίες (accept, connect και listen).


2 Οι νεότερες εκδόσεις της Java µέσω του rmic παράγουν µόνον stub κλάσεις για το 1.2 JRMP stub protocol.

∆εν παράγονται skeleton κλάσεις καθώς αυτές δεν υποστηρίζονται στην έκδοση 1.2 του stub protocol. Οι

παραγόµενες stub κλάσεις δεν θα λειτουργήσουν αν φορτωθούν στην JDK 1.1 virtual machine.



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

5


Μπορούμε να εγκαταστήσουμε έναν ειδικό Διαχειριστή Ασφαλείας (Security Manager) για το

σύστημα RMI με χρήση της μεθόδου setSecurityManager της κλάσης System της Java.

O διαχειριστής ασφαλείας RMI επιβάλλει μια πολιτική ασφαλείας για απομακρυσμένους

πληρεξούσιους όταν αυτοί φορτώνονται από κάποια (πιθανόν εχθρική) πηγή του δικτύου στο

τοπικό περιβάλλον Java, για να απαγορεύσει μη εξουσιοδοτημένη πρόσβαση σε τοπικούς πόρους.

Εξ ορισμού ένα Java RMI πρόγραμμα δεν εγκαθιστά κάποιον διαχειριστή ασφάλειας. Αν μια

διεργασία εξυπηρετητή ή πελάτη δεν εγκαταστήσει έναν διαχειριστή ασφαλείας RMI, τότε οι

κλάσεις των πληρεξούσιων (stubs ή proxies) μπορούν να φορτωθούν μόνο από το τοπικό σύστημα

αρχείων κάθε διεργασίας και όχι μέσω δικτύου.

Το java.rmi πακέτο παρέχει μια προκαθορισμένη υλοποίηση διαχειριστή ασφαλείας που μπορεί

να ενεργοποιηθεί με κώδικα όπως ο παρακάτω:

if (System.getSecurityManager() == null)

System.setSecurityManager(new RMISecurityManager());

Η προκαθορισμένη υλοποίηση του διαχειριστή ασφαλείας περιέχει διάφορες μεθόδους για τον

έλεγχο της πρόσβασης σε sockets, αρχεία, κ.α. Η προκαθορισμένη πολιτική που ακολουθείται είναι

αυστηρή με την έννοια ότι οι μέθοδοι του διαχειριστή δεν επιτρέπουν καμιά προσπέλαση.

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

εξειδικευμένες πολιτικές ασφαλείας.

Ο παρακάτω διαχειριστής ασφαλείας επιτρέπει τις ζητούμενες με sockets λειτουργίες:

public class MyRMISecurityManager extends RMISecurityManager

public MyRMISecurityManager()

super();

public void checkAccept(String host, int port)

public void checkConnect(String host, int port)

public void checkConnect(String host, int port, Object

executionContext)

public void checkListen(int port)

// MyRMISecurityManager

Ο διαχειριστής ασφάλειας επαναορίζει (overrides) τις μεθόδους check(Aceept|Connect|Listen)

ώστε απλά να επιστρέφουν χωρίς να εμποδίζουν έτσι την εκτέλεση των αντίστοιχων λειτουργιών.

Αυτές οι check μέθοδοι καλούνται από διάφορες μεθόδους στις βιβλιοθήκες της Java πριν οι

τελευταίες εκτελέσουν δυνητικά ευαίσθητες λειτουργίες.

Εναλλακτική προσέγγιση



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

6

Μπορούμε να αυξήσουμε την ασφάλεια της εφαρμογής μας φορτώνοντας τον default

SecurityManager που παρέχει η Java RMI με την προσθήκη του ακόλουθου κώδικα στον

εξυπηρετητή και στον πελάτη:

if(System.getSecurityManager() == null)

System.setSecurityManager(new RMISecurityManager());

System.out.println("RMISecurityManager enabled…");

Αν δεν έχουμε ορίσει το δικό μας policy αρχείο ο SecurityManager θα κοιτάξει για το default αρχείο

στο java.home/lib/security/java.policy όπου είναι εγκαταστημένο το JDK ή το JRE.

Ενδεχομένως να ορίζεται και το default αρχείο user.home/.java.policy που αν υπάρχει

λαμβάνεται και αυτό υπόψη κατά σειρά. Με τη χρήση policy αρχείων, μπορούμε να περιορίσουμε

τις ενέργειες που εκτελούνται από τον πληρεξούσιο του πελάτη. Πιο συγκεκριμένα, με ένα policy

αρχείο, μπορούμε να καθορίσουμε διαφορετικούς τύπους πρόσβασης σε κάθε είδος τοπικής

πληροφορίας. Το είδος της πληροφορίας μπορεί να περιλαμβάνει πρόσβαση σε αρχεία, σε ιδιότητες

του συστήματος, σε επικοινωνία μέσω sockets κτλ., ενώ ο τύπος πρόσβασης μπορεί να

περιλαμβάνει για παράδειγμα δυνατότητα διαβάσματος, εκτέλεσης (για αρχεία). Μπορούμε να

χρησιμοποιήσουμε την κλάση java.net.SocketPermission και να φτιάξουμε ένα νέο policy file, που

θα περιέχει μόνο την εντολή:

grant

permission java.net.SocketPermission "localhost:1024-", "accept, connect, listen";

;

Το συγκεκριμένο policy αρχείο υποδεικνύει ότι ο server που εκτελείται στον localhost, επιτρέπει,

ακούει και δέχεται συνδέσεις σε οποιοδήποτε port μεταξύ 1024-65536 στον localhost. Μπορούμε

να χρησιμοποιήσουμε το ίδιο policy αρχείο και για τον client, ή να επιτρέπουμε το listen, accept στο

policy αρχείο του server και το connect στο policy αρχείο του client, μιας και ο πελάτης είναι αυτός

που επιχειρεί τη σύνδεση και ο εξυπηρετητής αυτός που ακούει για συνδέσεις και τις αποδέχεται.

Σημειώνεται πως ο ορισμός του policy της εφαρμογής κεντρικά στο java.policy ή στο .java.policy δεν

είναι καλή επιλογή γιατί αυτό επηρεάζει όλες τις εφαρμογές του συστήματος ή του χρήστη με τον

ίδιο τρόπο, είτε μοιράζονται τις ίδιες απαιτήσεις, είτε όχι (το πιο πιθανό). Θα πρέπει να οριστεί ένα

εξειδικευμένο policy file για την εφαρμογή το οποίο θα πρέπει να το περάσουμε ως όρισμα στην

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

java -Djava.security.manager -Djava.security.policy= myRMIapp.policy myClient

ή ακόμη καλύτερα μέσα από το Netbeans:

αν κάνουμε δεξί click στο project/properties/run και στο VM options βάλουμε τις ακόλουθες

επιλογές:

-Djava.security.manager -Djava.security.policy= myRMIapp.policy



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

7

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

στο root φάκελο του project.

Θέμα 3 – Διομότιμα Συστήματα και Υπηρεσίες Ιστού (19 μονάδες)

Ερώτημα Α – Ιδιότητες Pastry συστήματος (9 μονάδες)

Έστω ένα Pastry σύστημα με 8-bit GUIDs, τα οποία γράφονται με 4-δικά ψηφία (δηλαδή 0, 1, 2 και

3). Έστω ένας νεοεισερχόμενος κόμβος Χ στο σύστημα Pastry, με GUID: 0013 και IP: διεύθυνση

176.231.132.3. Αυτός ο κόμβος διαθέτει στοιχεία για δύο γνωστούς κόμβους Pastry Β (με GUID:

0012 και IP διεύθυνση: 176.256.23.67) και C (με GUID: 3201 και IP διεύθυνση: 176.231.132.90).

i. Πόσοι κόμβοι μπορούν να λειτουργήσουν ταυτόχρονα στο σύστημα; Θεωρείτε καλή ιδέα τα

8-bit GUIDs αν είναι εκ των προτέρων γνωστό ότι σε αυτό το Pastry σύστημα θα είναι

συνδεδεμένοι τουλάχιστον 100 Η/Υ;

ii. Πόσες γραμμές και πόσες στήλες περιλαμβάνει ένας πίνακας δρομολόγησης σε κάθε κόμβο;

Σε πόσα -το μέγιστο- βήματα ολοκληρώνεται η υπερκείμενη δρομολόγηση (overlay routing)

σε αυτό το σύστημα;

iii. Ποιον από τους κόμβους Β και C θα επιλέξει ο αλγόριθμος πλησιέστερου γείτονα (nearest

neighbor algorithm) στον X και γιατί;


i) Μπορούν να υπάρχουν κόμβοι με έως και 256 (28) διαφορετικά GUIDs στο σύστημα.

Ωστόσο, τα 8-bit GUIDs δεν είναι καλή ιδέα καθώς με 100 κόμβους θα είναι πολύ συχνό

φαινόμενο η συνάρτηση κατακερματισμού να παράγει για έναν νέο-εισερχόμενο κόμβο

κάποιο GUID που είναι ήδη σε χρήση.

ii) Ο πίνακας δρομολόγησης έχει log 2b N γραμμές (log 4 256 = 4 γραμμές) και 4 στήλες (όσα

και τα τετραδικά ψηφία). Η υπερκείμενη δρομολόγηση σε αυτό το σύστημα ολοκληρώνεται

το μέγιστο σε log4256 = 4 βήματα (όσες και οι γραμμές του πίνακα δρομολόγησης).

iii) Θα επιλέξει τον C λόγω μεγαλύτερης εγγύτητας των IP διευθύνσεων (πιθανότητα οι Χ και C

βρίσκονται στο ίδιο τοπικό δίκτυο) που εγγυάται μικρότερο κόστος για τη δρομολόγηση

μηνυμάτων μεταξύ τους στο επίπεδο μεταφοράς.

Ερώτημα Β – Υπηρεσίες Ιστού (10 μονάδες)

Η εμφάνιση του πρωτόκολλου Simple Object Access Protocol (SOAP) έδωσε το έναυσμα για την

εμφάνιση μιας νέας κατηγορίας Ενδιάμεσου Λογισμικού που χαρακτηρίζεται με το όνομα Web

Services. Τόσο το πρωτόκολλο SOAP που χρησιμοποιείται στο επίπεδο της επικοινωνίας των Web



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

8

Services, όσο και η γλώσσα περιγραφής των διεπαφών των Web Services η Web Services Description

Language, έχουν τυποποιηθεί από τον διεθνή οργανισμό World Wide Web Consortium (W3C) και

έχουν γνωρίσει ευρεία αποδοχή και υποστήριξη από μεγάλες εταιρείες. Οι προσπάθειες

τυποποίησης των Web Services συνεχίζουν, με διάφορους οργανισμούς προτύπων να εργάζονται σε

πρότυπα για την ασφάλεια, τις συναλλαγές, την αναζήτηση περιβάλλοντος, τις επιχειρησιακές

διαδικασίες, και τη διαχείριση.

Παρόλη τη μεγάλη αποδοχή που γνωρίζουν τα τελευταία χρόνια οι Υπηρεσίες Ιστού δεν αναμένεται

να αντικαταστήσουν άλλες προσεγγίσεις όπως τις CORBA και J2EE. Μερικοί μάλιστα ισχυρίζονται ότι

από τεχνολογικής άποψης στο χώρο του Ενδιάμεσου Λογισμικού οι Υπηρεσίες Ιστού δεν κομίζουν

κάτι καινούργιο και δεν αντιμετωπίζουν κάποια καινούργια θέματα.

Ποιο είναι εκείνο το ισχυρό επιχείρημα που κάνει τις Υπηρεσίες Ιστού να θεωρούνται χρήσιμες και

σημαντικές;

(Απαντήσεις ~ 200 λέξεις)

Στην διερεύνηση της απάντησής σας μπορεί να σας βοηθήσει προαιρετικά και η μελέτη του

παρακάτω άρθρου.

Vinoski S., (2003) Toward Integration: Integration With Web Services, IEEE Internet Computing, 7(6):

75–77. (http://steve.vinoski.net/pdf/IEEE-Integration_With_Web_Services.pdf)


Για την πληθώρα των κατανεμημένων συστημάτων που είναι εγκατεστημένα σήμερα και

υποστηρίζουν την λειτουργία εταιριών και οργανισμών παρατηρείται σημαντική αδυναμία

διασύνδεσης, τόσο μεταξύ των συστημάτων διαφορετικών κατασκευαστών, όσο και μεταξύ

συστημάτων διαφορετικών οργανισμών, εξ’ αιτίας της ετερογένειας που χαρακτηρίζει τις

τεχνολογίες υλοποίησης αυτών των συστημάτων. Οι Υπηρεσίες Ιστού αντιμετωπίζουν αυτές τις

διαφορές με το να δίνουν την δυνατότητα να περιγραφεί το πως αυτά τα διαφορετικά συστήματα

μπορούν να χρησιμοποιηθούν μαζί. Αν και αυτή η προσέγγιση δεν συνιστά καινοτομία, ο ορισμός

του κατάλληλου συνόλου προτύπων (SOAP, WSDL, UDDI, Web Services Choreography Definition

Language, κ.α.) που να καλύπτουν το σύνολο των απαιτήσεων των επιχειρηματικών διεργασιών που

υποστηρίζουν τα διάφορα εγκατεστημένα συστήματα αποτελεί τεχνολογική πρόκληση.

Η βασική χρησιμότητα λοιπόν των Υπηρεσιών Ιστού είναι ως εργαλείο ολοκλήρωσης ετερογενών

συστημάτων Ενδιάμεσου Λογισμικού (ΕΛ). Η χρήση της γλώσσας περιγραφής WSDL επιτρέπει στους

υπεύθυνους για την ανάπτυξη υπηρεσιών να περιγράψουν αφαιρετικά τις διεπαφές των υπηρεσιών

και να καθορίσουν τις συνδέσεις (bindings) πρωτοκόλλων που απαιτούνται κατά τον χρόνο

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

που έχουν αναπτυχθεί με διαφορετικές τεχνολογίες ΕΛ μπορούν να εξαχθούν ως Web Services για

να μπορούν να προσπελαστούν από διάφορες εφαρμογές-πελάτες, ακόμη και «μη-συμβατές» ως

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

Θέμα 4 – Κατανεμημένος προγραμματισμός (12 μονάδες)

Ερώτημα Α – Κλήση απομακρυσμένων διαδικασιών και δείκτες (6 μονάδες)



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

9

Το μοντέλο κλήσης απομακρυσμένων διαδικασιών επιτρέπει στα προγράμματα να καλούν

διαδικασίες που βρίσκονται σε άλλους Η/Υ. Όμως, δείκτες μνήμης δεν μπορούν να

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

Για ποιο λόγο δεν είναι εφικτή η χρήση δεικτών; Πως μπορεί να αντιμετωπισθεί η μη χρήση τους;



Το πρόβλημα είναι ότι οι δείκτες που χρησιμοποιούνται ως ορίσματα αναφέρονται σε μνήμη που

είναι τοπική στη διαδικασία που κάνει την κλήση. Αυτή η διεύθυνση μνήμης δεν έχει κάποια

σημασία για την καλούμενη απομακρυσμένη διαδικασία και επιπλέον το πιο πιθανό είναι ότι η

απομακρυσμένη διαδικασία δεν θα διαθέτει τη δομή δεδομένων στην μνήμη του απομακρυσμένου

υπολογιστή που έχει η καλούσα διαδικασία. Η μόνη λύση είναι να αποσταλεί ολόκληρη η δομή

δεδομένων από την καλούσα στην απομακρυσμένη διαδικασία. Μια άλλη λύση είναι να

αντικαταστήσουμε τους δείκτες με αναφορές που είναι καθολικές (global) και έγκυρες σε επίπεδο

κατανεμημένου συστήματος όπως συμβαίνει με τα remote object references στο Java RMI.

Ερώτημα Β – Σημασιολογία κλήσης (call semantics) (6 μονάδες)

Να εξηγήστε πως προκύπτει η ανάγκη για At-Least-Once και At-Most-Once invocation semantics στα

μοντέλα κατανεμημένου προγραμματισμού όπως αυτά του RPC και RMI. Μπορούμε να έχουμε

Exactly-Once invocation semantics; Εξηγήστε γιατί ναι/όχι.



Η ανάγκη για την υποστήριξη των At-Least-Once και At-Most-Once κλήσεων πηγάζει από το γεγονός

ότι το αποτέλεσμα μιας απομακρυσμένης κλήσης μπορεί να μην επιστραφεί στον client και αυτό

μπορεί να οφείλεται, είτε στην απώλεια μηνυμάτων (request/reply), είτε στην αποτυχία/κατάρευση

του server.

Η υποστήριξη της σημασιολογίας Exactly-Once, όπως εννοείται στην περίπτωση της τοπικής

κλήσης, δεν είναι εγγυημένη, επειδή στην γενική περίπτωση, όταν έχουμε απώλεια της απάντησης,

ο client δεν μπορεί να διακρίνει εάν η ενδεχόμενη κατάρρευση του server συνέβη πριν την εκτέλεση

της αιτηθείσας λειτουργίας/μεθόδου ή μετά την εκτέλεσή της και πριν την αποστολή της

απάντησης. Συστήματα που υποστηρίζουν λειτουργίες συναλλαγών (transaction-based systems)

μπορούν να πλησιάσουν την σημασιολογία exactly-once με χρήση ειδικών πρωτοκόλλων ανάνηψης

σφαλμάτων και χρήση αντιγράφων του server.

Γενικές υποδείξεις

1) Για την απάντηση της εργασίας θα πρέπει να χρησιμοποιηθεί το υπόδειγμα της εργασίας

(πρότυπο συγγραφής εργασιών), το οποίο θα βρείτε στις ιστοσελίδες της ΣΔΥ50 στη δικτυακή

πύλη του ΕΑΠ. Στο υπόδειγμα αυτό:



ΤΜΗΜΑ

ΕΡΓΑΣΙΑ Νο

10

Συμπληρώστε όλα τα στοιχεία με κίτρινο.

Αν δεν έχετε απαντήσει σε ένα ερώτημα γράψτε «ΔΕΝ ΑΠΑΝΤΗΘΗΚΕ».

Αν απαντήσατε με ελλείψεις σε ένα ερώτημα γράψτε «ΑΠΑΝΤΗΘΗΚΕ ΕΛΛΕΙΠΩΣ».

2) Η συνεργασία στην ανάλυση της εργασίας επιτρέπεται, αλλά πρέπει να αναφερθεί στον ειδικό

χώρο στην πρώτη σελίδα της εργασίας. Η συνεργασία δεν πρέπει να οδηγεί σε από κοινού

επίλυση και συγγραφή της εργασίας. Η υποβολή κοινών απαντήσεων από διαφορετικούς

φοιτητές που συνεργάστηκαν δεν επιτρέπεται και θεωρείται ως ΑΝΤΙΓΡΑΦΗ. Οι απαντήσεις

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

διαφορετικών τμημάτων. Η αντιγραφή έχει ως αποτέλεσμα το ΜΗΔΕΝΙΣΜΟ ΤΗΣ ΕΡΓΑΣΙΑΣ

ΣΥΝΟΛΙΚΑ και την παραπομπή των παραβατών στην Κοσμητεία της Σχολής Θετικών Επιστημών &

Τεχνολογίας, σύμφωνα με τον εσωτερικό κανονισμό του ΕΑΠ.

Υποδείξεις/κανόνες για τη συγγραφή της εργασίας

3) Ο φοιτητής θα πρέπει να στείλει την εργασία με μορφή συμπιεσμένου αρχείου zip ή rar. To

όνομα του αρχείου θα είναι: SDY50_3ERG_EPITHETO_ONOMA.<rar|zip>. Να γίνει χρήση

λατινικών χαρακτήρων για την αποφυγή προβλημάτων. Το zip|rar αρχείο θα περιλαμβάνει το

doc αρχείο της εργασίας σας και το Java κώδικα (*.java) των θεμάτων 1Α και 2Α.

4) Οι απαντήσεις θα πρέπει να σύντομες, σαφείς και περιεκτικές. Δεν πρέπει να θιχθούν ή να

αναλυθούν θέματα τα οποία δεν θέτει το θέμα ή δεν ερωτούνται. Η συμμόρφωση με αυτή την

υπόδειξη αποτελεί μέρος της αξιολόγησης.

5) Η υλοποίηση των θεμάτων 1Α και 2Α θα γίνει στη γλώσσα προγραμματισμού Java, με χρήση του

εργαλείου NetBeans. Το zip|rar αρχείο που αναφέρθηκε παραπάνω (βλ. σημείο 3) θα

ενσωματώνει και δύο zip|rar αρχεία με το σύνολο των αρχείων των folders των NetBeans project

(ένα zip για το project του θέματος 1Α και ένα για το project του θέματος 2Α).

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

εκτελείται χωρίς να προκύπτουν σφάλματα λογισμικού (bugs), ακολουθεί «καλές αρχές»

προγραμματισμού (π.χ. σχολιασμό, στοίχιση, εύγλωττη ονοματοδοσία μεταβλητών,

επαναχρησιμοποίηση κώδικα, κλπ).

H εφαρμογή των παραπάνω κανόνων είναι ΥΠΟΧΡΕΩΤΙΚΗ και βαθμολογείται σύμφωνα με το

αντίστοιχο κριτήριο αξιολόγησης.

ΣΔΥ50 - ΓE3 2011-2012 -Ενδεικτικές απαντήσεις.pdf

Documents

Transcript of ΣΔΥ50 - ΓE3 2011-2012 -Ενδεικτικές απαντήσεις.pdf