Publié par

Il y a 11 années -

Temps de lecture 7 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

Agilité

RIA

SOA

Le coin de la technique


Actualité éditeurs / SSII

Oracle rachète BEA

Massimo Pezinni du Gartner Group expose son point de vue dans un article paru sur LMI : il voit dans ce rachat un danger de disparition de composants BEA hors WLS et Tuxedo.
Selon lui le projet Fusion est déjà bien engagé chez Oracle et l’arrivée de BEA ne devrait pas changer la donne. Il parle de certains produits qui passeraient en mode maintenance … De là à s’interroger sur l’avenir des produits nouveaux (ALSB, WLI) il n’y a qu’un pas.
Effectivement, en quelques années la gamme des produits BEA s’est considérablement élargie. On distingue 3 gammes :

  • La gamme historique : Tuxedo.
  • La gamme infrastructure WebLogic-* : Weblogic Server, WebLogic Integration, Weblogic Portal et JVM JRockit
  • La gamme SOA : Aqualogic-* : ALSB, ALDSP,ALBPM, ALRR, ALES, ALUI, …

Il faut regarder ce qui est à ce jour massivement vendu chez les client BEA : Weblogic Server, Tuxedo, WLI/WLP, ALSB.

  • Oracle est certainement très intéressé par Weblogic Server qui est reconnu comme l’un des meilleurs serveurs d’applications.
  • WLI est sûrement le produit qui peut résister et continuer à exister s’il est vu comme un outil d’intégration et non comme un moteur de BPM.
  • Concernant ALUI, ex Plumbtree, il y a un gros parc installé. Il faut savoir que ALUI est globalement indépendant du serveur d’application. Pour une réflexion sur les portail BEA/Oracle, vous pouvez lire le billet de Chris Bucchere : One Portal to Rule Them All.
  • De son côté, Tuxedo n’évolue pas énormément. Il est déjà en mode maintenance depuis des années mais avec un parc client énorme.
  • JRockit sous Linux devrait également être conservé. C’est une excellente JVM, plus performante que celle de Sun qui concentre plutôt ses optimisations sur la version Solaris (rien d’étonnant à celà). Ce produit est également un vitrine pour BEA où il démontrait son savoir faire technologique. Si l’investissement annuel est raisonable, Oracle pourrait bien conserver cette vitrine.
  • ALSB (AquaLogic Service Bus), l’ESB de BEA pourrait quant à lui résister car déjà bien vendu et reconnu.

Pour tout le reste, l’avenir semble plus sombre : peu de clients et en doublon avec une offre déjà existante chez Oracle (c’est quand même Oracle qui rachète BEA, et pas BEA qui rachète le département middleware d’oracle).

Agilité

Mike Cohn donne des pratiques d’adoption des méthodes agiles

Mike Cohn, membre fondateur de l’Agile Alliance, donne quelques pistes sur la façon d’injecter des pratiques agiles dans une entreprise à travers des patterns de base.

  • Faut-il démarrer l’agilité sur un petit projet, ou transformer toute l’organisation d’un coup?
  • Faut-il d’abord mettre en place les pratiques techniques XP ou d’abord s’efforcer de développer par itérations, sans mettre en place TDD (Test Driven Development), pair programming ou intégration continue?
  • Faut-il mettre en place l’agilité en « mode furtif », ou faut-il en faire la publicité à travers toute l’entreprise et même en dehors?

Comme toujours, il faut être pragmatique! Et choisir suivant le contexte les pratiques qui s’adaptent le mieux à l’entreprise.

RIA

Qu’est-ce que Flex ?

Ted Patrick, de chez Adobe, répond à la question basique: what is Flex?.
Extrait:

  • Flex est un moyen de produire des fichiers SWF (Flash)
  • Flex est fait pour les développeurs, pas pour les graphistes
  • Flex permet de développer des applications…
  • Qui vont être exécutées sur le web (player Adobe Flash)…
  • Ou sur le bureau (Adobe AIR)
  • Ou sur des mobiles (ce n’est pas encore le cas, et c’est un des gros défauts de Flex !)

SOA

JEE 6 : Extensibility, Profiles and Pruning

InfoQ nous présente les grandes lignes de Java EE 6 dont la version finale est attendue pour Q4 2008. Ce sera la première version modulaire de Java EE grâce à l’introduction des profiles. Le débat discutable « Tomcat est il un serveur Java EE ? » deviendra officiellement caduque, Tomcat implémentera le « Java EE Web Profile ».

