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.

DTOs pourquoi ?

Les DTOs ou Data Transfert Objects sont des POJOs Java servant à véhiculer des données la plupart du temps entre la couche présentation et la couche métier au sein d'une même application. Certains les appellent Value Objects (VO), d'autres Beans en réference à la spec java beans.

DTOs pourquoi?

Ce pattern a été mis en place avec l'arrivée des spec EJB 1.x, CMP et les fameux et très controversés entity beans. En effet les entity beans étaient des EJBs à part entière avec une interface locale ou distante et n'étaient pas sérialisables! C'est là que se trouvait le problème.
Il était donc impossible de faire passer par le réseau un entity beans lors d'une communication de type remote. Il fallait pour cela copier l'entity bean dans un nouvel objet sérialisable afin de pouvoir le faire transiter : le DTO.
Par ailleurs, pour les utilisations des entity beans via leurs interfaces locales, un entity bean restait toujours connecté, s'il était transmit tel quel à la couche présentation, toute modification de l'objet par cette dernière aurait pour conséquence une mise à jour directe de la donnée en base.

Le DTO est-il vraiment mort?

La persistance est sortie des specs EJB 3.0 et 3.1, et est portée par la spec JPA. une entitée JPA est un POJO avec des métadonnés (annotations) permettant au moteur de persistance de persister le POJO en base de données. Ces POJO sont sérialisables et donc véhiculables à travers le réseau, de plus, la notion de scope de persistance permet de garantir que les POJOs retournés en sortie d'une méthode sont automatiquement déconnectés de la base par exemple.

Le pattern DTO n'est donc plus obligatoire, il reste selon moi toujours utile lorsque l'affichage d'une page nécessite un ou plusieurs sous ensembles d'entités différentes. Le DTO permet dans ce cas d'avoir un objet d’agrégation et de ne renvoyer à l'IHM qu'un seul objet contenant par contre toutes les informations nécessaires à l'affichage.