EXAMEN de Rattrapage

Ce document est un examen de rattrapage en Systèmes et Applications Répartis, visant à évaluer les compétences des étudiants en programmation distribuée avec Java-RMI et en messagerie orientée message (MOM) avec JMS.

D'après le document EXAMEN de Rattrapage

Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Document source

EXAMEN de Rattrapage

Systèmes et Applications Répartis · PDF · 4 pages · 2014

Afficher l'aperçu du document

Consulter le document original →

Ce document est un examen de rattrapage en Systèmes et Applications Répartis, visant à évaluer les compétences des étudiants en programmation distribuée avec Java-RMI et en messagerie orientée message (MOM) avec JMS. Les questions testent la compréhension des mécanismes d’exécution d’objets distribués, la manipulation d’interfaces distantes, ainsi que la connaissance de l’architecture et du code de base d’un système de messagerie JMS.

Exercice 1 : Java-RMI (7 points — 1+2+2)

Les deux questions suivantes sont indépendantes.

1) Analyse d’un schéma d’exécution d’un objet distribué

On demande d’indiquer ce que signifie chaque lettre sur le schéma et de les ordonner dans le temps.

Solution :

Sans le schéma fourni, on ne peut pas nommer précisément chaque lettre. Cependant, dans un fonctionnement classique d’un objet distribué Java-RMI, les étapes sont généralement :

  • Le client invoque une méthode sur un stub local (proxy).
  • Le stub sérialise les paramètres et envoie la requête au serveur via le réseau.
  • Le serveur reçoit la requête, désérialise les paramètres, et appelle la méthode sur l’objet distant réel.
  • Le résultat est renvoyé au client par le même chemin inverse.
  • Le stub désérialise la réponse et la retourne au client.

L’ordre temporel est donc :

  1. Invocation client sur stub
  2. Envoi de la requête au serveur
  3. Exécution côté serveur
  4. Retour du résultat
  5. Réception et désérialisation côté client

Réponse : Chaque lettre correspond à une étape du cycle d’appel distant, et elles doivent être ordonnées selon ce déroulement temporel.

2) Programme Java avec objet local et objet distant

On considère la classe suivante (non fournie ici) et un programme qui affiche deux valeurs. On répond aux questions suivantes :

a) Quel est l’affichage produit par le programme ?

Le programme affiche successivement les valeurs 2 puis 3.

Explication : L’objet Entier y est initialisé avec la valeur 2. La méthode inc(y) incrémente y.n de 1, ce qui modifie y localement. L’affichage avant et après l’appel montre donc 2 puis 3.

Réponse : L’affichage est : 2 puis 3.

b) Écrire l’équivalent du main utilisant un objet distant RLocal

On donne l’interface distante RLocal avec une méthode inc prenant un Entier en paramètre et ne renvoyant rien. On doit écrire le main qui utilise un stub récupéré via rmiregistry.

public static void main(String[] args) {
    try {
        // Récupération d'un stub sur l'objet RLocal.
        RLocal l = (RLocal) Naming.lookup("//localhost/ILocal");
        Entier y = new Entier(2);
        System.out.println(y.n);
        l.inc(y);
        System.out.println(y.n);
    } catch (Exception exc) {
        // gestion des exceptions
    }
}

Réponse : Le main ci-dessus est l’équivalent demandé avec l’utilisation de l’objet distant.

c) Peut-on déterminer complètement l’affichage du main précédent sans connaître la programmation de l’objet distant ?

Analyse : L’objet Entier est local au client et est passé en paramètre à la méthode inc de l’interface distante RLocal. En Java-RMI, les objets non distants sont passés par valeur (sérialisés). Ainsi, le serveur reçoit une copie de l’objet Entier, incrémente sa valeur dans cette copie, mais cette modification ne se répercute pas sur l’objet local du client.

Par conséquent, la valeur de y.n côté client ne change pas après l’appel distant.

Réponse : Oui, on peut déterminer l’affichage : il sera 2 puis 2, car l’objet y côté client n’est pas modifié par l’incrémentation côté serveur.

