- Changement dans la configuration: apparition de la variable JONAS_BASE ( si celle ci est présente, les fichiers sont recherchés dans ce repertoire, sinon à partir de la variable JONAS_ROOT).
- Nouvelle version de JORAM pour le service JMS.
- Les packages JOnAS-TOMCAT et JOnAS-JETTY sont maintenant preconfigurés pour fonctionner directement.
- Integration d'Axis dans les packages JOnAS-TOMCAT et JOnAS-JETTY. Elle permet de rendre les EJB disponibles en tant que webservice.
- Nouvelle fonction dans Jadmin: c'est maitenant possible de sauvegarder les modification de configuration via celui-ci.
- Xerces 2.4.0 est intégré a JOnAS.
Les nouveaux outils:
- Support par xdoclet 1.3 de JOnAS, kit pour créer ses propres adaptateurs pour la persistence CMP2 et enfin une première version d'un plugin Eclipse.
Aller plus loin
- JOnAS (1 clic)
- Telechargement de JOnAS (2 clics)
- Historique des versions (3 clics)
- JOnAS Objectwebforge (1 clic)
# Re: JOnAS 3.1 est sorti, et la 3.0 est dans la Mdk 9.1
Posté par Benoît Bailleux (Mastodon) . Évalué à 8.
# Re: JOnAS 3.1 est sortie
Posté par Stéphane Bourzeix . Évalué à 4.
Je m'en vais tester ce plugin de suite ....
[^] # Re: JOnAS 3.1 est sortie
Posté par Olivier MARTIN . Évalué à 2.
J'en profite pour informer le sgens que la version 3.2.0 de Jboss vient d'être releasé. (encore une fois disponible sur source forge)
# Re: JOnAS 3.1 est sortie
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
# Re: JOnAS 3.1 est sortie
Posté par redguts . Évalué à 3.
# Avantages ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 2.
[^] # Re: Avantages ?
Posté par Nelis (site web personnel) . Évalué à 6.
Jonas ou JBoss font serveurs JMS, EJB, JNDI, ils gèrent la sécurité, les transactions, ...
Bref ils te fournissent tous les services nécessaires au bon fonctionnement d'une application J2EE.
[^] # Re: Avantages ?
Posté par Rage . Évalué à 4.
Aujourd'hui il manque encore une interface rapide avec des assistants fonctionnels et libres et une implémentation réèllement complète.
Pour moi tout ce barouf autour de J2EE est commercial, un serveur d'application libre doit être honnête et avouer qu'on en est encore aux balbutiements, et si la concurrence avec les technologies émergentes type .NET et la cible visée (les entreprises, donc les DI, donc pas toujours les plus à même de juger un source) pousse les sociétés commerciales à affirmer que J2EE c'est hype-cool-groovy-facile-qui-marche-tout-seul les projets comme Jonass et JBoss devraient eux rester plus humbles dans leur communication. Mais pour JBoss le lien libre/commercial est peu-être déjà trop étroit...
[^] # Re: Avantages ?
Posté par Nelis (site web personnel) . Évalué à 1.
Euh ... faudrait pas exagérer non plus ... Des tonnes d'applications J2EE tournent en prod, et tournent très bien. Je ne vois pas en quoi on en est aux balbutiements. Bien sûr les specs évoluent avec les versions, mais c'est normal, la plateforme évolue et devient de plus en plus mature.
J2EE ne va pas te faire un super wizard qui te créera une application mega géniale et rapide en trois clics. Il faut une bonne analyse et de l'expertise pour écrire une application J2EE, comme pour n'importe quelle application. Mais ça marche, et ça marche bien.
[^] # Re: Avantages ?
Posté par Rage . Évalué à 5.
Disons plutôt que ce n'est pas mature.
Une technologie non mature peut tourner en exploitation et être stable même, pourquoi pas.
Je suis très satisfait de l'ampleur de la réflection de génie logiciel de J2EE, le but est noble et les directions choisie semblent bonnes, mais pour moi c'est un peu comme de l'UML face à eXtreme Programming, on est encore très loin du pragmatisme dans J2EE. De nombreux principes d'implémentations ne sont pas automatisés alors qu'ils pourraient l'être.
Le but au final est quand même de générer vite des applications performantes, le but du programmeur est de savoir faire les bons choix dans la structure de l'ensemble, utilisation de messages, de processus synchrones ou pas, de tel ou tel type de transactions, etc.
Ce n'est pas CP4E (Computer Programming For Everybody) mais au moins ce serait bien que ce soit PONT (Program Only New Things).
<doux-rêve>
On devrait pouvoir piloter un choix d'architecture et puis passer ensuite directement au codage du coeur, du noyau métier.
Mais aujourd'hui faire afficher un Hello World stocké dans une BDD sur un écran distant en passant par une appli J2EE (même si le but est de gérer un processus plus complexe) demande un temps fou et les IDE n'indiquent pas la schématisation théorique du processus.
</doux-rêve>
On est encore très loin de ce qui devrait être une version 1.0. Un machin clair, utilisable par tous ceux qui ont étudié la théorie J2EE da façon simple et rapide.
Heureusement qu'il est possible de faire tourner des appli en J2EE, ce que je réclame c'est plus d'humilité, se retrouver devant un projet J2EE aujourd'hui c'est se taper un paquet de copier/coller, et de test-si-fait-bien-comme-la-théorie.
Bref je pense que ces applis commerciales et libres ne sont pas aussi humbles que des applis libres non-commerciales (type GNUe) et c'est sans doute un risque fort pour les logiciels libres aujourd'hui.
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 3.
- de simplifier radicalement la gestion des transactions (avec prise de décision au déploiement)
- de simplifier radicalement les problèmes de (re)démarrage d'un service avec le management automatique des instances de Bean
- de simplifier radicalement les problèmes de persistance avec les entity beans
- etc.
Une des idées principales est de déplacer certaines décisions depuis le code vers des descripteurs de déploiement ce qui clarifie grandement le code.
[^] # Re: Avantages ?
Posté par Rage . Évalué à 2.
Je suis en partie d'accord, au passage même si je n'étais pas d'accord je n'irai pas voter -, un score négatif pour un avis divergent je trouve ça un peu c**, mon avis était-il à ce point indigne de figurer dans le débat?
Mais bon, si le but de J2EE est effectivement de rajouter un niveau d'abstraction sur le middleware c'est pour ne pas réinventer la roue à chaque conception ou à chaque redéploiement. Ce qui en un sens est une façon de dévelloper plus vite et plus efficacement.
Et si pour être plus efficace il faut se taper des interfaces affreuses, complexes, lentes et ne représentant que très mal l'abstraction de la théorie J2EE alors c'est dommage.
Pour moi il est évident que toute cette réflexion ne se limite pas un point (la portabilité), elle touche aussi au RAD, elle ne touche sans doute pas assez à XP, elle concerne aussi les performances, la réutilisabilité, etc.
Donc voilà, score négatif pour celui qui ose dire que J2EE est immature, le gars qui aurait que la première version de Fortran était immature a sûrement été linché!
[^] # Re: Avantages ?
Posté par anonyme512 . Évalué à 2.
http://www.objectweb.org/conferences/2002/J2EE_Performance.pdf(...)
En effet, ce que tu programmes dans un serveur J2EE sont des "Beans", dont il existe plusieurs sortes (le SessionBean, qui doit contenir la logique business, l'EntityBean qui doit contenir la logique d'accès aux données, et enfin la Servlet, qui contient la logique de présentation. je suis très schématique là).
Le hic, c'est que, pour être modulaire, ces Beans causent entre eux via RMI (en général), et les perfs en prennent un sale coup. Dans la spec EJB 2.0, Sun a rajouté la possibilité de faire un appel local (en passant donc juste par la mémoire) entre SessionBeans et EntityBeans (ce qui revient à admettre de facto que le pattern Session Facade est la plus réaliste implémentation J2EE), mais le résultat est toujours pas fabuleux. Quand aux implémentations BMP et CMP, elle s'avèrent être à peu près aussi mauvaises l'une que l'autre.
Bref, J2EE permet d'énormément gagner en modularité (ben oui on peut recombiner facilement les Beans entre eux, ce qui est très intéressant), mais il faut bien avoir conscience que c'est au prix de performances amoindries.
Sinon, toujours du même consortium ObjectWeb, il y a Enhydra, tout aussi OpenSource, qui est un serveur d'application Java non-J2EE, qui est moins modulaire, mais qui torche niveau perfs.
[^] # Re: Avantages ?
Posté par redguts . Évalué à 3.
C'est comme le langage : celui qui torche tout c'est l'assembleur, mais quand tu as un programme important, tu préfères un langage de haut niveau!
[^] # Re: Avantages ?
Posté par Nelis (site web personnel) . Évalué à 2.
Effectivement, les EJB sont gourmands en ressources, et il ne faut pas les utiliser pour de petits projets. Mais ils font gagner pas mal de temps, ont des performances très satisfaisantes et surtout ont une très bonne scalability lorsqu'ils sont utilisés au bon endroit.
Et puis, J2EE ce n'est pas Servlet/JSP + EJB. C'est bien plus que ça.
Il y a JMS (Messages queues), JNDI (Naming service), sécurité, Web services, JDBC (datasources), ...
Pour l'accès aux bases de données, tu as typiquement le choix entre les EJB, JDBC dans les servlets, ou (dans un futur proche) JDO (Java Data Object, un nouveau moyen de gérer la persitence, plus léger que les EJB).
Personnellement dans un projet de taille moyenne sur lequel je travail, j'utilise des servlets pour le Controller, des query appelés par JDBC comme Model et les JSP comme View. (Je déconseille l'utilisation de servlet comme view, parce que l'HTML hardcodé ça pue quand même ...)
[^] # Re: Avantages ?
Posté par anonyme512 . Évalué à 2.
Par ailleurs, JNDI, Web services, JDBC, tout ça n'est pas le propre de J2EE. A peu près tous les serveurs d'applications Java utilisent ces couches (ya pas vraiment le choix, sauf peut-être pour la couche LDAP, qui est grave pourrie dans JNDI, alors que Novell en a une belle qu'ils ont filé à OpenLDAP), et même si tu fais du développement servlet-only dans Tomcat, tu vas les utiliser (d'ailleurs, c'est ce que tu fais, non ? ;-)). Ce qui fait le coeur de J2EE c'est bel et bien les EJB (mais je suis d'accord avec toi que ce n'est pas le seul élément).
De plus, les EJB et J2EE ont un autre avantage que je n'ai pas cité, c'est que leur aspect modulaire fait qu'en réalité, pour les programmer, on utilise en général largement de la génération de code (à vrai dire, on a pas vraiment le choix, cf. les indications de complexité du code dans le test).
Enfin, je pense que tu devrais vraiment regarder du coté d'Enhydra pour ton projet. En gros Enhydra offre également un support de type MVC, mais en bien propre: il y a DODS, qui fait de l'encapsulation objet JDBC pour les accès base (par génération de code). Tu utilises ensuite ces objets de données (DO) pour implémenter ta couche business, et pour finir tu construis des objets de présentation (PO) qui utilisent les objets business, ainsi que des objets DOM pour générer les pages web. Ces objets DOM sont générés par XMLC, qui "compile" des pages HTML (ou XML, ou WML, ou XHTML) de template en DOM Java, en fournissant via de la génération de code les raccourcis idoine pour y accéder facilement. Le tout est lancé dans ce qu'ils appelent une SuperServlet.
En conclusion, tout dépend de la taille du projet et de tes besoins. Il va de soi que plus le projet est gros, plus la modularité est un atout. De même, si le projet doit être inséré dans un environnement déjà assez complexe et J2EE et qu'on veut de l'interopérabilité à mort, ben il faut faire du J2EE. Par contre sur un petit ou moyen projet mieux vaut privilégier les perfs par rapport à ce qu'apporterait J2EE, et si on veut de l'interopérabilité, il suffit de développer un backend XML.
[^] # Re: Avantages ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
C'est un tutorial ou j'explique comment développer des EJBS et en quoi, ca va changer ta vite et ta facon de concevoir l'informatique !
a+
Stéphane
http://about.me/straumat
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 1.
Absolument pas. Il n'y a pas de coeur J2EE, l'intérêt c'est justement l'ensemble, à savoir les servlets, les JSP, JNDI, etc. Bien entendu, le J2SE est toujours une version en avance par rapport au J2EE donc si tu compares J2SE 1.4 à J2EE 1.3, il n'y a plus grand chose de spécifique à J2EE (excepté Servlet/JSP/EJB). Par contre, tout l'aspect web services est spécifique à J2EE 1.4. Comme les specs java sont modulaires, tu peux bien sûr implémenter seulement des morceaux, il n'en reste pas moins que réduire J2EE au morceau le plus compliqué (les EJB), c'est n'importe quoi.
[^] # Re: Avantages ?
Posté par anonyme512 . Évalué à 1.
Bien sur, le reste (JNDI, etc.) peut etre rajouté après, c pas la question... D'ailleurs tout Java est modulaire, tu peux rajouter des composants autant que tu veux à J2SE aussi.
Donc je réitère, le système Servlet/EJB est le coeur de J2EE. C'est d'ailleurs tellement vrai que le plus gros de la bataille dans les serveurs d'application J2EE est là: avoir le conteneur d'EJB le plus optimisé (via des appels locaux notamment, ou via du RMI amélioré, comme le fait Jonas avec Jeremie). Enfin... je les connais pas tous, donc il y en a peut etre qui réimplémentent à leur sauce des choses comme cette daube de JNDI, mais ce qui est sur c'est que personne ne se bat là-dessus (hélas).
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 2.
Ouai, sauf que tu disais EJB. D'ailleurs ton premier post faisait déjà la confusion entre deux choses qui n'ont pas beaucoup en commun, les Servlets (et les JSP) d'un côté, les EJB de l'autre. D'autre part, entre le J2SE 1.4 et J2EE 1.4 (version beta) tu auras comme différence (en plus des Servlet/JSP/EJB) toute la partie web services (SOAP etc.), la partie messaging (JMS qui est elle aussi un très gros morceau), JMX, JTA, etc.
Bref, tu peux t'en tirer en amalgamant Servlet/JSP/EJB dans un même sac et là, je suis d'accord, c'est le coeur de la technologie, cependant ça reste tandencieux. De plus, vue la mode actuelle des web services, tu te retrouves maintenant avec un gros morceau de plus dans J2EE.
Que du point de vue marketing, les serveurs d'applications se battent sur les EJB est logique, c'est la partie la plus visible et la plus concurrentielle. De la à ne voir qu'elle, il y a un grand pas.
[^] # Re: Avantages ?
Posté par Nelis (site web personnel) . Évalué à 1.
Effectivement, JMS fait tout autant partie de J2EE que EJB ou Servlet/JSP. Et JMS est loin d'être quelque chose de petit ou de négligeable. Idem pour JMX, JTA & co
Sinon, pour Anonyme, sur quoi te bases-tu pour dire que JNDI est de la daube ? Moi je trouve ça bien fichu et hyper pratique.
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Avantages ?
Posté par Guillaume Carre . Évalué à 1.
Effectivement, les EJB sont gourmands en ressources, et il ne faut pas les utiliser pour de petits projets. Mais ils font gagner pas mal de temps, ont des performances très satisfaisantes et surtout ont une très bonne scalability lorsqu'ils sont utilisés au bon endroit.
Pour les performances, si on parle des EJB Entity Beans, elles sont loin d'être satisfaisantes!
Depuis les EJB 2 les choses se sont arrangées (appels locaux entre les Session et les Entity, avant il fallait passer par RMI), mais tu as toujours au moins 3 classes par EJB, voir 4 ou 5, et l'empreinte mémoire d'un objet métier modélisé par un Entity Bean est énorme! Sans parler des requêtes SQL générées dans les CMP, où on n'a pas de contrôle, on est obligé de coder les méthodes find en SQL...
On peut aussi parler de l'absence de notion d'héritage avec les Entity Beans...
Pour l'accès aux bases de données, tu as typiquement le choix entre les EJB, JDBC dans les servlets, ou (dans un futur proche) JDO (Java Data Object, un nouveau moyen de gérer la persitence, plus léger que les EJB).
JDO (Java Data Objects) n'est pas directement comparable aux Entity Beans CMP, puique suivant l'implémentation utilisée, on peut gérer la persistance dans une base de données relationnelle, mais aussi dans une base de données objet, dans du XML, etc etc (la spec JDO n'est pas restrictive)
pour plus d'infos, www.libelis.com
Personnellement dans un projet de taille moyenne sur lequel je travail, j'utilise des servlets pour le Controller, des query appelés par JDBC comme Model et les JSP comme View. (Je déconseille l'utilisation de servlet comme view, parce que l'HTML hardcodé ça pue quand même ...)
Utiliser un framework de type Struts va beaucoup aider dans ce cas là... http://jakarta.apache.org/struts(...)
[^] # Re: Avantages ?
Posté par Nelis (site web personnel) . Évalué à 1.
Je ne trouve pas ça dérangeant d'avoir plusieurs classes par EJB, tu as les diverses interfaces implémentées (EJBHome, ...) et tu as l'implémentation proprement dite (qui est générée automatiquement). Effectivement ça bouffe de la mémoire, mais en contre partie ça rend pas mal de service.
Par contre je ne comprends pas pourquoi tu te plains que le SQL soit généré tout seul dans les CMP (tu peux utiliser des BMP si tu veux), puis juste après tu te plains de devoir utiliser du SQL pour les finders ...
Pour JDO je n'ai pas dit que c'était == aux EJB mais que c'était une autre manière de gérer la persistance.
Pour Struts merci, je connais ;-) C'est un très bon framework que j'ai déjà utilisé dans plusieurs projets.
[^] # Re: Avantages ?
Posté par Guillaume Carre . Évalué à 2.
Tu sais, comme le dis Boubou, avant les EJB 2.0 les serveurs d'applications faisait déjà souvent des appels locaux en interne, ce qu'a fait Sun c'est inclure cette possibilité dans la spec. Donc niveau perf, c'était déjà +- idem.
ha... je demande confirmation, tu as un lien?
Je ne trouve pas ça dérangeant d'avoir plusieurs classes par EJB, tu as les diverses interfaces implémentées (EJBHome, ...) et tu as l'implémentation proprement dite (qui est générée automatiquement). Effectivement ça bouffe de la mémoire, mais en contre partie ça rend pas mal de service.
ha... moi avoir 4 ou 5 classes par objet métier, quand tu as un modèle de 300 objets, je trouve ca un peu génant... quand tu vois que tu n'en as qu'une à coder avec JDO...
En plus les services rendus par le conteneur d'EJB, tu les as en utilisant des Session Beans, suffit de placer JDO (ou des DAO) derrière ces Session Beans, et tu rends ton modèle objet beaucoup plus simple, et tu diminues l'empreinte mémoire de ton application
De toute façon, en pratique, tout le monde fait du Session Bean + JDBC, aprés s'être cassé les dents sur les Entity Beans...
Par contre je ne comprends pas pourquoi tu te plains que le SQL soit généré tout seul dans les CMP (tu peux utiliser des BMP si tu veux), puis juste après tu te plains de devoir utiliser du SQL pour les finders ...
je ne me plains pas que le SQL soit généré tout seul, je me plains que le SQL généré tout seul soit pourri... et qu'en conséquence on soit obligé de tout coder dans les finders... où est alors l'utilité des CMP je vous le demande... (par rapport aux BMP)
enfin on va pas refaire le gueguerre JDO vs CMP de serverside hein ;-)
http://www.theserverside.com/discussion/thread.jsp?thread_id=771&am(...)
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 1.
Pour les perfs voir les benchs déjà cités qui montrent que l'introduction de l'interface local ne change pas grand chose? D'autre part, Fleury a déjà dit dans plusieurs papiers et docs que JBoss optimise les appels locaux.
ha... moi avoir 4 ou 5 classes par objet métier, quand tu as un modèle de 300 objets, je trouve ca un peu génant... quand tu vois que tu n'en as qu'une à coder avec JDO...
Argh ! Utilise donc XDoclet, malheureux ! Une seule classe à coder par Bean. Faux vraiment être un troll pour coder ça à la main.
De toute façon, en pratique, tout le monde fait du Session Bean + JDBC, aprés s'être cassé les dents sur les Entity Beans...
Fleury dit exactement le contraire, et j'ai plutôt tendance à le croire lui, désolé.
je ne me plains pas que le SQL soit généré tout seul, je me plains que le SQL généré tout seul soit pourri... et qu'en conséquence on soit obligé de tout coder dans les finders...
Un exemple serait le bienvenu...
[^] # Re: Avantages ?
Posté par Guillaume Carre . Évalué à 1.
Pour les perfs voir les benchs déjà cités qui montrent que l'introduction de l'interface local ne change pas grand chose? D'autre part, Fleury a déjà dit dans plusieurs papiers et docs que JBoss optimise les appels locaux.
ha JBoss le prend peut etre en compte, effectivement. Par contre je rappelle que JBoss n'a pas été certififié compatible J2EE 1.3.
Argh ! Utilise donc XDoclet, malheureux ! Une seule classe à coder par Bean. Faux vraiment être un troll pour coder ça à la main.
c'est clair... WSAD le fait aussi
mais bon justement, on a été obligé de fabriquer de nouveaux outils pour résoudre les problèmes soulevés plus haut... C'est comme le pattern Session Facade, on l'utilise à cause des problèmes de granularité des Entity Beans (en appel distant, on fait des getAttribute, on devrait pouvoir faire des getObject)...
Fleury dit exactement le contraire, et j'ai plutôt tendance à le croire lui, désolé.
ha... ben Fleury il est pas forcément impartial hein... ;-) Si j'étais toi je m'intéresserais aussi aux retours d'expérience des utilisateurs, et pas qu'aux dires des éditeurs... :-)
Un exemple serait le bienvenu...
faudrait que je retrouve ca, j'ai lu un papier quelque part là dessus, j'ai pas expérimenté moi même là dessus... je me base sur des retours d'exp désolé...
[^] # Re: Avantages ?
Posté par encre (site web personnel) . Évalué à 1.
euh essaye toi-meme avec un exemple simple, et tu verras la difference de vitesse.
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 1.
Pourrais-tu développer, ça ne me semble pas très clair, ton truc. Sur le client, tu as le Home et le Remote, sur le serveur le Bean lui-même plus de l'enrobage propre au serveur.
Sans parler des requêtes SQL générées dans les CMP, où on n'a pas de contrôle, on est obligé de coder les méthodes find en SQL...
Ba oui, c'est le but de CMP. Si tu veux du contrôle tu fais tu BMP. Sinon, les find sont codés en EJBQL, pas en SQL.
[^] # Re: Avantages ?
Posté par Guillaume Carre . Évalué à 1.
Pourrais-tu développer, ça ne me semble pas très clair, ton truc. Sur le client, tu as le Home et le Remote, sur le serveur le Bean lui-même plus de l'enrobage propre au serveur.
par exemple, tu as besoin dans certains cas de coder une classe ObjectKey pour gérer la clé primaire... ca fait 4...
Ba oui, c'est le but de CMP. Si tu veux du contrôle tu fais tu BMP. Sinon, les find sont codés en EJBQL, pas en SQL.
oui bien sur, si le code SQL généré me convenait ca serait trés bien, mais je pense que ce n'est pas assez optimisé... il me semble que le code généré ne fait pas de jointures tout seul par exemple...
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 1.
Effectivement. Cf cependant plus haut pour les classes à coder à la main.
oui bien sur, si le code SQL généré me convenait ca serait trés bien, mais je pense que ce n'est pas assez optimisé
Les résultats de bench semblent montrer le contraire.
il me semble que le code généré ne fait pas de jointures tout seul par exemple...
En effet, avec les EJB 1.x. Mais tu sais, les serveurs modernes implémentent les EJB 2.0 et sont en route pour les EJB 2.1. Je suis d'accord avec le fait que CMP 1.1 c'est pas génial. Mais se baser là dessus pour critiquer le J2EE actuel, c'est comme critiquer XP en se basant sur le DOS, c'est n'importe quoi.
[^] # Re: Avantages ?
Posté par Guillaume Carre . Évalué à 1.
Sinon je ne critique pas J2EE, si c'est moi que tu visais, je critique les EJB Entity Beans CMP (et BMP). Je trouve les Session Beans extremement utiles. Au passage je demande confirmation pour les jointures avec les EJB 2, là aussi si tu as une info je suis preneur :)
[^] # Re: Avantages ?
Posté par Sylvain Dusart (site web personnel) . Évalué à 2.
SELECT OBJECT(c) FROM Chien AS c WHERE c.maitre.age = ?1
(maitre étant le nom de l'attribut représentant le CMP Personne dans le CMP Chien)
ouala...
PS : ça marche aussi pour les liens n-n
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Avantages ?
Posté par boubou (site web personnel) . Évalué à 1.
les Servlet ne sont pas des beans et sont un moyen très efficace d'implémenter des CGI. Ils font effectivement partie de J2EE, comme les EJB.
Sun a rajouté la possibilité de faire un appel local (en passant donc juste par la mémoire) entre SessionBeans et EntityBeans (ce qui revient à admettre de facto que le pattern Session Facade est la plus réaliste implémentation J2EE)
Bof. L'appel local, c'est simplement la reconnaissance officielle par Sun de ce que font les fabriquants de serveur EJB depuis des années, à savoir optimiser les appels entre EJB. La SessionFacade est un moyen d'optimiser (entre autre) les appels entre la couche de présentation et la couche business. Elle consiste en fait à bien programmer la séparation en couche dans le cas où il n'y a pas collocation de la couche de présentation et de la couche business. Tu peux bien sûr utiliser les interfaces locales pour accéder de la couche web à la couche EJB, mais c'est assez débile car ça te bloque dans l'évolution du système : tu ne pourras plus mettre le serveur d'EJB sur une machine différente du serveur JSP/Servlet.
Quand aux implémentations BMP et CMP, elle s'avèrent être à peu près aussi mauvaises l'une que l'autre.
C'est-à-dire ? Le surcout de l'architecture EJB vient en gros exclusivement de l'aspect RMI. La persistence ne pose en général pas de problème.
[^] # Re: Avantages ?
Posté par Guillaume Carre . Évalué à 1.
C'est-à-dire ? Le surcout de l'architecture EJB vient en gros exclusivement de l'aspect RMI. La persistence ne pose en général pas de problème.
pour les CMP:
empreinte mémoire des EJB, et surtout pas d'héritage, c'est un comble, alors qu'on utilise un langage objet!
la norme EJB 2 a pas mal apporté, heureusement:
- interfaces locales comme on a dit
- EJBQL (langage de query)
- relations entre les EJB, 1-1 1-n n-n (CMR = Container Managed RelationShips)
# Re: JOnAS 3.1 est sortie
Posté par zyvad . Évalué à 3.
- à quoi ça sert tout ce bazar Java/Beans/Tomcat/Objetcs/Web ?
- qu'est-ce que ça a de mieux pour faire des applications que tout ce qui existe déjà ?
- qu'est-ce que ça sait faire et qu'on ne peut pas faire autrement ?
- qu'est-ce que ça peut apporter dans l'avenir ?
- existe-t-il un service de taille raisonnable accessible par le Web par lequel on puisse se faire une idée de l'intérêt de l'approche ?
[^] # Re: JOnAS 3.1 est sortie
Posté par boubou (site web personnel) . Évalué à 4.
Quelques réponses, nécessairement basiques :
Tu ajoutes en général Tomcat à apache. Apache se charge des pages statiques et Tomcat de la partie JSP/Servlet. Tomcat est open source et produit par la fondation apache.
[^] # Re: JOnAS 3.1 est sortie
Posté par zyvad . Évalué à 1.
Je te remercie notamment de _ce_ point-clé :
"Globalement, l'idée de tout ce bordel est de simplifier la mise en oeuvre d'applications réparties, c'est-à-dire implémentées par plusieurs machines qui se partagent le boulot. On peut bien sûr faire autrement que d'utiliser ces mécanismes, mais franchement, ça devient vite très difficile. J'ai un cours sur les systèmes répartis (http://apiacoa.org/teaching/distributed/(...) ) qui peut te donner une vague idée des difficultés."
Si je comprends bien, l'un des points-clés de la chose repose sur la difficulté dans l'absolu de paralléliser un algorithme arbitraire.
Même si effectivement, il y aurait matière à débat, a-t-on une idée même vague de l'apport en termes de performances brutes qu'offre la parallélisation sur N machines d'une tâche +/- arbitraire ainsi implémentée par rapport à une implémentation plus traditionnelle sur un système non-scalable, mais non-pénalisée par la méthode ? Ou doit-on considérer l'ensemble des bénéfices (par exemple, inclure le bénéfice conjecturé de l'emploi de Java sur la robustesse du code produit, ou la souplesse supposée de l'approche "web services" dans la communication ou la présentation) dans l'évaluation globale de l'intérêt de l'ensemble ?
[^] #
Posté par Guillaume Carre . Évalué à 1.
Les EJB sont des composants distribués, dans le sens où on peut invoquer leurs méthodes à distance, via RMI.
L'idée est donc dans une application J2EE, de séparer les différentes couches applicatives, et de placer par exemple les applications web (JSP/Servlets) sur une machine, et les EJB sur une autre, pour améliorer la scalabilité de l'application.
On obtient ainsi un environnement n-tiers, avec une machine pour Apache, une machine pour les applications Web, une machine pour les EJBs, une machine pour le SGBD, etc etc...
Ca permet également de répondre à des problématiques de sécurité, comme par exemple interdire l'accés à la machine "EJB", qui contient le métier de l'application, à partir de la machine Apache.
[^] # Re: JOnAS 3.1 est sortie
Posté par zyvad . Évalué à 1.
Vu l'angle du programmeur beutiot que je suis, ce sont des choses auxquelles on reste peu sensible, mais ça peut intéresser d'autres types d'intervenants.
Bon : merci pour toutes ces précisions : l'annonce initiale est maintenant un peu enterrée dans les autres annonces de linuxfr : on se retrouvera pour la suite du débat à la prochaine annonce relative au thème.
[^] # Re: JOnAS 3.1 est sortie
Posté par boubou (site web personnel) . Évalué à 1.
Il ne s'agit de parallèliser automatiquement (un problème plus que difficile, en général NP complet dans ses incarnations les plus simples), mais bien d'offrir un support qui permet d'équilibrer la charge. Sinon, Zyvad, appeler des objets distants est en pratique quelque chose de très difficile. Bien entendu, la partie simple (disons RMI en Java) est conceptuellement et techniquement assez faicle. Le problème est que la réalité est plus complexe. Par exemple, il faut trouver les objets (d'où les annuaires JNDI), il faut gérer des transactions, éventuellement réparties (d'où JTA et le support des transactions dans les EJB), il faut monter en charge (d'où les state less Session Bean et les Message Driven Bean), etc.
Si tu veux continuer la discussion, on peut faire ça par mail !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.