Examens de Rattrapage en Middleware et Construction d'Applications Répartis

Ce document présente un examen de rattrapage en Middleware et Construction d’Applications Répartis. Il évalue les connaissances théoriques et pratiques des étudiants sur les concepts fondamentaux des systèmes répartis, les annuaires LDAP, les services web, ainsi que les composants EJB et leur comparaison avec les web services.

Exercice 1 : Questions diverses

Cette première série de questions demande de définir des acronymes, d’expliquer des concepts liés aux EJB, au binding dans les systèmes répartis, puis de différencier plusieurs paires ou triplets de termes.

1. Signification des acronymes

• ADL : Architecture Description Language (Langage de Description d’Architecture)
• DIT : Directory Information Tree (Arbre d’Information d’Annuaire)
• EJB : Enterprise JavaBeans
• J2EE : Java 2 Platform, Enterprise Edition
• JNDI : Java Naming and Directory Interface
• LDIF : LDAP Data Interchange Format

2. Modélisation du type EJB entité (entity) et gestion

Le type EJB entité modélise une donnée persistante représentant un objet métier dans une base de données. Il est géré par le conteneur EJB qui assure la gestion du cycle de vie, la persistance et la synchronisation avec la base de données.

Réponse : Le type EJB entité modélise un objet métier persistant, géré par le conteneur EJB qui prend en charge la persistance et la gestion du cycle de vie.

3. Processus de Binding dans les systèmes répartis

Le binding est le processus qui permet de lier un client à un service dans un système réparti. Il prend en entrée une référence ou un nom de service et retourne une référence concrète permettant la communication avec ce service.

Entrées : Nom ou référence abstraite du service.

Sorties : Référence concrète ou stub permettant d’invoquer le service.

Réponse : Le binding consiste à associer une référence abstraite à une référence concrète de service, permettant au client d’accéder au service dans un système réparti.

4. Différences fondamentales entre paires ou triplets de termes

1. API et ADL : L’API est un ensemble d’interfaces de programmation utilisées pour développer des applications, tandis que l’ADL est un langage de description d’architecture permettant de modéliser la structure d’un système.
2. Composant et conteneur : Un composant est une unité fonctionnelle réutilisable, alors que le conteneur est l’environnement d’exécution qui gère les composants (cycle de vie, sécurité, transactions).
3. LDAP et LDIF : LDAP est un protocole d’accès aux annuaires, tandis que LDIF est un format de fichier utilisé pour représenter et échanger les données d’un annuaire LDAP.
4. JNDI et UDDI : JNDI est une API Java pour accéder aux services de nommage et d’annuaire, alors que UDDI est un référentiel pour publier et découvrir des services web.
5. SOA et SOAP : SOA (Service-Oriented Architecture) est un style d’architecture basé sur des services, tandis que SOAP est un protocole de communication utilisant XML pour échanger des messages entre services.

Exercice 2 : LDAP

Cette série de questions porte sur la compréhension d’un extrait de fichier LDIF et la structure d’un annuaire LDAP.

1. Unité d’information de base d’un annuaire LDAP et sa structure

L’unité d’information de base dans un annuaire LDAP est l’entrée (entry). Chaque entrée est identifiée de manière unique par un DN (Distinguished Name) et est composée d’attributs avec leurs valeurs. La structure est hiérarchique, formant un arbre appelé DIT (Directory Information Tree).

Réponse : L’unité de base est l’entrée LDAP, identifiée par un DN, composée d’attributs, et organisée en arbre DIT.

2. Signification des termes dn, dc, ou dans le fichier LDIF

• dn (Distinguished Name) : nom unique identifiant une entrée dans l’annuaire.
• dc (Domain Component) : composant de domaine, représentant une partie du nom de domaine (ex. yourorg, com).
• ou (Organizational Unit) : unité organisationnelle, une subdivision dans l’annuaire.

Réponse : dn identifie une entrée, dc représente un composant de domaine, ou désigne une unité organisationnelle.

3. Arbre DIT correspondant au fichier LDIF

L’arbre DIT est organisé comme suit :

dc=yourorg, dc=com
├── ou=groups
└── ou=people

Réponse : L’arbre DIT a pour racine dc=yourorg, dc=com avec deux branches : ou=groups et ou=people.

4. Interprétation des filtres LDAP

• (&(objectclass=inetOrgPerson)(!(mail=*))) : Ce filtre retourne toutes les entrées de type utilisateur (inetOrgPerson) qui n’ont pas d’adresse mail renseignée.
• (&(|(uid=jack)(uid=jill))(objectclass=posixAccount)) : Ce filtre retourne les entrées de type compte posix (posixAccount) dont l’identifiant utilisateur (uid) est soit "jack" soit "jill".

Réponse : Le premier filtre sélectionne les utilisateurs sans adresse mail, le second sélectionne les comptes posix des utilisateurs jack ou jill.

Exercice 3 : Web services

Cette partie traite des notions fondamentales sur les services web, leur description, publication et messages SOAP.

1. QCM sur les fichiers WSDL, services web et leur publication

