Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
SOA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Actualité éditeurs / SSII
Les standards du Cloud Computing en préparation
Comme pour tout marché émergeant, le Cloud Computing s’est développé autour de technologies propriétaires mises au point par différents éditeurs et fournisseurs. Une session dédiée aux problématiques d’intégration lors du CloudCamp Paris avait conclu qu’aucun standard adapté n’était disponible pour permettre le transfert d’informations entre les différents fournisseurs et technologies du Cloud Computing.
Le monde du Cloud Computing montant en puissance mois après mois, la problématique de standardisation se fait de plus en plus pressante. C’est donc sans surprise qu’on a assisté à la constitution d’organismes de standardisation et de groupes de travail afin d’établir les standards à venir. Afin de donner une visibilité à l’ensemble de ces efforts, l’Open Grid Forum (OGF) annonce la création d’un site commun ou chaque organisme est invité à présenter ses travaux en cours : http://cloud-standards.org. On notera particulièrement deux spécifications prometteuses :
- Open Virtualization Format (OVF) : Format de packaging d’application permettant la distribution et le déploiement simplifié sur environnement virtualisé.
- Open Cloud Computing Interface (OCCI) : API standardisée permettant la définition, le provisioning et le monitoring d’infrastructures exposées en tant que services sur un Cloud (IaaS).
Par ailleurs, l’Open Cloud Consortium (OCC) explique travailler sur des frameworks d’interopérabilité entre Clouds et l’OASIS expose quant à elle sa vision selon laquelle le Cloud Computing est une extension naturelle des concepts SOA, et que, par conséquent, de nombreux standards qu’elle développe actuellement intègrent cette problématique.
Fin de JavaRebel, place à …
Zeroturnaround, l’éditeur de JavaRebel, doit faire face à un joli défi : pour avoir fait une entorse à la marque déposée Java, il doit modifier le nom de son produit, sans pour autant perdre la notoriété d’ores et déjà acquise. Pour faire d’une pierre deux coups (modifier effectivement ce nom mais aussi s’offrir un joli coup de pub), l’éditeur soumet ce renommage à un concours. En jeu, une licence JavaRebel à vie…
RIA
GWT 1.7 pour les nouveaux navigateurs !
Les dernières releases de GWT étaient plutôt espacées dans le temps (1 an entre 1.4/1.5 et 8 mois entre 1.5/1.6) mais il n’aura fallu attendre que 3 mois pour voir débarquer la version 1.6.5 1.7 de GWT.
Cette dernière version (définie comme mise à jour mineure / bugfix release) apporte un meilleur support des derniers navigateurs à savoir Internet Explorer 8, FireFox 3.5 et Safari 4 (meilleur support d’IE8 = disparition d’IE6 ? 
).
L’ajout du user.agent ie8, qui peut potentiellement impacter certains projets, a fait pencher la balance vers un numéro de version de type majeure (1.7) pour forcer les développeurs à être attentif sur ce point important (une version de type 1.6.5 n’aurait pas eu le même impact).
Une simple recompilation suffit pour être compatible avec ces navigateurs, aucune modification de code n’est requise. Disponible comme toujours dans la section téléchargement du Google Code.
Flex Monkey 1.0
Plus de 7 mois après la sortie de la version 0.5 (précédente revue de presse), FlexMonkey, le framework de tests automatisés pour applications Flex et Air, se met à jour et passe ainsi en version 1.0 (par InfoQ).
Au menu : réorganisation de l’interface utilisateur, support direct d’applications Air (la console FlexMonkey devenant d’ailleurs une application Air) et tests générés pour Fluint (qui pourront aussi être lancés par FlexUnit 4).
Plusieurs tutoriels/exemples sont déjà disponibles sur la toile, on retiendra plus particulièrement le Getting Started d’Eric Owens (Gorilla Logic) et l’article très complet de Stuart Stern (CEO de Gorilla Logic et créateur de FlexMonkey) sur InfoQ.
SOA
La base de données dans une Event Driven Architecture
Sur son blog dédié aux traitements des évènements dans les systèmes d’informations, Tibco a publié un billet portant sur le positionnement d’une base de données dans une Event Driven Architecture (EDA).
Se trouvant à la base de nombreuses applications et services, elle constitue en effet une potentielle source d’évènements très intéressante. L’auteur met alors en avant la technologie Continuous Query Notification (CQN) intégrée à Oracle 11g, et qui permet aux clients d’une base de données de s’enregistrer pour recevoir des notifications lorsque les données d’une table ou le résultat d’une requête prédéfinie changent. On peut assimiler cette technologie à un mécanisme de trigger qui rappellerait des systèmes externes.
Cette possibilité permet ainsi d’enrichir les sources d’évènements disponibles au sein du système d’information : de par son positionnement, la base de données est capable d’offrir simplement des évènements qui seraient parfois complexes à générer au niveau applicatif. Dans une telle configuration, le Complex Event Processing (CEP) permettra alors de manipuler le volume important d’évènements ainsi créés afin d’en extraire des informations métiers utiles.
REST et les abus de langage
Ryan McDonough, contributeur au projet RESTEasy, a publié un billet dans lequel il fait un parallèle entre les abus de langages liés à REST et les mauvaises pratiques qui en découlent.
Parmi les erreurs de compréhension qu’il met en avant, on retrouve l’assimilation de REST à un protocole, la définition de REST en tant que synonyme de HTTP, ou encore l’utilisation abusive du qualificatif RESTful.
Il est souvent question lorsque l’on parle de REST de définition d’URLs, de représentations multiples d’une ressource, ou, plus couramment encore, d’opposition à SOAP. Loin de ces problématiques, Ryan McDonough met ici en avant le fait que REST est dans la réalité trop souvent utilisé pour justifier à tort tout type d’utilisation douteuse de JSON ou XML sur HTTP…
A ce titre, le livre RESTful WebServices de Leonard Richardson et Sam Ruby permet de comprendre en détail toutes les nuances de ce modèle d’architecture qui sont parfois délicates à appréhender.
Le coin de la technique
OpenDS passe en version 2.0
La version 2.0 du projet OpenDS est disponible. Il s’agit d’un serveur LDAP implémenté entièrement en Java et soutenu par Sun ; ces caractéristiques le positionne donc directement face à Apache Directory Server, son équivalent développé par la fondation Apache.
Ludovic Poitou présente les principales nouveautés de cette version :
- Ajout d’un control panel graphique, en remplacement du status-panel de la version précédente, permettant d’administrer le serveur et ses données
- Amélioration de la réplication multi-master
- Support de connections sécurisées SASL
- Affinement du système de contrôle d’accès
- Amélioration des performances. On notera sur ce point la collaboration avec l’équipe du garbage collector G1 qui avait été exposée il y a 2 mois
Au delà de l’ajout de fonctionnalités, la question du positionnement reste entière pour OpenDS tout comme pour son rival ApacheDS. En effet, l’annuaire est en général une ressource critique du système d’information pour laquelle on préfèrera généralement une implémentation native plus mature. Dès lors, OpenDS se destinera principalement au poste de développement, aux tests, et aux applications embarquant directement leur propre annuaire comme mécanisme de persistance.
10 bonnes raisons de chercher le successeur de Java
Dans la droite ligne d’un certain nombre de keynotes récentes, Mario Fusco expose, sur TheServerSide, 10 bonnes raisons de chercher un héritier à Java. Ces ‘manques’ de Java sont souvent évoqués, parfois partiellement comblés par les futures spécifications. Il nous a semblé malgré tout intéressant de les reprendre ici, ne serait ce pour que ces limitation soient bien comprises de tous.
- Absence de Closures, et son corollaire, l’absence de pointeur sur les fonctions (first-class function).
- L’existence de types primitifs (le langage n’est pas 100 % objet), et un autoboxing pas toujours performant (sur la gestion des null par exemple).
- La faiblesse des Génériques : impossible de découvrir leur type au Runtime.
- L’impossibilité de supprimer certains warnings concernant les génériques.
- Impossible de passer un paramètre void à une méthode.
- Le pattern proxy n’est pas implémenté de manière native sur les classes concrètes.
- Le switch…case est très faible
- La présence des exceptions Checked qui obligent à de douloureux
try...catchou à d’illisiblesthrows
Mario Fusco a l’honnêteté de reconnaitre que nombre de ces défauts font partie des péchés originels de Java et qu’il est quasiment impossible de les remettre en cause sans gravement compromettre la compatibilité ascendante du language, qui en est une des pierres angulaires. C’est pour cette raison qu’il se met en quête du next gen language
Vous ne manquerez pas de remarquer que, comme tout article qui parle de succéder à Java, ce billet est richement (parfois de manière assez virulente) commenté.
Evènements de notre communauté en France et à l’étranger
Soirée Tontons Flexeurs
Demain (mardi 21 Juillet) de 18h à 20h se déroulera une nouvelle soirée des Tontons Flexeurs dont le sujet est un retour d’expériences sur la mise en place d’applications Flex en entreprise dans le monde Java (tests unitaires/fonctionnels, intégration continue…).
L’événement étant déjà complet, il ne vous reste plus qu’à bookmarker leur calendrier pour être informé des prochaines réunions
Bonjour,
Comme toujours votre revue de presse est très intéressante : sujets variés, résumés concis et pertinents. Merci.
Je reviens sur le sujet « REST et les abus de langage » : je vous rejoins totalement car je mène depuis longtemps un combat acharné contre les préjugés et incompréhensions concernant REST
REST n’est pas si facile que cela à appréhender. En complément de votre post, j’invite donc les intéressés à consulter :
– mon blog pro, sur lequel je viens d’entamer une démarche de clarification des concepts REST en une dizaine de points : http://www.aeon-consulting.fr/fr/blog/ (Aeon Consulting)
– mon blog perso, sur lequel j’ai déjà posté plusieurs articles dans le même esprit que le vôtre : http://francois.goldgewicht.com
Je pense en effet qu’échanger est essentiel dans cet objectif de clarification.
François Goldgewicht
Bonjour,
Je vous remercie pour avoir diffuser l’information concernant la sortie d’OpenDS 2.0.
Par contre je tiens a preciser quelques details:
- OpenDS n’est pas positionné directement face a Apache Directory Server et n’est pas destiné au poste de developpement. Certes on peut considerer qu’OpenDS n’est pas aussi mature qu’OpenLDAP ou Sun Directory Server, mais il est conçu et réalisé par l’équipe de développement de Sun Directory Server, bénéficiant de plus de 10 ans d’experience dans le domaine. L’objectif du projet OpenDS est de fournir une nouvelle génération de services LDAP plus performants, plus complets et plus faciles a utiliser. Et le produit Sun Directory Server Enterprise Edition 8 s’appuyera sur la technologie OpenDS.
- La notion d’implementation native est ambigue et incorrecte. Elle sousentend que une implementation en Java ne peut avoir les performances ou caracteristiques d’un serveur ecrit en C ou C++. Il suffit de suivre un peu le projet OpenDS pour se rendre compte que le serveur n’est pas un jouet de developpeurs. Les tests de base se font avec des bases de données de 10 millions d’utilisateurs. Les temps de réponse sont de l’ordre de UNE milliseconde. Et certains benchmarks ont produit des résultats difficiles a obtenir avec des serveurs natifs et mature : http://blogs.sun.com/ds/entry/opends_nehalem_benchmark_sunblade_6270
- OpenDS ne vient pas s’aligner avec Apache Directory Server concernant la replication multi-maitre. La replication multi-maitres est present dans OpenDS depuis la version 1.0, sortie il y a un an. Les ameliorations presentes dans la version 2.0 incluent le support jusqu’a 8 servers maitres, un mode de Replcation Assurée qui garantit la disponibilité et la fiabilité des données.
Pour conclure, je dirais qu’avec la version 2.0, OpenDS arrive dans sa phase de maturité et se pose en concurrent sérieux de tous les serveurs d’annuaire LDAP d’entreprises.
Cordialement,
Ludovic Poitou
http://blogs.sun.com/Ludo
@Ludovic
Merci pour ces précisions apportant une clarification sur la question du positionnement d’OpenDS. L’opposition à ApacheDS est difficilement évitable mais il est vrai qu’une perspective d’intégration de la technologie OpenDS au sein du prochain Sun Directory Server donne une dimension différente au projet open source de Sun.
Notre formulation « on préfèrera généralement une implémentation native plus mature » mérite quelques précisions :
- Il existe plusieurs serveurs d’annuaire très matures développés en C ou C++, sous licence commerciale ou Open Source, face auxquels on trouve maintenant deux challengers implémentés en Java que sont OpenDS et ApacheDS. Lors du choix d’une technologie destinée au support d’une ressource critique, il est naturel de se tourner vers une solutions mature qui apportera une plus large communauté et des compétences plus courantes. Dans un tel contexte, une solution plus récente devra a priori proposer des apports significatifs de fonctionnalités ou de performances pour devenir compétitive.
- Nous ne souhaitions pas mettre en doute les performances des implémentations qui se basent sur Java. Le garbage collector a longtemps été une source d’inquiétude pour ce type d’applications, mais les récentes améliorations en la matière et plus particulièrement le très prometteur G1 tendent à minimiser cette problématique.
Enfin, notre imprécision sur la réplication multi-master offerte par OpenDS a été corrigée.
Cordialement,
Michael Figuière (Xebia)
Perso, j’ai un faible pour un serveur LDAP en Java, plutôt qu’en C ou C++, car Java est mon langage de programmation de ces dernières années (raison de « confiance », et je me dis aussi que s’il fallait « étendre » ce serveur de qque manière que ce soit, un serveur en Java ferait plus l’affaire) et un serveur programmé en Java est moins sujet à certains pbs de sécurité, comme les pbs de déplacement de buffer (et sans doute aussi plus facile à installer).
De fait, l’approche serveur LDAP en Java me semble plus intéressante qu’un serveur C++ relativement équivalent en C ou C++.
Votre avis sur le positionnement d’OpenDS sent très fort l’affirmation gratuite passée au pipotron !
Au passage, ne vous arrive-t-il donc jamais d’utiliser un serveur d’applications full java (qui bien sûr n’est pas une ressource critique…) ?
Concernant REST, il me semble qu’on peut tout de même dire que l’expression de « représentations multiples d’une ressource » est pas totalement fausse quand même il me semble ? Ce n’est pas un abus de langage que de dire ça, je crois ?
D’ailleurs, dans le billet indiqué, on trouve : « There are only resources and representations, and it’s the representations of those resources you need to be specific about. »
Y a-t-il quelque chose que je n’ai pas compris ?
De toutes façons merci pour votre très intéressante revue de presse, continuez, malgré mes critiques que j’espère constructives.