Publié par

Il y a 10 années -

Temps de lecture 11 minutes

Revue de Presse Xebia

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

SOA

Le coin de la technique

SOA

SOA Manifesto : pragmatisme utopique ?

La communauté SOA vient de publier son SOA Manifesto. Les valeurs sont très consensuelles, on pourrait même les trouver trop lisses quand on a vécu un naufrage SOA (avec l’oubli des objectifs métier, sa perfection naïve initiale, ses services faussement partagés qui finalement ne satisfont même pas le premier consommateur et autres ESB passe-plats).

Saluons tout de même cette initiative. SOA est une réalité. Les projets utopistes sont aujourd’hui minoritaires face à tous les projets qui intègrent des web services pour interconnecter les applications.
Le Manifeste SOA en français :
Valeur métier plutôt que stratégie technique,
Objectifs stratégiques plutôt que bénéfices spécifiques à un projet,
Interopérabilité intrinsèque plutôt qu’intégration propriétaire,
Services partagés plutôt qu’implémentation spécifique à un besoin particulier,
Flexibilité plutôt qu’optimisation,
Amélioration incrémentale plutôt que recherche de la perfection initiale.

Et rassurons-nous, ce n’est pas un manifesto qui empêchera les zélotes SOA de se déchirer. La guerre SOAP versus REST bat (toujours) son plein :-).

Ils parlent du SOA Manifesto : InfoQ SOA Manifesto, Stefan Tilkov’s Weblog : Comments on SOA Manifesto.

Allez, je retourne à mes web services Contract First avec CXF ;-).

WADL devient une Submission W3C

Marc Hadley, auteur de la spécification WADL et spec-lead de la JSR-311 (JAX-RS), a annoncé que WADL venait d’être accepté en tant que Submission W3C.

Cette spécification portée par Sun a pour but de définir un format XML de description de services REST. Il s’agit donc d’un équivalent à WSDL pour REST. Alors que REST-*, porté par JBoss, a récemment relancé le débat sur la tendance récurrente à vouloir intégrer dans REST les fonctionnalités des très controversés WS-*, la soumission de WADL au W3C fait réapparaître la question de l’intérêt de définir des contrats pour des services REST.

Joe Gregorio s’opposait vivement à l’initiative WADL il y a deux ans déjà. Il reprochait principalement :

  • l’insuffisance de WADL pour définir élégamment tous les types de services REST
  • la fragilité du client qui ne fonctionne plus lorsque le contrat change comme c’est déjà le cas avec WSDL
  • le manque de réalisme de l’approche WADL2Java qui ne permettrait pas la pleine exploitation de REST. Il préférait donc une approche d’écriture du client REST manuelle, en se basant sur un socle commun.

Toutefois, l’approche « REST avec un contrat » est séduisante pour les applications d’entreprise dont les services sont souvent aussi nombreux que les consommateurs variés.
C’est dans cette logique que de nombreux projets lèvent les ambiguïtés de leurs services REST en préférant XSD à JSON. Les URL et paramètres d’appel restant alors décrits uniquement dans une documentation annexe.

Par ailleurs, on peut regretter que WADL n’ait pas mieux adressé que WSDL des problèmes aussi important que le versioning des services alors qu’un projet comme Apache Thrift a su être innovant sur le sujet.

La soumission de WADL au W3C n’implique donc pas forcément son succès à venir. La disponibilité en masse d’outils et de frameworks permettant de gérer ce format pourrait en revanche attirer une partie des adeptes de SOAP.

Le coin de la technique

Play! Framework 1.0

The Server Side nous annonce la sortie de Play! Framework en version 1.0.

Play! est un framework web de haute productivité (tout comme Grails ou Spring Roo) qui simplifie la création et le développement d’applications Web en langage Java. Ce framework full stack inclut tout une batterie de composants tels que Groovy (pour le templating), Apache Mina mais aussi Hibernate. Quant à l’architecture de vos projets Play!, elle sera de type RESTful.

Cette vidéo nous donne un bon aperçu du produit, surtout en ce qui concerne le fameux Fix the bug and hit reload ! c’est à dire pas de compilation, de déploiement ou de redémarrage serveur suite à la modification de vos classes Java, juste un rafraîchissement de votre navigateur pour voir vos modifications.

A noter que l’équipe travaille déjà sur la version 1.1 et, entre autres, sur le support de Scala

Pour les liens utiles, la documentation complète du produit se trouve sur cette page. Le téléchargement se passe par ici. Et, comme le rappelle TSS, n’oubliez pas la présentation Play! framework in practice à Devoxx, en tous cas nous y serons !

Mise à jour de VisualVM en 1.2

