Stub/Skeleton pourquoi?

Comme je l'ai déjà expliqué dans un précédent post RMI est une technologie qui permet l'invocation de méthodes sur des objets distants.

Dans ce type d'invocation, les objets sont hébergés sur un serveur RMI distant. Celui-ci les rend accessible depuis l’extérieur en les publiant dans un annuaire (RMI registry).
Il est alors possible pour un client d'obtenir une référence à ces objets en faisant une recherche dans cet annuaire (lookup).

Stub pourquoi?

La référence retournée par le serveur lors d'un lookup n'est pas vraiment celle de l'objet distant.
En effet, le serveur RMI renvoie un proxy. Ce proxy va réaliser pour le client les opérations liées aux caractères distribué et éventuellement réparti (load-balancé si je peux me permetre :-)) des appels de méthodes. Ce proxy qui s’exécute coté client est appelé Stub.

Skeleton pourquoi?

Coté client, les appels de méthode se font sur l'objet stub. C'est au stub que revient la charge de réaliser l'appel sur l'objet distant coté serveur. cet objet coté serveur est le skeleton ou tie.

Dans la technologie EJB, le skeleton est un autre proxy qui implémente les services du conteneur EJB tels que la sécurité, la concurrence et la gestion des transactions.

On dit souvent en informatique qu'un diagramme clair et compréhensible vaut bien des discours.
Je suis bien d'accord :-), j'espère juste que mon diagramme sera assez clair pour tout le monde.