Avant tout, J2EE peut être grossièrement résumé en disant que c'est une spécification très détaillée de serveur d'application (fait pour fonctionner en java.)
Qui dit "serveur d'application" dit "logiciel serveur" : on ne "voit" pas tourner J2EE (au plus il affichera de temps en temps ce qui se passe sur le terminal texte depuis lequel il a été lancé.) Mais globalement on ne voit pas plus sa présence qu'on ne voit celle de sshd ou ftpd. C'est pas bien grave vu qu'en général on est censé faire tourner ça sur un monstre de calcul octoprocesseur branché sur le réseau d'entreprise, et auquel c'est tout juste si on a laissé un clavier et un écran en mode texte (c'est pas que c'est nécessaire, mais c'est l'utilisation courante, quoi...)
Par conséquent, à quoi ça ressemble... À tous les programmes qui utilisent les services du serveur, tout simplement. Dans la mesure où on peut s'en servir comme serveur d'application web (voire même serveur web aussi,) le fameux programme en question peut être un simple navigateur. Mais dans la mesure où le principe de J2EE c'est d'utiliser des EJB, et que le principe des EJB, c'est de les filer aux programmes qui en ont besoin pour qu'ils discutent directement avec le serveur pour faire tel ou tel traitement de l'information, ben... N'importe quel genre de programme peut interagir (facilement, je veux dire, que ça prend pas des plombes à programmer,) avec un serveur d'application J2EE. Et donc n'importe quel genre de programme peut être "la partie visible" d'un serveur J2EE.
A quoi sert un serveur J2EE (ou un serveur d'application en général ) ? A tout les traitements informatiques dont on peut avoir besoin dans sa boîte. C'est une sorte d'interface entre systèmes de bases de données, bases de données tout court, serveurs webs, traitements et calculs spécifiques à l'entreprise, logiciels des utilisateurs finaux (genre pas besoin de s'assurer que le programme de conversion AutoCad vers PDF marche sur toutes les machines de la boîte : on le met sur le serveur d'application et pour s'en servir les utilisateurs finaux se servent d'un petit client tout léger et bien intégré à leur environnement.)
C'est plus clair ? (Je teste mes capacités de pédagogue, ici, hein, pas d'ingénieur...)
[^] # Re: Pourquoi choisir JOnAS plutôt que JBoss ?
Posté par Miair Patreau . En réponse à la dépêche Pourquoi choisir JOnAS plutôt que JBoss ?. Évalué à 1.
Qui dit "serveur d'application" dit "logiciel serveur" : on ne "voit" pas tourner J2EE (au plus il affichera de temps en temps ce qui se passe sur le terminal texte depuis lequel il a été lancé.) Mais globalement on ne voit pas plus sa présence qu'on ne voit celle de sshd ou ftpd. C'est pas bien grave vu qu'en général on est censé faire tourner ça sur un monstre de calcul octoprocesseur branché sur le réseau d'entreprise, et auquel c'est tout juste si on a laissé un clavier et un écran en mode texte (c'est pas que c'est nécessaire, mais c'est l'utilisation courante, quoi...)
Par conséquent, à quoi ça ressemble... À tous les programmes qui utilisent les services du serveur, tout simplement. Dans la mesure où on peut s'en servir comme serveur d'application web (voire même serveur web aussi,) le fameux programme en question peut être un simple navigateur. Mais dans la mesure où le principe de J2EE c'est d'utiliser des EJB, et que le principe des EJB, c'est de les filer aux programmes qui en ont besoin pour qu'ils discutent directement avec le serveur pour faire tel ou tel traitement de l'information, ben... N'importe quel genre de programme peut interagir (facilement, je veux dire, que ça prend pas des plombes à programmer,) avec un serveur d'application J2EE. Et donc n'importe quel genre de programme peut être "la partie visible" d'un serveur J2EE.
A quoi sert un serveur J2EE (ou un serveur d'application en général ) ? A tout les traitements informatiques dont on peut avoir besoin dans sa boîte. C'est une sorte d'interface entre systèmes de bases de données, bases de données tout court, serveurs webs, traitements et calculs spécifiques à l'entreprise, logiciels des utilisateurs finaux (genre pas besoin de s'assurer que le programme de conversion AutoCad vers PDF marche sur toutes les machines de la boîte : on le met sur le serveur d'application et pour s'en servir les utilisateurs finaux se servent d'un petit client tout léger et bien intégré à leur environnement.)
C'est plus clair ? (Je teste mes capacités de pédagogue, ici, hein, pas d'ingénieur...)