8 mois après la sortie de la version 1.1, l’équipe nous gratifie d’une nouvelle version de son outil de monitoring de JVM. Avec un passage de 1.1.1 à 1.2, il ne faut pas s’attendre à de grandes révolutions. Une liste de 31 bugs corrigés, suivie de quelques nouvelles fonctionnalités notables:

  • Un sampling profiler CPU et mémoire
  • Support de plusieurs instances de JStatd
  • Amélioration de l’API de génération de graphes
  • Sauvegarde d’un snapshot de l’application dans un fichier nps pouvant-être utilisé plus tard pour analyse

Nous vous passons les améliorations de GUI et le support des proxys qui peut toujours s’avérer utile pour les analyses à distance. La vraie grande nouveauté c’est le plugin permettant de profiler l’application par sampling. Il ne faut pas s’attendre à la précision des outils instrumentant l’application comme JXInsight. Cependant, cela permettra une analyse assez poussée sans impact sur les performances.

Comment concevoir un datacenter, … par Google

Lors de la conférence Ladis 2009 (Large Scale Distributed Systems and Middleware), Jeff Dean, du groupe infrastructure chez Google, a présenté les manières de concevoir un système distribué.

Il passe en revue différentes problématiques :

  • Infrastructure
  • Stockage
  • Clustering
  • Échange de données sur le réseau
  • Communication entre applications
  • Construction d’application sur de telles infrastructures

Il est intéressant de voir les problématiques posées et les solutions proposées, sur des problématiques que nous avons trop tendance à oublier en tant que développeurs. Citons entre autres :

  • Latence réseau : un critère important, car difficile à optimiser
  • Bande passante du réseau
  • Capacité de stockage (mémoire et disque)

Il est donc très important même pour un développeur d’avoir ces chiffres en tête.

Par retour d’expérience, Jeff Dean montre les joies d’interagir avec du matériel physique. Les applications ne doivent pas supposer que le matériel est infaillible, il y a différentes erreurs que nos applications doivent gérer. Quand on voit les nombres d’occurrences de ce type de problème et leur nature, leur gestion par l’application n’est pas aussi triviale qu’il y parait :

  • Problème DNS
  • Plantage de serveur
  • Perte de connections

Cette présentation est très riche, et elle permet de voir les tenants et aboutissants d’une bonne infrastructure mais aussi les impacts que cela peut avoir dans nos développements de tous les jours.

Les contraintes que s’est imposé Google en terme de disponibilité, dimensionnement, … ont amené plusieurs innovations technologiques en terme d’infrastructure qui ont des impacts sur le développement applicatif :

  • Protocol Buffer
  • MapReduce
  • Google File System
  • Big Table

Les lecteurs intéressés par les innovations mises en place par Google sur ses infrastructures noteront que Gregor Hohpe (auteur de Enterprise Integration Patterns) présentera à Devoxx une session Distributed Programming the Google Way.

Ca bouge dans la communauté Groovy/Grails

Pour commencer, on peut noter la longue présentation de Grails faite par Graeme Rocher sur InfoQ. Le « papa » de Grails revient sur de nombreux points relatifs à ce très bon framework permettant de créer des applications web rapidement en bénéficiant de la puissance de Java, Groovy, Hibernate, Spring…

Ensuite, et c’est la rançon du succès, il y a beaucoup de discussions et d’interrogations autour des besoins auxquels répondent Groovy et Grails. Sur son blog, Peter Delahunty précise par exemple que, pour lui, Grails n’est l’arme absolue que si on a une bonne connaissance des technologies sous-jacentes (Spring, Hibernate…). Il ne faut pas débuter par Grails sans s’attendre à bloquer sur des problèmes relatifs à ces technologies.

Cet article va dans le même sens et rappelle qu’à partir du moment où l’on parle de « la magie Groovy » il faut être conscient que des choses qui n’ont rien de magique (cela reste du code !) se passent. Les « dynamic finders », le MOP (Meta Object Protocol) et la magie des closures font rêver mais s’expliquent bel et bien ! Ensuite, il y est noté que la proximité de Groovy et Java fait que de nombreuses personnes pensent que l’on peut passer de Java à Groovy sans formation particulière. Si l’on ne comprend pas les principes de ces choses magiques et que l’on se contente de les accepter comme tels, on s’expose tôt ou tard à des retours de flamme sévères qui se matérialisent généralement sous la forme de StackTraces incompréhensibles. Enfin, le manque de support professionnel pour Groovy/Grails est évoqué. Sur ce point, je pense que l’auteur se trompe. On note en effet que Springsource semble fournir un support commercial pour ces technologies. Mais, il y a peu, Groovy et Grails n’étaient pas encore dans le giron de Springsource et l’on devait « se contenter » du support de la communauté. Néanmoins, celui-ci a toujours été assez réactif et de bon niveau.

Toujours concernant Groovy, on peut noter la version Community Edition de l’IDE IntelliJ, tout récemment publiée, semble bien lotie au niveau du support de ce langage. Malheureusement, le support de Grails, lui, n’est pas présent dans cette version.

Votre application web est elle vulnérable ?

