Version imprimable
Salut à tous,
Je me demandais pourquoi distingue t-on 2 conteneurs différents dans un serveur d'applications Java EE ?
Ok pour le conteneur web qui contient les servlet et JSP.
Ok j'ai saisie ce qu'était le conteneur EJB mais pourquoi le différencie t-on avec le conteneur web car les 2 sont des compléments qui tourne avec Java ?
Merci pour votre éclairage. :ccool:
Il y a des multiple raisons, mais les plus importante pour moi sont :
- Pour une dissociation de code et des responsabilité (ça te force a séparer ta couche Model de tes couches Vue et Controlleur)
- Pour les performances : imagine que ton site ai un franc succès, mais ton serveur commence a ne plus être capable de répondre aux requête dans un délai assez court : après avoir nettoyer au mieux le code, tu va prendre une autre machine sur laquelle tu ne va déployer que la partie EJB, et tu va configurer le premier serveur pour se connecter aux EJB du deuxième.
Tu aura donc ici séparer les fonctionnalités en deux serveurs pour améliorer les performances. Ensuite chaque conteneur est généralement "clusterisable" ce qui te permet de déployer un ferme de 10 serveur (5 EJB, 5 JSP par exemple) tous relier entre eux et partageant leur informations. Ceci pour augmenter la sécurité (si un serveur tombe) et les performances (avec 5 serveur d'EJB tu sera capable de répondre à 5 fois plus de requêtes dans le même délai, en théorie :))
Salut OcterA
Ok. C'est puissant en effet comme principe ca permet de faire des trucs de malade. Clustering sur chaque containers du serveur d'application c'est la grande classe 8-)
Par contre d'après le schéma de ce lien :
http://coursinformatique.dyalo.com/J...erviceWeb.html
Il place les JavaBeans dans la parti conteneur WEB alors que wikipédia stipule qu'un JavaBeans = Beans = une des 3 catégories de EJB.
Alors pourquoi placer des Beans dans le conteneur WEB et non dans le conteneur EJB prévu à cette effet ?
Les JavaBeans ne sont pas forcément des EJB, explications dans les cours et tutoriels java : http://java.developpez.com/cours/
Merci Mad-Math par contre j'ai quand même du mal à comprendre la différence entre des JavaBeans et des EJB car Wikipédia mentionne que :
"Les EJB entité sont des beans ayant majoritairement pour vocation d'être persistants, c'est-à-dire pouvant être stockés sur un support physique entre deux sessions."
Et comme un Beans et un JavaBeans c'est pareil , ref, cours et tutoriels java : http://java.developpez.com/cours/
Alors qu'elle serait LA DIFFERENCE (et non la definition!) entre des EJB et des JavaBeans de facon clair, net, precise, limpide et clairvoyante :) ?
Bonjour
un bean pour faire simple c'est une classe qui respecte une certaine forme pour pouvoir être manipulable et utilisable par des frameworks, protocoles, librairies, logiciels etc
Un javabean est une classe java, qui doit répondre à certains critères.
De mémoire, et cela mérite vérification il faut:
- un constructeur public sans argument
- implémenter sérializable
- des getters et setters
Pour ma part après investiguation sur le net pour de vrai réponse détaillé et afin que cela puise servir au d'autres voici ce que j'ai pu condensé :
"La technique Enterprise JavaBeans (EJB) est une architecture de composants logiciels côté serveur pour la plateforme de développement JEE.Cette architecture propose un cadre pour créer des composants distribués (c’est-à-dire déployés sur des serveurs distants) écrit en langage de programmation Java hébergés au sein d'un serveur applicatif permettant de représenter des données (EJB dit entité), de proposer des services avec ou sans conservation d'état entre les appels (EJB dit session), ou encore d'accomplir des tâches de manière asynchrone (EJB dit message). Tous les EJB peuvent évoluer dans un contexte transactionnel.
De la version 1.0 à la version 2.1, un EJB était accompagné d'un ou plusieurs fichiers de déploiement écrit en XML qui permettait au serveur applicatif de déployer correctement l'objet au sein d'un conteneur. C'était notamment dans ces fichiers de déploiement que le développeur avait la possibilité de préciser le cadre transactionnel dans lequel l'objet allait s'exécuter. Depuis la version 3.0, le modèle EJB utilise le principe d'annotation java (meta-données) pour spécifier toute la configuration et les propriétés transactionnelles de l'objet. Le fichier de code source de l'EJB se suffit à lui-même.
C'est le serveur applicatif qui a en charge la création, la destruction, la passivation ou l'activation de ses composants en fonction des besoins. Le client via un appel RMI (ou une de ses dérivées) va rechercher un EJB par son nom logique JNDI et appeler une/des méthodes de cet objet.
Ce sont des composants inter-process (≠ JavaBeans qui sont intra-process) qui peuvent être executé sur des JVM différentes (≠JavaBeans qui a besoin d’être sur la même JVM). Ils ne possèdent pas de GUI.
La différence essentiel entre les EJB et les JavaBeans réside dans le fait que le conteneur EJB du serveur d’applications fourni des services implicite aux EJB là ou les JavaBeans ne possède aucuns service et doivent être écrit entièrement par le programmeur. Les EJB sont accessibles indirectement par le client au travers de technologie diverses alors que les JavaBeans sont un processus interne pour les developpeur. JavaBeans n’est pas fait pour des architecture n-tiers alors que les EJB oui.
"
Tu n'as pas de rôle ou d'architecture d'associé à la notion de Bean (JavaBean). Ce sont des classes qui respectent + ou - les critères énoncés par fr1man. On s'en sert pour rassembler des données dans une même classe.
Avec les EJB (Session, MDB, Entity) tu as une notion de rôle/architecture qui est associée.
Les EJB Entity sont des JavaBeans qui s'insèrent dans le cadre d'une architecture particulière et qui ont pour rôle d'être persisté (En base de données ou autre).
Exemple vite fait : tu veut créer un service de recherche de personne
Tu va créer ton EJBEntity qui correspond a ton type Personne.
Tu va créer ton EJBSession avec le service rechercherPersonne. Et au lieu d'avoir 150 paramètres à ta méthode rechercherPersonne(nom, prenom, ordreDeTri...), tu peux si tu le souhaites les regrouper dans un JavaBean CritereRecherche, que tu pourra éventuellement réutiliser dans d'autres services de recherche.
Merci mad-math pour la qualité de tes réponses.
En fait ma difficulté de compréhension résidait dans le fait que les JavaBeans et les EJB se différencie non pas par leur nature mais par leur utilisation.Citation:
"Tu n'as pas de rôle ou d'architecture d'associé à la notion de Bean (JavaBean). Ce sont des classes qui respectent + ou - les critères énoncés par fr1man. On s'en sert pour rassembler des données dans une même classe.
Avec les EJB (Session, MDB, Entity) tu as une notion de rôle/architecture qui est associée.
Les EJB Entity sont des JavaBeans qui s'insèrent dans le cadre d'une architecture particulière et qui ont pour rôle d'être persisté (En base de données ou autre)."
Ca commence effectivement à me parler un peu plus là. :DCitation:
Exemple vite fait : tu veut créer un service de recherche de personne
Tu va créer ton EJBEntity qui correspond a ton type Personne.
Tu va créer ton EJBSession avec le service rechercherPersonne. Et au lieu d'avoir 150 paramètres à ta méthode rechercherPersonne(nom, prenom, ordreDeTri...), tu peux si tu le souhaites les regrouper dans un JavaBean CritereRecherche, que tu pourra éventuellement réutiliser dans d'autres services de recherche.
Dit moi peut-on considérer que les EJB Entity ont les mêmes propriétés que les Beans standard a savoir qu'il peuvent être :
- propriété simple
- propriété indexées
- propriété liées
- propriété liées avec contraintes ?
Je n'ai pas compris ta question... :calim2:
LOL je l'a refait :lol:
Les EJB Entity sont considérés comme des Beans.
Les beans possèdent certaines propriétés.
Les JavaBeans sont des beans.
Les EJB ne sont pas réellement des JavaBeans
Alors
Peut-on considéré que les EJB entity possèdent les même propriétés que les Beans standard à savoir qu'ils peuvent être de cette forme :
- Beans à propriété simple
- Beans à propriété indexées
- Beans à propriété liées
- Beans à propriété liées avec contraintes ?
Je ne comprends pas tes histoires de propriétés simple, liées, contraintes...
Cette explication me parait suffisamment simple pour expliquer ce qu'est un bean.Citation:
Envoyé par fr1man
Si tes EJB entity ont un constructeur sans argument, sérializable et avec des propriétés accessibles via getter/setter (Et c'est généralement le cas), tu peux le considérer comme un bean.
Dans ce lien tu trouvera une explication concernant les types de propriété dans les cours et tutoriels pour apprendre java : http://java.developpez.com/cours/
Finalement tu fait la démarche inverse et tu te simplifie la vie. Et tu as bien raison."Si tes EJB entity ont un constructeur sans argument, sérializable et avec des propriétés accessibles via getter/setter tu peux le considérer comme un bean" donc les EJB auront forcement les propriétés qui vont avec :ccool:
On peut dire que on a fait tous le tour des EJB.
Merci de votre aide et à la prochaine.