Les nouveautés majeures
Fini les serveurs Java EE monolythiques ! Java EE 6 devient modulaires avec l’introduction de profiles.
Ce mécanisme de profile est déjà utilisé dans Java Mobile [1] avec quelques difficultés d’interopérabilité et les promoteurs d’OSGI défendent leur modèle d’assemblage ; on se souviendra quand même du satisfecit que Rod Jonhson, le fondateur de Spring Framework, a adressé aux profiles JavaEE 6 en juillet 2007 (Spring source 2007/07 : Java EE 6 gets it right). On remarquera aussi que le débat sur OSGI est aussi présent sur la spécification JBI 2.0.

Pruning
Le processus de ‘pruning’ (ie. fin de vie) existe depuis longtemps pour les standards Java mais a rarement été utilisé. En rupture avec les versions précédentes, Java EE 6 ouvre le chantier de nettoyage des API désuètes (Java SE 7 suit la même approche). Les premiers candidats à la retraite sont :

  • EJB-CMP : désolé pour les entreprises qui ont investi sur les EJB 1.x et 2.x. La suppression commence par le mécanisme de persistance EJB-CMP et il faudra s’attendra à voir rapidement suivre le reste de ces APIs.
  • JAX-RPC et JAX-Registry [2] : les APIs Web Services pour Java ne vivent pas plus longtemps que les standards WS-*. Ces disparitions auront probablement peu d’impacts, XFire et Axis 1 ont souvent été préférés à JAX-RPC. Quant à JAX-Registry, son utilisation est restée confidentielle.

Les absents

On notera deux absents notables à JavaEE 6:

  • Les portails java et leur gestion de contenu [3] : la vague de marketing intense des éditeurs de portails java est passée ; les promesses de réutilisabilité et de ROI on rarement été au rendez-vous. Les APIs portlet vont-elles se faire ‘pruner’ avant même de rejoindre Java EE ? Nous pressentons plutôt la création d’un profile « java portals » dont la communauté sera très restreinte. Seule une rupture majeure dans la gestion de contenu en Java permettrait de menacer la prédominance de PHP sur ce sujet.
  • Les standards d’intégration JBI et SCA/SDO [4] : ces sujets semblent trop polémiques et trop politiques pour permettre d’entériner des standards Java. JBI 1.0 a déçu ceux qui s’y sont aventurés (ServiceMix, Mule, etc) et l’ébauche de la version 2.0 rencontre toujours l’hostilité d’IBM et de BEA. Ces deux éditeurs lui préfèrent les standards SCA et SDO qui rencontrent un accueil pour le moins circonspect de la part de Sun, peut-être parce que la gouvernance des ces standards est partagée.

[1] JSR 37 Mobile Information Device Profile, JSR 137 Java Game Profile, etc
[2] JSR-101 Java APIs for XML based RPC et JSR 93 Java API for XML Registries
[3] JSR-168 Portlet specification, JSR-286 Portlet Specification 2.0, JSR-301 Portlet Bridge Specification for JavaServer Faces et JSR-170 Content Repository for Java technology API
[4] JSR-208 Java Business Integration et JSR-235 Service Data Objects

Le coin de la technique

Une expérience positive sur Wicket

Après une année passée à développer une application avec Wicket, Julian Sinai, nous donne son retour d’expérience très positif. Venant du monde du « client lourd » (Swing), il a dans un premier temps évalué différents frameworks web:

  • GWT: trop éloigné des autres frameworks web, pas de HTML, pas de WAR
  • Tapestry: gros coût d’entrée, difficile de développer de nouveaux composants
  • JSF: trop complexe

Parmi les points positifs qu’il retire de l’expérience, il insiste en particulier sur la claire séparation entre le code de présentation et le code métier, et sur la facilité avec laquelle on peut développer des composants réutilisables. Matt Raible a commenté rapidement l’article sur son blog.

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

