jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Logiciel

[20] Slune 0.4
[11] IPCop v1.3.0 est sortie
[45] Nouveaux drivers NVidia
[37] FreeTTS : de la synthèse vocale libre
[109] Faire tourner des applications MS sous Linux
[16] Amaya 8.0
[8] Andromeda9 en GPL
[62] Trusted Debian 1.0
[39] Hyperion Entertainment annonce un accord de portage avec IncaGold
[70] NoMachine - Une alternative libre de contrôle de bureau à distance

Liens connexes

JOnAS (613 hits)
Telechargement de JOnAS (314 hits)
Historique des versions (467 hits)
JOnAS Objectwebforge (340 hits)

Dépêche modérée par

Nyco

Logiciel : JOnAS 3.1 est sortie

Posté par Sébastien (). Modéré le 28 avril 2003.

JOnAS est une implémentation OpenSource de la spécification J2EE de Sun Microsystems (serveur d'application java). JOnAS est un projet faisant partie d'ObjectWeb, consortium incluant l'Inria, France Telecom R&D et Bull.

JOnAS (613 hits)
Telechargement de JOnAS (314 hits)
Historique des versions (467 hits)
JOnAS Objectwebforge (340 hits)

> Lire la dépêche (43 commentaires, moyenne: 2,1).

Les nouvelles "features" de la 3.1 sont (principalement):

- 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.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Re: JOnAS 3.1 est sorti, et la 3.0 est dans la Mdk 9.1

Posté par Benoît Bailleux (Jabber id, ) le 29/04/2003 à 06:34. (lien). Évalué à 8.

Pour info, juste une chose que je ne savais pas encore : la version 3.0 (dommage, la 3.1 est tout de même plus intéressante) est incluse dans les distributions de la Mdk 9.1 (avec Tomcat 4.1).

--
BB

Re: JOnAS 3.1 est sortie

Posté par Stéphane Bourzeix (page perso, ) le 29/04/2003 à 06:39. (lien). Évalué à 4.

Le Plugin Eclipse est une TRES bonne nouvelle, car le probleme de ces applications (Jonas, Jboss ...) est bien souvent leur intégration avec un IDE pour nous faciliter la vie !!

Je m'en vais tester ce plugin de suite ....

[^]Re: JOnAS 3.1 est sortie

Posté par Olivier MARTIN () le 29/04/2003 à 10:29. (lien). Évalué à 2.
Jboss développe depuis quelques mois un plugin eclipse plugin qui vient d'être releasé dernierement. il suffit d'aller faire un tour sur source forge.

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 (page perso, ) le 29/04/2003 à 07:15. (lien). Évalué à 3.

Ils fournissent aussi une version de XDoclet qui convient avec JOnAS 3.1... nottons quand même que pour le moment, jonas ne permet pas de choisir le mapping avec les champs de la base de données :(

Re: JOnAS 3.1 est sortie

Posté par redguts () le 29/04/2003 à 07:28. (lien). Évalué à 3.

Personnellement, ce que j'apprécie le plus c'est la connection à un OpenLDAP pour la gestion de la sécurité

Avantages ?

Posté par Sylvestre Ledru (Jabber id, page perso, ) le 29/04/2003 à 08:10. (lien). Évalué à 2.

Je suis un utilisateur régulier de Tomcat et j'envisage de bientot utiliser un serveur J2EE (Jonas ou Jboss) mais je voudrais savoir, en dehors du fait que beaucoup de libs soient inclus par defaut a l'intérieur (RMI, JDBC, logs ...), ca apporte quoi de plus que Tomcat ?

[^]Re: Avantages ?

Posté par Nelis (page perso, ) le 29/04/2003 à 08:23. (lien). Évalué à 6.
Tomcat c'est un serveur Servlet/JSP.

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.

--
Vache qui rit, à moitié dans son lit
- [^]Re: Avantages ?
  
  Posté par Rage () le 29/04/2003 à 09:14. (lien). Évalué à 4.
  On peut dire que quand tout sera fini et correctement implémenté (traitements de masse type batch, mappage d'une vue dynamique des tables sur un seul Bean) cela permettra réèllement du RAD, programmer plus vite sans réinventer la roue à chaque fois et pouvoir se reposer sur ses deux oreilles pour la gestion des conflits d'accès aux ressources, la sécurité, etc.
  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 (page perso, ) le 29/04/2003 à 09:21. (lien). Évalué à 1.
    qu'on en est encore aux balbutiements
    
    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.
    
    --
    Vache qui rit, à moitié dans son lit
    - [^]Re: Avantages ?
      
      Posté par Rage () le 29/04/2003 à 11:09. (lien). Évalué à 5.
      La critique est juste, aussi j'affine mes propos.
      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 (page perso, ) le 29/04/2003 à 13:33. (lien). Évalué à 3.
    Je crois que tu passes complètement à côté de J2EE. Le but des serveurs d'applications n'est pas de faire du RAD, mais simplement de jouer le rôle de middleware, c'est-à-dire en gros de mécanisme d'intégration simplifié. L'intérêt de J2EE, c'est par exemple :
    
    - 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 () le 29/04/2003 à 14:35. (lien). Évalué à 2.
      Oui,
      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 () le 29/04/2003 à 08:33. (lien). Évalué à 2.
Beaucoup de colle, et de quoi pénaliser lourdement les perfs :
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 () le 29/04/2003 à 08:51. (lien). Évalué à 3.
  Ca dépend du trafic que tu es sensé gérer : le (grand) coup est fixe, mais il existe un (petit) gain, qui est proportionnel au nombre de 'hits' ; donc plus tu as d'utilisateurs, plus tu as intérêt à faire de l'EJB.
  
  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 (page perso, ) le 29/04/2003 à 09:09. (lien). Évalué à 2.
  Je trouve que tu schématises beaucoup ...
  
  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 ...)
  
  --
  Vache qui rit, à moitié dans son lit
  - [^]Re: Avantages ?
    
    Posté par anonyme512 () le 29/04/2003 à 09:56. (lien). Évalué à 2.
    Je schématise beaucoup en effet (j'étais pressé). Mais les tests sont très intéressants néanmoins. C'est à ma connaissance les seuls tests comparant les différents patterns J2EE, ainsi que RMI et Jeremie, le tout pour Jonas, et je voulais surtout fournir le lien en pâture à la faune locale ;-)
    
    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 (page perso, ) le 29/04/2003 à 11:08. (lien). Évalué à 2.
      Pour le monsieur qui ne savait pas ce qu'allait lui apporter JOnAS par rapport à Tomcat : http://www.ashita-studio.com/tutoriaux/ejb/(...)
      
      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
    - [^]Re: Avantages ?
      
      Posté par boubou (page perso, ) le 29/04/2003 à 13:57. (lien). Évalué à 1.
      Ce qui fait le coeur de J2EE c'est bel et bien les EJB
      
      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 () le 30/04/2003 à 08:17. (lien). Évalué à 1.
        Mouais, non, tu noteras que JNDI, JDBC, etc. étaient déjà présents dans J2SE 1.3, et ce pour une très bonne raison: les 3/4 (voir 9/10) des composants en dehors des Servlet/JSP/EJB dans J2EE sont avant tout des composants d'accès à des services/composants hétérogènes à Java (bases SQL, DNS, LDAP, Système sous-jacent, Système de fichier, mail, librairies en C/C++, etc.), ce qui explique qu'on les retrouve dans J2SE, car tout programme Java a potentiellement besoin d'accéder à ces service/composants hétérogènes via une API Java. D'ailleurs, tu noteras que, par défaut, dans J2EE distribué par Sun, il n'y a pas grand chose de plus que Servlet/EJB: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/index.html(...)
        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 (page perso, ) le 30/04/2003 à 09:21. (lien). Évalué à 2.
        le système Servlet/EJB est le coeur de J2EE
        
        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 (page perso, ) le 30/04/2003 à 14:04. (lien). Évalué à 1.
        Tout à fait d'accord !
        
        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.
        
        --
        Vache qui rit, à moitié dans son lit
        
        [^]Re: Avantages ?
        
        Posté par boubou (page perso, ) le 01/05/2003 à 10:24. (lien). Évalué à 1.
        Tout pareil pour JNDI. Il manquait des providers dans les premières versions, mais bon, c'est extensible et plutôt cool.
  - [^]Re: Avantages ?
    
    Posté par Guillaume Carre () le 29/04/2003 à 13:49. (lien). É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 (page perso, ) le 29/04/2003 à 14:03. (lien). Évalué à 1.
      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.
      
      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.
      
      --
      Vache qui rit, à moitié dans son lit
      - [^]Re: Avantages ?
        
        Posté par Guillaume Carre () le 29/04/2003 à 14:21. (lien). É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 (page perso, ) le 29/04/2003 à 14:26. (lien). Évalué à 1.
        ha... je demande confirmation, tu as un lien?
        
        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 () le 29/04/2003 à 14:55. (lien). É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 (page perso, ) le 29/04/2003 à 17:43. (lien). É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?
        
        euh essaye toi-meme avec un exemple simple, et tu verras la difference de vitesse.
        
        [^]Re: Avantages ?
        
        Posté par boubou (page perso, ) le 30/04/2003 à 05:47. (lien). Évalué à 3.
        Bien entendu, si tu n'actives pas les options d'optimisation des communications locales. Les serveurs EJB ont tous ce genre d'option (qui sont d'ailleurs en désaccord avec la norme, mais bon) qui permettent de se passer des interfaces locales du point de vue formel, mais en utilisant le même mécanisme de façon transparente (enfin presque, restent les problèmes de sémantique lié au mode de passage des paramètres objets).
    - [^]Re: Avantages ?
      
      Posté par boubou (page perso, ) le 29/04/2003 à 14:15. (lien). Évalué à 1.
      mais tu as toujours au moins 3 classes par EJB, voir 4 ou 5
      
      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 () le 29/04/2003 à 14:25. (lien). É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 (page perso, ) le 29/04/2003 à 14:31. (lien). Évalué à 1.
        ObjectKey
        
        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 () le 29/04/2003 à 14:46. (lien). Évalué à 1.
        Tout dépend de ton niveau d'acceptance, et des perfs dont tu as besoin effectivement, ca peut convenir... Mais j'ai eu trés peu d'échos favorables à ce sujet, en général ce n'est pas trés glorieux... Si tu as un lien pour tes benchs, ca m'intéresse!
        
        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 (page perso, ) le 29/04/2003 à 17:55. (lien). Évalué à 2.
        si tu as un CMP Personne et un CMP Chien, le tout lié en 1-n (une personne à des chiens), tu peux faire par exemple dans l'EJB-QL pour trouver tous les chiens dont le maitre a comme age XXX:
        
        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 (page perso, ) le 30/04/2003 à 05:49. (lien). Évalué à 1.
        Merci pour l'exemple. En fait, Guillaume a formellement raison au sens ou on doit écrire l'aspect jointure à la main. C'est beaucoup plus simple que d'utiliser JDBC, mais ça reste un peu SQL sur les bords.
- [^]Re: Avantages ?
  
  Posté par boubou (page perso, ) le 29/04/2003 à 13:45. (lien). Évalué à 1.
  tu n'es pas schématique, tu es faux. Exemples :
  
  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 () le 29/04/2003 à 14:31. (lien). É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 () le 29/04/2003 à 19:27. (lien). Évalué à 3.

Je sens que je vais passer pour l'idiot du village, mais tant pis : ce n'est pas un troll, je ne comprends vraiment _rien_ de ce qui se dit

- à 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 (page perso, ) le 30/04/2003 à 06:06. (lien). Évalué à 4.
Vastes questions !

Quelques réponses, nécessairement basiques :
- Tomcat est l'implémentation de référence (i.e. le modèle) de deux spécifications de SUN, les servlets et les JSP (Java Server Page) :
  - les servlets sont une version Java des CGI, c'est-à-dire les extensions côtés serveur d'un serveur web
  - les JSP sont une sorte de version Java de PHP, à savoir une façon d'insérer du code Java dans des pages web afin de les rendre dynamiques (accès à une base de données, calculs, etc.)
  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.
- Les Entreprise Java Beans sont une spécification de SUN pour des composants logiciels côté serveur. Il est très difficile d'en donner une description rapide et simple à la fois. L'idée de base est de proposer un environnement logiciel (le serveur d'application) implémentant de nombreux services (gestion des threads, de la connexion à une base de données, des transactions, etc.) puis de permettre l'insertion de morceaux de code (les Beans) dans cet environnement, de la façon la plus simple possible. Ca apporte pas mal de chose, comme par exemple :
  - les EntityBeans (une des catégories de composant) permettent par exemple de fabriquer des données de façon objet tout en ayant une persistance automatique, c'est-à-dire une sauvegarde transparente des objets en question dans une base de données. Normalement tu n'as plus à écrire de JDBC (l'api Java pour attaquer les bases de données).
  - l'aspect transactionnel (le fait qu'une opération complexe semble être atomique, c'est-à-dire semble s'exécuter comme une seule instruction pour les autres opérations du système) est géré de façon très souple et très automatique dans un serveur d'EJB ce qui est un apport majeur.
- 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.
- Finalement, tu peux lire le tutoriel de sun ( http://java.sun.com/j2ee/tutorial/1_3-fcs/(...) ) qui te donnera quelques idées sur J2EE, mais franchement, ça demande beaucoup de lecture...
- [^]Re: JOnAS 3.1 est sortie
  
  Posté par zyvad () le 30/04/2003 à 16:33. (lien). Évalué à 1.
  Merci d'avoir essayé de m'expliquer : le rôle de chaque composant me semble maintenant beaucoup plus clair.
  
  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 () le 30/04/2003 à 21:36. (lien). Évalué à 1.
    Je crois que l'idée de "répartition", plutôt que la répartition de charge entre plusieurs machines, signifie plutôt "distribution".
    
    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 () le 01/05/2003 à 10:14. (lien). Évalué à 1.
      Haaaa... oui, effectivement, je crois comprendre mieux l'intérêt de la chose, maintenant. Invoquer des procédures sur des "objets" distants en soi ne pose pas de véritables problèmes, à condition de ne pas ajouter tout un lots d'assertions (confiance en le réseau, en le système hôte, transparence sur les conditions d'hébergement de l'objet, mobilité effective des objets et des systèmes dans un périmètre, etc.), auquel l'ensemble prétend répondre implicitement : en labellisant chaque composant du système du sol au plafond, on fournit des assurances implicites à des exigences qui ne le sont pas moins :-)
      
      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 (page perso, ) le 01/05/2003 à 10:31. (lien). Évalué à 1.
        Très bonne réponse de Guillaume !
        
        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 !

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Logiciel : JOnAS 3.1 est sortie

Re: JOnAS 3.1 est sorti, et la 3.0 est dans la Mdk 9.1

Re: JOnAS 3.1 est sortie

[^]Re: JOnAS 3.1 est sortie

Re: JOnAS 3.1 est sortie

Re: JOnAS 3.1 est sortie

Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

[^]Re: Avantages ?

Re: JOnAS 3.1 est sortie

[^]Re: JOnAS 3.1 est sortie

[^]Re: JOnAS 3.1 est sortie

[^]

[^]Re: JOnAS 3.1 est sortie

[^]Re: JOnAS 3.1 est sortie