Le Web Application Security Consortium (WASC) estime que 87% des applications de la toile sont vulnérables. Tout le monde ne peut pas s’offrir les services d’un expert en sécurité, et un développeur ne peut pas écrire du code sécurisé s’il ne connaît ou ne comprends pas les risques auxquels il s’expose. C’est pour cette raison que DeveloperWorks revient sur les principales failles de sécurité qui nous guettent, et quelques outils simples pour analyser notre code.
Les points de faiblesse les plus connus sont :

  • le cross site scripting : le pirate injecte, via un autre site (de type forum par exemple), un script (de type javascript) vers le site visé. Ce script lui permet de récupérer des informations de connexion, des cookies…
  • l’injection de SQL : le pirate saisit du code SQL dans un formulaire web. Celui-ci est poussé jusqu’à la base, exécuté et donne (le plus souvent) accès à la base ‘en direct’ au pirate (l’un des exemples le plus connus est l’injection de OR 1=1- dans un formulaire d’authentification, qui retourne alors toujours TRUE).

Et l’on reparle de l’OWASP, qui propose un outil open source pour détecter ces erreurs de conception : WebScarab. WebScarab s’utilise comme un proxy HTTP (qui se place entre votre browser et votre serveur d’applications, par simple redirection des ports). Ensuite, un simple fichier .txt permet d’injecter votre site avec quelques-uns des plus célèbres cas de cross site scripting ou d’injection SQL. Un autre outil open source est présenté, d’un fonctionnement similaire, Paros Proxy.
Reste ensuite à détecter les faux positifs, opération généralement manuelle.

On notera que la section Ressources de l’article original est richement fournie, et permet de réellement comprendre les risques auxquels sont exposées les applications accessibles sur internet.

Saurez-vous trouver les failles du site de test Webgoat ?

Artifactory : évolutions et mode SaaS

Artifactory est un repository Maven dont la principale particularité est de s’appuyer sur Java Content Repository (JCR) pour assurer le stockage des artefacts. Le choix de JCR plutôt qu’un simple système de fichiers n’avait pas fait l’unanimité car il rend les tâches courantes d’administration plus délicates. En effet, lorsque l’on veut supprimer, remplacer ou déplacer un ensemble d’artefacts, l’action est triviale lorsque le système de fichier est utilisé alors qu’elle devient plus complexe avec JCR, qui n’est pas aussi directement manipulable.

Conscient de ce problème JFrog, l’éditeur derrière Artifactory, a peu à peu intégré un certain nombre de fonctionnalités permettant d’effectuer ces tâches courantes d’administration des artefacts directement depuis l’interface Web. Ainsi, la dernière version du projet permet même le déplacement d’artefacts entre plusieurs repository.

Début septembre, JFrog a également lancé ArtifactoryOnline, un service d’hébergement de repository Maven Artifactory en mode SaaS (Software as a Service). Ce type d’offre répond clairement à un besoin puisque la présence d’un repository Maven est souhaitable pour de nombreux cas d’utilisation et que cette infrastructure nécessite du temps et du matériel dont ne disposent pas toujours les équipes de taille réduite.

Par ces innovations, le repository Maven de JFrog saura sûrement séduire les utilisateurs déçus par les solutions concurrentes que sont Nexus et Archiva.

Article mis à jour le 26/10/2009 à 21h25

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

5 réponses pour " Revue de Presse Xebia "

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

    Un document accepté en tant que Submission n’a pas vocation à devenir une Recommendation (cf. http://www.w3.org/2005/10/Process-20051014/submission#Submission ). Un tel document permet de faire profiter la communauté d’une technologie développée par un des membres du W3C, dont Sun fait partie.

    Si l’équipe du W3C est intéressée, elle peut juger utile de lancer un groupe de travail sur le sujet. On rentre alors dans un tout autre processus (cf. http://www.w3.org/2005/10/Process-20051014/tr.html#Reports ).

    Dans le cas présent (et pour le moment), le W3C n’a pas décidé de poursuivre ce travail (cf. http://www.w3.org/Submission/2009/03/Comment#next_steps ).

    Alexandre Bertails, W3C.

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

    Petite correction, c’est « MapReduce » au lieu de ReduceMap.
    La déclinaison open source du MapReduce étant Hadoop http://hadoop.apache.org.

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

    @Alexandre : Merci pour ces précisions sur le fonctionnement du W3C, et sur le statut actuel de la spécification WADL. Nous adaptons notre article en tenant compte de cette nuance.

    @Franck : Merci également. En effet, il fallait bien entendu lire MapReduce. Notons par ailleurs qu’Hadoop est soutenu par Yahoo!, Google n’ayant pas diffusé l’implémentation qu’ils utilisent en interne.

    Michael Figuière (Xebia)

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

    A propos de Play!, un petit cocoricoooo : c’est des français :)

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

    « c’est des français » -> ce sont des français! C’est du français…
    ok vite vite je vais play-er… –>[]

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.