JBoss 4.0 est un serveur d'application J2EE disponible sous licence LGPL. L'obtention de cette certification le place au même niveau de qualité que des produits propriétaires comme WebSphere d'IBM ou WebLogic de BEA. Cette certification de compatibilité prouve une fois de plus que le monde Open Source/libre peut offrir des solutions alternatives viables aux produits professionnels. JBoss Inc. s'efforce en outre de développer les futures technologies du monde J2EE en participant activement au JCP (Java Community Process, un consortium de développeurs contribuant à l'évolution des technologies Java) avec par exemple un travail important sur les EJB 3.0 (Enterprise Java Beans).
Aller plus loin
- JBoss Inc. (1 clic)
- JCP (2 clics)
- DLFP : « L'administration fiscale opte pour JBoss » (4 clics)
- Communiqué de presse (0 clic)
# Bien mais...
Posté par xsnipe . Évalué à 5.
[^] # Re: Bien mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
http://about.me/straumat
[^] # Re: Bien mais...
Posté par capicapio . Évalué à 1.
C'est le grand départ des EJB, à mon humble avis
[^] # Re: Bien mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Je pense que ca va booster l'utilisation des EJB et vraiment les mettre au centre des applications J2EE.
http://about.me/straumat
[^] # Re: Bien mais...
Posté par Romain Guy . Évalué à 2.
[^] # Re: Bien mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: Bien mais...
Posté par Gabriel . Évalué à 2.
http://www.beust.com/weblog/archives/000131.html(...)
Ou c'est Matt Raible je ne sais plus? qui montre la différence de bla-bla entre l'annotation et les xdoclets.
http://www.raibledesigns.com(...)
[^] # Re: Bien mais...
Posté par boubou (site web personnel) . Évalué à 3.
Oui, enfin, c'est pas si ouvert que ça les JCP...
[^] # Re: Bien mais...
Posté par Romain Guy . Évalué à 2.
[^] # Re: Bien mais...
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Pour les applications non J2EE, vive hibernate ;)
http://about.me/straumat
# Ne dîtes pas "même niveau de qualité" mais plutôt "compatible avec" :o)
Posté par yod81 . Évalué à 7.
Si je ne m'abuse, cela signifie qu'il est parfaitement compatible avec le standard J2EE proposé par SUN. Est-ce qu'on peu pour autant parlé de même qualité (rapidité d'exécution, stabilité, etc. ) ?
De plus, la "valeur ajoutée" des Webspheres et autres est la présence d'extention plus ou moins compatibles avec le standard, que les utilisateurs ne trouveront pas ailleurs. Est-ce que quelqu'un a une idée des "plus" de Jboss ?
[^] # Re: Ne dîtes pas "même niveau de qualité" mais plutôt "compatible avec"
Posté par Stéphane Traumat (site web personnel) . Évalué à 8.
On peut peut être pas parlé de même qualité étant donné que, justement, la force de J2EE est dans le fait que chacun peut faire sa propre implémentation.
Par contre, cela signifie qu'une application développé pour JBOss poura, sans recompilation tournée sous Websphere... le code source n'aura pas à être changé.
A mon avis.. le mieux, c d'utiliser J2EE et ainsi de ne se marrier avec aucun vendeur.
http://about.me/straumat
[^] # Re: Ne dîtes pas "même niveau de qualité" mais plutôt "compatible avec"
Posté par jde . Évalué à 5.
Par contre ce qu'on peut reprocher aux serveurs d'appli c'est que chacun y va de son (ses) petit fichier de conf xml perso, ce qui fait q'un war ou un ear fait pour jboss ne fonctionnera pas tel quel dans weblogic ou autre ...
[^] # Re: Ne dîtes pas "même niveau de qualité" mais plutôt "compatible avec"
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Et c'est bien la l'avantage, les fichiers de config particuliers permettent à chaque "vendeur" d'offrir des choses en plus à leur client comme le nbe d'ejb de session crée par défaut...
Il est à noter que des outils comme XDoclet permettent de générer automatiquement les fichiers spécifiques à chaque serveur... un bon exemple : http://xpetstore.sf.net(...) qui est un site de e commerce J2EE qui tourne aussi bien sous JBoss que sous Websphere et Weblogic
http://about.me/straumat
# newbie
Posté par ascobol . Évalué à 7.
Désolé pour cette question peut-être triviale, mais ça sert à quoi un serveur d'application J2EE ?
C'est la machine virtuelle java qui permet d'exécuter un programme écrit en java ?
C'est un compilateur ?
La terminologie Java, c'est décidément trop compliqué pour moi :-(
merci
[^] # Re: newbie
Posté par TImaniac (site web personnel) . Évalué à 10.
Le but est de ne pas avoir à réinventer la roue à chaque fois, les même services étant souvent nécessaire d'une solution à l'autre.
[^] # Re: newbie
Posté par philou (site web personnel) . Évalué à 1.
Vous en pensez quoi ?
[^] # Re: newbie
Posté par RuleZ . Évalué à 9.
Probablement que PHP remplace du JSP ici ou la, mais pour ce qui est des applications il est incapable de faire le poid face à J2EE.
PHP est un language dont la fonction primaire, principale est de faire du web dynamique. Pour Java, le web dynamique n'est qu'une de ses capacités. Et d'ailleurs, de ce qui j'ai pu lire, JSP est retravaillé pour permettre une simplicité comparable à PHP (car pour l'instant, il est vrai que rien ne rivalise avec php en terme de rentabilité ... dans le domaine des languages de type scripts pour web dynamique)
Sinon, à propos de JBoss, c'est probablement ce qui manquait à Java pour faire fasse à .NET, sa certification est une très bonne nouvelle. J2EE se confirme en standart ouvert et normé, avec maintenant un pied dans le libre.
[^] # Re: newbie
Posté par Eric Boulat . Évalué à 10.
La déclaration implicite des variables en php est une source inépuisable de bugs trés difficile à retrouver. L'absence de compilateur en est une autre ! Quant à la prog objet en php3 et 4 n'y pensez même pas ! Au moins avec le php5 on a enfin un modèle objet digne de ce nom ! Normal Sun a collaboré avec Zend sur son développement histoire que php soit à java j2ee ce que vb est à .net un langage facile de prime-abord pour ne pas décourager les développeurs débutants.
Mais selon moi il est quand même plus sur de développer en jsp qu'en php, la librairie standard est mieux organisée, plus vaste et la réutilisation du code est nettement plus aisée ! En développement on passe plus de temps en maintenance et évolution qu'en nouveau développement, il faut y penser !
[^] # Re: newbie
Posté par Gabriel . Évalué à 2.
Avantage énorme du php - à mon avis - la productivité, les solutions déjà développées (phpmyadmin, phpBB, daCode, postNuke, spip etc... ), l'intégration naturelle avec le html, solutions qui peuvent se comprendre facilement (tu rajoutes un serveur, un autre, un troisième, si tu as bien codé à la base ça peut marcher etc.), une vitesse tout à fait acceptable pour du web (je sais, j'aproxime: php<>web).
Personnellement je trouve aussi un avantage que pour la vue (du modèle MVC) il n'y ait pas de compilation, que l'on puisse changer et travailler sa vue à toute vitesse - comparé aux jsp, c'est notable je te jure...
Avantages du java: la propreté du modèle, le langage tout terrain (web et pas web, gros systèmes et petits..), la propreté de certaines librairies (hibernate/spring). Mais désavantage : on peut faire des trucs très nuls en java (grâce à certaines specs trop compliquées dans les ejb par ex)
Exemple de propreté : les taglibs:
<forEach var="personne" items="listeDuPersonnel">
<li>
<c:out value="${personne.nom}" />
</li>
</forEach>
C'est facile à lire et je trouve mieux que le mixte de code php+html
[^] # Re: newbie
Posté par Stéphane Traumat (site web personnel) . Évalué à 7.
Et oui, les JSP avec la JSTL tend à se rapprocher de PHP mais LAMP a déja pris toute la place chez les hebergeurs.
J'ai fait une introduction à J2EE pour ceux que cela interesse : http://www.ashita-studio.com/articles/j2ee/introduction_J2EE.html(...)
http://about.me/straumat
[^] # Re: newbie
Posté par jde . Évalué à 2.
[^] # Re: newbie
Posté par Romain Guy . Évalué à 1.
[^] # Re: newbie
Posté par Gabriel . Évalué à 2.
De plus ça veut dire qu'il faut un outil
Je trouve aussi très intéressant le modèle jsf mais pas facile pour un pauvre codeur qui n'a que ses 10 doigts (et eclipse). Est-ce que vous avez vent d'un projet open source qui s'intéresserait aux jsf?
De plus l'idée d'abstraire le modèle http ça me fait tj bizarre - parce que ce protocole a ses spécificités (protocole sans état, le système des requètes réponses...) Là dessus j'attends de voir aussi
[^] # Re: newbie
Posté par matli . Évalué à 3.
L'un des avantages de J2EE à mon sens est le fait que l'accès aux ressources est géré au niveau du serveur d'appli, et non pas au niveau de chaque appli. Par exemple, pour accéder à une base de donnée, tu définis au niveau du serveur un pool de connexion vers cette base de donnée, et l'appli utilisera, voire partagera, ce pool de connexion. De plus, le nombre de connexion à une base de données est un paramètre extrêmement sensible dans la phase de tuning.
Il n'est donc pas raisonnable de laisser les développeurs prendre cela en charge car ceux-ci n'ont en général aucune idée de ce que peuvent être des contraintes de production:
- le dev: ah ben quoi, pourtant ça marche bien sur mon PC
- l'admin: ben ça marche moins bien avec 200 utilisateurs...
Avec PHP, ceci n'est pas possible (pour l'instant?)
Pour reprendre les autres commentaires, PHP et J2EE n'ont pas du tout la même cible, et surtout, J2EE, ce n'est pas que jsp!!!
[^] # Re: newbie
Posté par Nicolas Delsaux (site web personnel) . Évalué à 10.
Pour ça, un serveur J2EE doit fournir les outils correspondant à un ensemble de normes dont les noms commencet souvent par J :
JMX (Java Management Extension) pour intégrer le serveur à un Nagios, par exemple
JMS (Java Messaging System) pour l'envoi de messages événementiels sur les systèmes de messages (jai oublié le nom, mais globalement, ça n'a rien à voir avec Evolution, Outlook ou Opera)
JTS (Java Transaction Service) pour gérer les transactions, voire même les transactions distribuées
JSP (Java Server Pages) une petite techno de présentation, qui a vécu.
EJB (Enterprise Java Beans) la norme phare de J2EE, qui définit des "objets métiers" sous un certain nombre de forme qui nous font revenir à l'époque bénie des struct C. Le seul avantage étant qu'ici, les struct peuvent être persistées de manière quasi-transparente ...
Et tant d'autres que j'oublie
Tout ça c'est bien joli, mais en fait, à sens, si J2EE apporte une certaine capacité d'intégration de Java à "l'informatique d'entreprise", ça se fait au prix de nombreuses contorsions :
- Durant le développement, car J2EE est une norme ouverte, qui n'impose que peu de choses (et qui notamment n'impose pas les descripteurs de déploiement permettant d'organiser tout le bouzin). Ce qui fait qu'une appli J2EE n'est en général pas ou peu portable (à moins bien sûr d'être codée avec des outils génériques, comme XDoclet ou Ant, et encore ...). Bref, l'enfer, le véritable enfer du développement J2EE, c'est que loin de nous aider à développer plus facilement grâce à une meilleure organisation Java (ce qui est en partie fait), le code est complètement scindé entre d'un côté le développement de composants Java, et de l'autre leur organisation (qui n'est souvent pas réellement séparée, du fait que ces applications soient le plus souvent des saletés de gestion) qui elle est contenue dans des fichiers XML.
- Durant l'utilisation, on est quand même très loin d'applications rapides. D'accord, ça marche, mais comme le dit de plus en plus de monde, la complexité de J2EE le rend inaccessible à l'immense majorité des développeurs. De plus, comme toute usine à gaz qui se respecte, le coût d'exploitation n'est pas nul, puisqu'il existe désormais des postes d'administrateurs d'applications J2EE, dont le rôle, tout comme pour un admin Oracle, est de faire en sorte que ça continue à marcher (!).
Bon, pour moi, développeur Java, il est clair que c'est uin bon gagne-pain. Toutefois, je trouve ça dommage qu'une techno comme Java serve à "ça", et surtout de cette manière là.
# Coquille ?
Posté par Mes Zigues . Évalué à 10.
Ce ne serait pas propriétaire par hasard, parce que l'alternative aux produits professionnels existe, c'est Microsoft.
Désolé, je n'ai pas pu résister.
[^] # Re: Coquille ?
Posté par George Tramo . Évalué à -1.
# Dommage
Posté par Stéphane Traumat (site web personnel) . Évalué à 5.
Néanmoins, on devrait l'avoir plus tard dans l'année.. à la rentrée j'éspère
http://about.me/straumat
[^] # Re: Dommage
Posté par matli . Évalué à 1.
Vivement que les alternatives libres viennent "rafraîchir" le marché
[^] # Re: Dommage
Posté par capicapio . Évalué à 1.
Si ce dernier obtient sa certification à la rentrée, on pourra dire qu'il lui a fallu moins longtemps ;-)
Sérieusement, 2 serveurs d'application J2EE libres, ça devrait changer la donne dans les développements java...
[^] # Re: Dommage
Posté par Gloo . Évalué à 1.
Pauvre choux.
Je sabrerai le champagne aussi quand le tour de jonas viendra. C'est une des plus bonnes news de l'année je trouve.
Mais bon, java-ca-pu-c-pas-libre hein ;)
[^] # Re: Dommage
Posté par Olivier Serve (site web personnel) . Évalué à 4.
Certes, mais on trouve énormément de logiciels libres en Java, notamment tous les projets de Apache-Jakarta (Tomcat/Axis, Xerces, les commons), Eclipse ...
Je ne comprends pas bien pourquoi, mais c'est un fait. Je pense que c'est dû au fait que l'utilisation de Java étant assez récente pour autre chose que des applets, des logiciels libres ont pû apparaître très tôt, conviennent à beaucoup de monde et sont devenus des standards de fait (l'un des meilleurs exemples est Tomcat utilisé par des serveurs J2EE propriétaires). Il me semble que dans la communauté Java, l'utilisation de LL est devenue "naturelle".
Enfin bon, c'est juste mon avis et je le partage.
# Merci
Posté par Tr4m0 . Évalué à -3.
[^] # Re: Merci
Posté par Mitch 911 . Évalué à -6.
Merci Pierre Tramo pour cette certification J2EE
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.