PUBLIC MARKS with tag ejb

Java opensource projects in the world

Encore un tutorial sur les EJB

Une initiation aux EJB

Tout est dans le titre

Pattern pour utiliser les EJB 2 (avec notamment l'architecture d'un système de cache avec des EJB CMP utilisant un JMS)

Site SUN de référence pour les EJB

Tutorial français expliquant les ejb 3.0

Les EJB sont particulièrement nécessaires pour des applications critiques sur de grosses architectures matérielles, là où les ressources ne sont qu’un problème secondaire et où les avantages des EJB (gestion déclarative des transactions, distribution d’objets et support de la persistence automatique) prennent tout leur sens. Dans ce type de contexte, la tolérance aux pannes et la répartition de la charge sont des élements vitaux. Le clustering est la technologie permettant de répondre à ces 2 préoccupations. Ce document va donc s’intéresser à la bonne façon de le mettre en oeuvre en tentant de mettre en avant les pièges inhérents à l’utilisation d’un cluster.

Je suis novice dans la J2EE alors excusez moi pour la remarque, mais je souhaiterais connaître la différence entre un Web Sevice et un EJB, pas du point de vu de la programmation, mais savoir ce que chacun me permet de faire quoi exactement. En effet, j'ai du mal à discerner les fonctionnalités de chacun. Je ne sais si je suis un cas isolé, mais quand je lis que c'est facile à comprendre et à programmer, excusez moi du peu, mais j'ai du mal.

Je bataille aujourd'hui pour faire adopter par mon entreprise les serveurs d'applications J2EE, et donc commencer à basculer vers une architecture distribuée. J'aurais aimé connaître votre point de vue sur les arguments que l'on m'a opposés, ainsi que quelques clarifications qui ne feront pas de mal. Normes EJB Tout d'abord, concernant l'utilisation des EJBs, je me suis vu répondre que la norme EJB n'était pas encore stabilisée et en constante évolution. Alors que la plupart des serveurs sont validés pour la norme EJB 2.0 et qu'apparaît la norme 3.0, on peut effectivement s'interroger. Les changements entre les normes sont-ils importants ? Vaut-il mieux attendre la norme 3.0 ou bien commencer avec la mature 2.0 ? Question complémentaire : qu'en est-il des protocoles utilisés pour la communication (CORBA, SOAP, RMI...) Serveurs d'application Après discussions, si serveur d'application il y a, il sera choisi entre JOnAS, JBoss ou Websphere. JOnAS et JBoss parcequ'ils sont libres, ou WAS parcequ'il est déjà utilisé dans le groupe (choix le plus probable, au passage). Sans être redondant avec le post-it "[SERVEUR J2EE] Quelles différences entre les serveurs J2EE ?", mais pour actualiser un peu (la plupart des posts datent de 2003, la situation a certainement évolué depuis), qu'en est-il aujourd'hui de ces serveurs en terme de coût de possession, de perennité de la solution (cette dernière question concerne plus JOnAS, apparemment en perte de vitesse) et.. de performances ?

Autrement dit:si je fais parti d une entreprise, que je vais chez un client, que je lui présente l'architecture J2EE, qu'il constate que la partie métier est constituées d EJB, comment lui justifierai je l usage d'un framework de mapping O/R et ke finalement l application n a pas besoin d etre conforme a l architecture J2EE a 100%?

Je suis en train de modéliser en UML une base de données qui à donc un diagramme de classe. Cette BDD contiendra les infos de mon système. Et j'ai un système que je veux développer en JAVA qui a aussi un diagramme de classe. J'ai construit le diagramme de classe du système de façon identique au diagramme de classe de ma BDD. sauf que mon diagramme de classe du sytème contient des méthodes en plus. Je voudrais savoir si mon raisonnement est le bon? Quelqu'un pourrait-il me donner son avis?

Est-il possible de faire tout un projet J2EE sans passer par les EJB ?? Quels sont les différentes autres méthodes ?? S'il y a un plus au niveau des performances ... Petite explication : je fais partie d'un projet et nous avons développé tout le code métier via des EJB ... Etant tous débutants, la prise en main des EJB fut laborieuse (problème de transactions, paramétrages ...) Nous devons faire une autre application (J2EE aussi) et je me demandais si on ne pouvait pas faire abstraction des EJB ou faire un mélange pour éviter tous les problèmes rencontrés ...

Est-il possible d'ajouter les fichier necessaire à l'exposition d'un EJB en tant que service Web et de continuer à se servir de l'EJB normalement et en même temps de s'en servir en tant que Web Service ? - La méthode pour exposer un EJB en tant que Service Web : 1) créer fichier config.xml (contenant la config du service) 2) utiliser wscompile -define config.xml 3) mettre les fichiers générés (.wsdl,webservice.xml, mapping.xml) dans le jar 4) déployer l'EJB Est ce une bonne méthode ?

Je me pose une question depuis un moment. Lorsqu'on parle de J2EE et plus précisemment de sa couche métier, on parle tout le temps d'EJB. Est-ce qu'il est pas possible d'avoir autre chose que des EJB comme par exemple un programme Java accessible par RMI ou JMS ? Si c'est le cas, est ce que des outils comme JBoss permettent de faire tourner des couches métier qui ne sont pas des EJB ? Il y a surement des topics qui parlent déjà de ça mais j'ai pas réussi à les trouver, si c'est le cas, je veux bien que vous m'envoyez les liens. J'ai bien essayé de chercher mais c'est pas évident pour une question aussi générale.

Tutorials for Hibernate, EJB 2, EJB 3 Struts, JavaServerfaces (JSF) Tomcat, JBoss, Myeclipse, Eclipse and other

La technologie EJB semble arriver à maturité et cet excellent article compare EJB 2.1 et les nouveaux EJB 3.0. Beaucoup de travail a été effectué pour aller vers plus de simplicité.

Un tour d'horizon des EJB en anglais

There's a lot we can learn from CORBA's mistakes