1. Un fichier WSDL (ex. toto.wsdl) est :
   • 1. Non, ce n’est pas une classe Java.
   • 2. Oui, il est basé entièrement sur XML.
   • 3. Non, ce n’est pas une page JSP.
   • 4. Oui, c’est une interface de description de web service.
2. Un service web est :
   • 1. Non, ce n’est pas un ensemble de paquetages et classes Java.
   • 2. Non, ce n’est pas une page HTML.
   • 3. Non, ce n’est pas un fichier WSDL, mais il est décrit par un fichier WSDL.
   • 4. Non, ce n’est pas une page JSP.
3. Pour publier un service web :
   • 1. Oui, il faut résoudre ses dépendances vis-à-vis d’autres services.
   • 2. Non, on n’utilise pas le protocole DNS.
   • 3. Oui, on utilise un référentiel de services web appelé UDDI.
4. Un fichier décrivant un service web :
   • 1. Oui, il est obligatoirement un fichier XML.
   • 2. Oui, il peut se comparer à une interface Java.
   • 3. Non, il n’est pas obligatoire qu’il contienne une balise <deployment>.
   • 4. Non, il n’est pas obligatoire qu’il contienne une unique balise <service>.

2. Propriétés d’un message SOAP

• 1. Oui, un message SOAP doit être codé en XML.
• 2. Oui, il doit contenir une enveloppe SOAP (<Envelope>).
• 3. Oui, il peut avoir un en-tête (header).
• 4. Oui, il peut avoir un corps SOAP (body).

3. Analyse d’un extrait de fichier SOAP

L’extrait donné est :

1. HTTP/1.1 200 OK
2. Content-Type: text/xml; charset="utf-8"
3. Content-Length: nnnn

5. <SOAP-ENV:Envelope
6.   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
7. SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

9. <SOAP-ENV:>
10.     <m:GetLastTradePriceResponse xmlns:m="Some-URI">
11.         <Price>37.5</Price>
12.     </m:GetResponse>
13. </SOAP-ENV:Body>

1. À quoi correspond ce fichier ?

Ce fichier est une réponse SOAP envoyée par un service web, contenant le résultat d’une requête GetLastTradePrice, avec un prix retourné de 37.5.

2. Trois erreurs de syntaxe et règles non respectées :

• Ligne 7 : La balise <SOAP-ENV:Envelope> est fermée immédiatement avec "/>", ce qui empêche d’avoir un contenu à l’intérieur. La règle XML veut qu’une balise ouvrante avec contenu ait une balise fermante correspondante.
• Ligne 9 : La balise <SOAP-ENV:> est incomplète, il manque le nom complet de la balise (par exemple <SOAP-ENV:Body>). La règle XML impose un nom de balise valide.
• Ligne 12 : La balise fermante </m:GetResponse> ne correspond pas à la balise ouvrante <m:GetLastTradePriceResponse>. La règle XML impose que les balises ouvrantes et fermantes correspondent exactement.

Exercice 4 : Composants et EJB

Cette partie analyse deux interfaces Java liées aux EJB et demande leur rôle ainsi qu’une comparaison entre EJB et web services.

1. Fonction des deux codes et différence

Le premier code définit une interface PanierDeCommandeHome qui étend EJBHome. Cette interface est un "Home interface" permettant de créer une instance d’un EJB (ici, un panier de commande) via la méthode create(). Elle gère la création et la localisation de l’EJB.

Le second code définit une interface PanierDeCommande qui étend EJBObject. Cette interface représente l’EJB distant lui-même, exposant les méthodes métier telles que buyItem(Product item) et getItemList(). Elle permet d’invoquer les opérations sur l’EJB.

Différence : La première interface est une interface de création (home), la seconde est l’interface métier exposée par l’EJB.

2. Complétion du tableau comparatif

	EJB	Webservices
Vendeur(s) (1 ou plusieurs)	Sun Microsystems (historique)	W3C
Composants	EJB (Enterprise JavaBeans)	Services web (services SOAP, REST)
Langage de définition de services	Non spécifié explicitement dans l’énoncé	WSDL
Nommage	JNDI	UDDI, SOAP
Protocole	RMI/IIOP (Java Remote Method Invocation over Internet Inter-ORB Protocol)	HTTP, FTP, SMTP

Note : Certaines valeurs sont déduites des conventions usuelles car le document ne précise pas toutes les réponses explicitement.

Méthode

Ce sujet récompense une bonne maîtrise des définitions et concepts clés en middleware et systèmes répartis, ainsi qu’une capacité à analyser des extraits de code et des fichiers de configuration. Il est essentiel de répondre de manière claire, précise et structurée, en justifiant chaque réponse par des explications ou des exemples.

Les erreurs fréquentes à éviter sont :

• Confondre les rôles des interfaces EJB (home vs remote).
• Omettre de préciser les entrées et sorties dans les processus comme le binding.
• Ne pas respecter la syntaxe XML dans l’analyse des fichiers SOAP.
• Ne pas différencier correctement des termes proches comme API/ADL ou JNDI/UDDI.
• Omettre de montrer les étapes de raisonnement ou de justification.

Enfin, la rigueur dans la transcription des acronymes, des noms et des protocoles est primordiale pour éviter toute confusion.