Exercice 2 : MOM-JMS (5 points — 1,25+1,25+2,5)

1) Rappel de l’architecture d’un producteur-consommateur JMS

On demande de rappeler l’architecture d’un système JMS avec un producteur et un consommateur.

Solution :

Dans JMS (Java Message Service), l’architecture producteur-consommateur comprend :

  • Un producteur de messages (Message Producer) qui crée et envoie des messages.
  • Une connexion (Connection) établie avec le serveur de messages.
  • Une session (Session) qui gère le contexte de communication et la transaction.
  • Un consommateur de messages (Message Consumer) qui reçoit les messages.
  • Un broker ou serveur de messages qui assure la transmission entre producteurs et consommateurs.

Réponse : L’architecture comprend un producteur, une connexion, une session, un consommateur, et un serveur de messages assurant la communication.

2) Compléter la figure suivante

La figure montre les éléments :

  • Message Producer
  • Connection
  • Session
  • Message
  • Message Consumer

La figure illustre la chaîne de production et consommation de messages via la connexion et la session JMS.

Réponse : La figure complète montre que le producteur crée un message, la session gère la communication via la connexion, et le consommateur reçoit le message.

3) Correspondance entre commentaires et instructions Java JMS

On doit associer chaque commentaire à l’instruction correspondante parmi celles proposées :

Commentaire Instruction
a) Créer une session JMS iii) TopicSession pubSession = connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
b) Récupérer une fabrique de connexion JMS iv) TopicConnectionFactory conFactory = (TopicConnectionFactory)jndi.lookup("JmsTopicConnectionFactory");
c) Récupérer le contexte de nommage ii) Properties env = new Properties(); InitialContext jndi = new InitialContext(env);
d) Créer une connexion i) TopicConnection connection = conFactory.createTopicConnection(username,password);
e) Créer un producteur de messages vi) TopicPublisher publisher = pubSession.createPublisher(chatTopic);
f) Récupérer un sujet (topic) v) Topic chatTopic = (Topic)jndi.lookup(topicName);

Réponse : a)iii) ; b)iv) ; c)ii) ; d)i) ; e)vi) ; f)v)

4) Séquence d’une portion du code du producteur de messages

On demande d’ordonner la séquence d’instructions pour le producteur en fonction des correspondances précédentes.

La séquence est :

  1. c) Récupérer le contexte de nommage
  2. b) Récupérer une fabrique de connexion JMS
  3. d) Créer une connexion
  4. a) Créer une session JMS
  5. e) Créer un producteur de messages
  6. f) Récupérer un sujet (topic)

Réponse : La séquence correcte est : c) ; b) ; d) ; a) ; e) ; f)

Méthode

Ce sujet récompense une bonne compréhension des mécanismes fondamentaux de la programmation distribuée et de la messagerie JMS. Il est essentiel de :

  • Respecter la terminologie et les conventions données dans l’énoncé, notamment sur le passage par valeur des objets dans Java-RMI.
  • Montrer clairement les étapes du raisonnement, notamment pour expliquer pourquoi un objet local ne change pas après un appel distant.
  • Associer précisément chaque instruction à sa fonction dans l’architecture JMS, en respectant l’ordre logique de création du contexte, de la connexion, de la session, puis du producteur.
  • Ne pas inventer d’informations non fournies, et signaler les impossibilités quand des données manquent (comme le schéma du premier exercice).
  • Présenter les réponses avec des exemples de code ou des explications détaillées pour faciliter la compréhension.

Les erreurs fréquentes à éviter sont :

  • Confondre passage par valeur et passage par référence en Java-RMI.
  • Omettre des étapes dans la séquence JMS ou mélanger les rôles des objets.
  • Ne pas justifier les réponses ou donner des réponses sans raisonnement.

Partager

Commentaires

Aucun commentaire pour le moment. Posez la première question.

Les commentaires sont relus avant publication. Votre e-mail n'est jamais affiché.

← Toutes les révisions