9 réponses pour " Revue de Presse Xebia "

  1. Publié par , Il y a 11 années

    « (la JVM JRockit est) plus performante que celle de Sun »
    Les performances sont relatives et changeantes dans le temps.
    On ne peut clairement pas dire que l’une est supérieure à la seconde, même sur Linux.

    Je suis curieux, existe-il des références de JRockit en production?
    BEA Weblogic Server est il toujours configuré pour utiliser la JVM Sun par défaut?

  2. Publié par , Il y a 11 années

    Alexis =>

    J’ai de mon coté effectué quelques benchs comparant les performances de Weblogic avec les deux JVM (Sun et Jrockit) à chaque fois JRockit était très sensiblement au dessus.

    Je connais au moins deux grands comptes qui font tourner Weblogic avec JRockit.

    Par contre j’ai systématiquement rencontré des bugs avec JRockit, des bugs de stabilité ou des bugs dans les APIs.

  3. Publié par , Il y a 11 années

    Petite précision : La JVM de Sun est proposée par défaut en mode développement mais JRockit l’est pour le mode production.

  4. Publié par , Il y a 11 années

    Bonjour Alexis et merci à l’attention que vous portez à notre blog.
    Voici quelques précisions de notre point de vue sur JRockit :

    Références – utilisation de JRockit en production

    Citer des références est toujours difficile à cause des engagements de confidentialité.
    Si nous rencontrons plus souvent JRockit en production sur des serveurs Windows, voici quelques clients avec lesquels j’ai travaillé qui utilisent JRockit sous Linux :
    * un leader français de la Vente A Distance utilise WebLogic Server 8.1 avec JRockit sous Linux.
    * un leader de l’électronique embarquée utilise JBoss avec JRockit sous Linux RHEL 4.

    Performances

    Les benchmarks comparatifs sont une science délicate qu’il faut manier avec la plus grande vigilance.
    Nous avons retenu le comparatif de JVM Spec JBB 2005 (Java Server Benchmark) sur lequel BEA, IBM et SUN semblent s’accorder puisqu’ils y publient les résultats de leur implémentation.

    S’il est impossible de comparer côte à côte les JVM des différents éditeurs parce que les conditions de tests changent (serveur utilisé, etc), nous remarquerons les très bonnes performances de JRockit (cf ici).

    Cela n’enlève rien aux mérites des implémentations d’IBM et de Sun. On saluera au passage les gains très importants de performances entre les versions 5 et 6 des implémentations de Sun.

    Outillage et exploitabilité

    L’outillage des JVM est un élément clef de l’exploitabilité d’une application Java.

    JRockit a toujours porté une grande attention à ce sujet et le JRockit Mission Control est assurément un argument différenciateur au moment de choisir une implémentation.

    Concernant l’importance de l’outillage des JVM, on se souviendra :
    – de l’interview du Dr Holly Cummins (IBM Hursley labs) sur The Server Side qui nous apprenait qu’IBM mettait actuellement le focus sur l’outillage de sa JVM.

    – de la liste exhaustive des options de la JVM 6 de Sun que maintient Joseph D. Mocker.

  5. Publié par , Il y a 11 années

    Je souhaite apporter une précision : la version de Tapestry évaluée n’est pas précisée, et je suis étonné des remarques si elles portent sur la 5. Tapestry 5 n’a pas grand chose à voir avec Tapestry 4 (si, on a le même auteur, les mêmes concepts, mais ça s’arrête là). Il aurait peut être dû porter un autre nom, pour éviter les confusions.
    Je pense (après évaluation de Wicket 1.3 et Tapestry 5, et après un an de développement avec T5) que T5 est beaucoup plus simple que Wicket (et donc sûrement plus simple que tout autre framework Web Java).

    Le coût d’entrée dans T5 est devenu quasiment nul : on a un application qui fonctionne en une commande grâce à un archetype Maven, on fait ses premières pages et composants au bout de quelques minutes …
    En particulier, les composants sont des POJO, qui doivent uniquement suivre quelques conventions. On n’a pas d’héritage complexe à la Wicket. D’où mon interrogation sur les remarques concernant la complexité de créer de nouveaux composants dans T5.

    Néanmoins, j’ai deux pistes :
    * il est évident qu’en venant de Swing l’auteur se soit retrouvé chez lui avec Wicket. Et c’est peut être aussi pourquoi je suis plus à l’aise avec T5 :)
    * T5 utilise un framework d’IoC (très bon, un peu à la Guice, et qui s’intègre de manière transparente à Spring). L’idée est la même que pour framework d’IoC (gérer le cycle de vie des classes et de leurs dépendances pour elles). Ca permet entre autre de pouvoir injecter des dépendances dans nos classes sans se soucier de la manière dont la classe est retrouvée, et de séparer très clairement les services (sans états) du code de présentation : au final, on a moins de code sans rapport avec le but de la classe. Bref, ce framework d’IoC est abondamment utilisé, et si l’auteur n’est pas familier avec le concept d’IoC, il a pu trouver cela étrange et complexe. Et pourtant, c’est tellement pratique d’avoir une annotation @Inject à la place des 4 ou 5 lignes d’accès aux factories et instances des services…

    En me relisant, mon commentaire fait un peu « prêche pour sa paroisse ». Donc surtout : ne me croyez pas sur parole, tester le, et voyez s’il vous convient.

    Dernière remarques : La partie « interface web » d’InterLDAP ( http://interldap.org ) est en chantier depuis environs un an.

    T5 m’a permis de développer de manière tout à fait élégante un framework de composants génériques relatif à notre métier, que l’on peut surcharger, assembler ou étendre afin de les spécialiser pour un client. Et je commence à être assez content du résultat (le code est libre, et bientôt un site de démo sera mis en place ;)

    Bonne journée,
    Francois Armand

  6. Publié par , Il y a 11 années

    Rouler vite sans airbag ca semble être une pratique courante dans des benchmarks dont l’objectif n’est pas de tester la stabilité mais bien uniquement la performance…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.