Intéressé par des cours d'informatique en ligne ?
Visitez mon nouveau site https://www.yesik.it !

Cet article est une reprise de l'article Les containers JEE que j'avais précédemment publié sur http://wiki.esicom-st-malo.fr

Dans le contexte Java/JEE, un container est un logiciel qui sert d'environnement d'exécution à un ou plusieurs composants Java.

Il y a container et container!

Ne confondez pas les containers JEE avec les classes containers [1]!

On parle parfois de classes containers pour parler des classes de collection - List, Array, Map, etc. - offertes par certains langages. Dans la terminologie Java, on parlera systématiquement de collection.

Dans le contexte Java/JEE, le terme de container est spécifiquement utilisé pour parler d'un logiciel dont le travail est d'offrir un environnement d'exécution à un composant Java.

Notion de container

Définition et exemples

L'architecture container-composant vise à offrir un mécanisme d'abstraction et de découplage en séparant le travail à effectuer (assuré par le composant) et le contexte d'exécution (géré par le container).

Un container JEE est un "hôte" logiciel sur lequel viennent s'enficher des composants additionnels. Un peu à la manière d'une carte mère (comme celle d'un PC) sur laquelle on peut venir mettre des modules complémentaires (cartes PCI, par ex.).

Pour donner un autre exemple, de nombreux logiciels permettent l'ajout de fonctionnalités supplémentaires au travers de plug-ins (greffons en français). C'est un autre cas d'architecture container-composant: l'application (Firefox, GIMP, etc.) est le container, et le plug-in est le composant.

Avantages

Le container sert d'interface entre le composant et le "monde extérieur", et sert donc de couche d'abstraction. En outre, cette architecture assure le découplage entre le container et le composant en permettant de remplacer l'un sans que cela n'ait d'impact sur l'autre. C'est particulièrement vrai si le container et le composant respectent tous deux des spécifications publiques: dans ce cas, le container peut "héberger" n'importe quel composant respectant cette spécification, et à l'inverse un même composant peut être hébergé sur n'importe quel container compatible. Cela permet par exemple de réduire la dépendance vis à vis d'un éditeur de logiciel particulier.

Les containers classiques Java/JEE

Les spécifications de Java/JEE définissent un certain nombre de containers standards. Nous allons en passer en revue quelques-uns:

La machine virtuelle java

Par bien des aspects, la machine virtuelle java peut être vue comme un container qui permet de charger puis d'exécuter des modules: les programmes.

L'auteur d'un programme Java n'a pas à savoir sur quelle plate-forme s'exécutera son programme. Tous les accès entre le programme et le "monde extérieur" se font au travers de services offerts par la machine virtuelle. Celle-ci assure bien un rôle d'abstraction.

De plus, un programme Java peut s'exécuter sur n'importe quelle autre machine virtuelle respectant les mêmes spécifications. Réciproquement, une machine virtuelle Java peut faire tourner n'importe quel programme Java. Il y a bien découplage entre la machine virtuelle et le programme qu'elle exécute.

Le container d'applet

Une Applet est un composant logiciel Java et qui s'exécute sur la machine cliente. Généralement "embarqué" dans une page web, l'Applet doit par conséquent être téléchargée sur la machine cliente. Un logiciel capable de servir de contexte d'exécution pour des Applets Java est appelé un container d'Applet. La plupart des navigateurs web du marché (firefox, IE, Safari, etc.) peuvent servir de container d'Applet.

Dans ce cas, le container est le navigateur Web, et le composant est l'Applet.

Container de Servlet

Une Servlet est un composant logiciel Java et qui étend les possibilités d'un serveur et étant capable de répondre à certaines requêtes. Bien que les Servlets ne soient pas spécialement liées à un type de requête particulier, elles sont le plus généralement dans des applications hébergées sur un serveur Web [2].

Dans ce cas le serveur sert de container, et la Servlet est le composant.

Remarque:

Une Servlet est assure un rôle équivalent côté serveur à celui de l'Applet côté client: étendre les possibilités du logiciel hôte.

Un exemple typique de container de Servlet est Apache Tomcat.

Serveur d'application

Un serveur d'application est un serveur, tout comme le container de Servlet, mais à la différence de celui-ci, il est capable d'accueillir tout une application d'entreprise (business application) et offre des services poussés pour assurer la sécurité, la persistance des données, ou encore la communication entre les différents composants qu'il héberge.

Note:

La différence entre serveur d'application et container de Servlet n'est pas toujours facile à appréhender au premier abord. En simplifiant (outrageusement) et pour parler par analogie, on peut dire que les Servlets sont un peu aux applications d'entreprise ce que les outils en ligne de commande sont aux logiciels dotés d'une interface graphique:

  • Avec les outils en ligne de commande, une commande est envoyée, la commande s'exécute et affiche un résultat. Tout comme la Servlet renvoie une réponse en réaction à une requête.
  • Avec les logiciels dotés d'une interface graphique, le logiciel "tourne" en attendant que l'utilisateur fasse une action. Le logiciel réagit, peut faire une action, changer d'état ou renvoyer une réponse, mais ne se termine pas pour autant.

Des exemples typiques de container d'application sont JBoss AS ou Apache Geronimo.