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

Le coin de la technique

Actualité éditeurs / SSII

Eclipse Ganymède

La nouvelle livraison de la fondation Eclipse sera disponible le 25 juin. Cet article d’ IBM DeveloperWorks passe en revue l’ensemble des sous projets qui constitue cette nouvelle mouture.

Le coin de la technique

JAX-RS : Java standardise son API REST

Marc Hadley et Paul Sandoz, les specs leaders de JAX-RS, ont présenté à JavaOne 2008 dans JAX-RS: The Java API for RESTful Web Services les enjeux de l’API REST en Java dont la version 1.0 est prévue pour Septembre 2008.

Nous retiendrons:

REST en cinq étapes :

  1. Donner un ID sous forme d’URL à chaque donnée (ex. : <client id="http://example.com/client/my-company"><name>my company</name>...</client>).
  2. Lier les données ensembles (ex. : <product-order><client ref="http://example.com/client/my-company"/>...</product-order>).
  3. Utiliser les méthodes HTTP standard (GET pour la lecture, PUT pour l’écriture avec ID, POST pour l’écriture sans ID, DELETE).
  4. Représenter les données sous plusieurs formats (XML, JSON, HTML souvent déterminé selon le champ Accept de la requête HTTP).
  5. Communications ‘stateless’

Example de code JAX-RS :

@Path("orders/{order_id}")
public class OrderResource {
   @GET
   @ProduceMime({"application/xml","application/json"})
   Order getOrder(@PathParam("order_id") String id) {
   ...
   }
}

Les principales implémentations JAX-RS :
Restlet, JBoss RESTEasy, Apache CXF, Glassfish Jersey.

Sortie de la JSR286 – Version 2 de l’API Portlet Java

Cette nouvelle version apporte le support des événements (une portlet peut envoyer ou recevoir des évènements), une gestion des paramètres publics pouvant être partagée entre différentes portlets (Public parameter renderer), le « resource serving » pour qu’une portlet puisse donner accès à une ressource, et pour finir le « portlet filter » qui permettra de faire des transformations en entrée ou sortie de la portlet.
JSR-000286 Portlet Specification 2.0

Le top 10 des fonctionnalités de Hudson

On a déjà parlé de Hudson a plusieurs reprises, toujours en bien, et on en rajoute une couche, avec ce post d’Arun Gupta (Technology Evangelist chez Sun), qui nous donne son top 10 des meilleures fonctionnalités de Hudson:

  1. Facilité d’installation et d’utilisation – Hudson est un simple WAR à déployer
  2. Vaste écosystème de pluginsvoir la liste des plugins les plus téléchargés depuis la mise en place du centre de téléchargements de plugins dans Hudson 1.222
  3. Support du build distribué – la mise en place d’un build distribué est simple, un serveur maître gère les esclaves, et leur distribue les builds automatiquement. On se connecte à l’interface du maître et le mode distribué est transparent, l’interface est la même que si les builds sont effectués sur le serveur maître
  4. Support du build inter-équipes – les dépendances entre projets compilés par Hudson sont correctement gérées, avec un système de « chaînage » des builds. On peut également aisément garder la trace des versions utilisées grâce au Finger printing
  5. Open Source – Hudson est entièrement Open Source, sous licence MIT
  6. Maturité – au 23 Juin 2008, Hudson en est à la 227ème release
  7. Existence de nombreux outils pour Hudson en dehors de Hudson – l’API de contrôle d’Hudson a permis l’apparition d’outils tiers, comme par exemple un plugin pour Firefox ou une icône de notification dans la barre des tâches sous Windows ou MacOS.
  8. Support des liens permalink – Hudson expose des URLs simples pour certaines pages, comme les pages « dernier build réussi » ou « historique des temps de build »
  9. Internationalisation – Hudson est disponible en Anglais, Japonais, Allemand, Français (grâce au travail d’Eric Lefevre, Turque, Brésilien, Portugais et Russe. Un guide d’internationalisation est disponible.
  10. API d’utilitaires développés pour Hudson – peuvent être utilisés sur d’autres projets

Nous utilisons Hudson chez nos clients sur de nombreux projets, l’outil est tellement simple et efficace qu’il nous est maintenant difficile de nous en passer!

Dave Syer revient sur SpringBatch pour InfoQ

Le leader du projet SpringBatch , David Syer , expose sur InfoQ les principales fonctionnalités offertes par le framework. Comme pour l’ensemble du projet Spring, le but avoué est d’aider le développeur à se consacrer à la logique métier de son application, en délégant au maximum les taches sans valeurs ajoutées au framework.
Les principaux cas d’utilisation de SpringBatch sont les suivants :

  • Traitements business : reporting, traitement de commandes, réconciliation de comptes…
  • Gestion d’import /export : traitement de formulaires, rapports d’inventaire…
  • Emissions à grande échelle : campagne d’emailing, états financier…

Les principales fonctionnalités de SpringBatch

  • Une infrastructure de bas niveau, réutilisable, offrant la gestion des répétitions et des ‘retry’, la synchronisation des transactions, la lecture / écriture en fichiers plats, en XML ou en base de données.
  • Un noyau (Core) sous forme d’API légère qui permet le lancement et la gestion des batchs, et fourni tous les outils pour la gestion opérationnelle de ceux ci.
  • Un environnement d’exécution (implémentation de l’API Core)
  • Un ensemble d’applications d’exemple déclinant toutes les fonctionnalités offertes par SpringBatch
runtimedependencies.png

David Syer revient également sur la collaboration fructueuse entre la fondation Spring et Accenture sur ce projet, qui a permis d’augmenter la quantité et la qualité des contributions sur le code source.

A noter que David Syers donnera une télé-conférence sur l’utilisation de SpringBatch le 9 juillet .

L’intégralité de l’article sur InfoQ .

Sécurité des applications web : les lignes de front bougent

Jeremiah Grossman, Whitehat, et Joe Walker, Sitepen ont présenté à JavaOne 2008 dans Advanced Web Application Security les évolutions des menaces qui pèsent sur les applications web avec l’émergence des Cross Site Request Forgery* (CSRF) et JavaScript Hijacking qui s’ajoutent au bien connu Cross Site Scripting (XSS).

Cross Site Request Forgery (CSRF)

  • Description : un attaquant insère dans une page web une URL (<img />, <iframe />, etc) vers un site applicatif auquel l’internaute a l’habitude de se connecter. Il n’est même pas nécessaire d’injecter ce code malicieux sur le site agressé ; il suffit que la page web ‘crackée’ soit affichée dans le browser.
  • Exemple : insertion d’un tag image <img src="https://ma-banque.com/virement?montant=666&beneficiaire=un-mechant-attaquant" />
  • Protection : OWASP CSRF Guard

JavaScript Hijacking

  • Description : le langage JavaScript permet de redéfinir la plupart des comportements, notamment les constructeurs, les getters et les setters. Il suffit de redéfinir le comportement d’un accès Ajax pour intercepter et modifier les contenus entrants et sortants.
  • Exemple : redéfinition du constructeur et d’un setter
function Object() {
  alert("Hello, World");
  this.__defineSetter__('foo', function(x) {  alert(x); } );
}
  • Protections : utiliser un framework Ajax qui prévient cette faille (DWR 2.2 le fait déjà, les autres y travaillent), lire des documents de référence tels que JavaScript Hijacking par Brian Chess, Yekaterina Tsipenyuk O’Neil et Jacob West.

Cross Site Scripting (XSS)

  • Description : Problème maintenant bien connu mais toujours aussi dangereux d’injection de javascript dans des pages web.
  • Exemple : saisie d’une valeur malicieuse dans un champ de formulaire telle que Joe<script src="http://evil.com/danger.js" />
  • Protections : Restreindre les données en entrée, escaper les données affichées et fixer l’encodage des pages.

 

Billets sur le même thème :

4 Responses

  • A propos de REST

    Je suis un peu sceptique par rapport à JAX-RS. Tout d’abord il est évident que JAX-RS sera difficilement utilisable autrement que par un IDE générant automatiquement le code. Pourquoi pas, Netbeans est excellent.

    Cependant cela s’ajoutera sans doute à du code déjà généré par cette méthode : http://youtube.com/watch?v=cDdfVMro99s ce qui commence à faire beaucoup.

    REST a selon moi l’avantage de produire un code immédiatement lisible, contrairement à SOAP. La génération de code s’oppose aussi dans la pratique au « Reduce Coupling ».

    ———–

    Dans les points à retenir, je mettrais surtout :
    – Addressabilité et Connectivité (grâce aux URI) – cela aide au bon référencement
    – Scalabilité : pas de session = plus facile de diriger des requêtes vers des serveurs multiples.

    ——-

    Je ne vois pas trop l’intérêt d’annotations telles que @ProduceMime pour un effet qui peut s’écrire en une migne de code. On peut utiliser un Pattern Strategie qui fera très bien le boulot, voire juste un attribut static.

    On sent la volonté de mettre tout ce qui est possible dans REST de façon théorisé est englobée – ie emprisonnée – dans l’api. Je rejoins les propos du blog « abstract – final  » : Do we need frameworks for REST ? : http://abstractfinal.blogspot.com/2007/04/do-we-need-frameworks-for-rest.html

    Cordialement :)
    Nicolas Zozol
    http://nicolas-zozol.developpez.com/tutoriels/java/restful/jsp/

  • Bonjour Nicolas,

    Je comprends votre inquiétude sur le foisonnement des frameworks et des standards pour supporter des techniques qui finalement n’ont rien besoin de plus que ce que nous avons sous la main.

    Cependant, je suis optimiste en voyant les efforts de mutualisation entre les API JAX-RS et Servlet 3. Je vois une grande simplification avec les annotations de déclaration de méthodes http (@GET, @Path, @QueryParam, @PathParam, etc) et j’espère même que ces annotations amorcent l’unification des action based web frameworks (Struts, Spring MVC, etc).

    Je trouve la syntaxe ci-dessous très séduisante :

    @GET @Path("/employees/{id}/")
    public Employee getEmployee(@PathParam("id") int id) { ... }

    Par ailleurs, j’attends d’un framework JAX-RS qu’il m’offre en plus de ce que j’ai actuellement :
    - des serializers vers les formats qui plaisent aux consommateurs de mes services (XML pour java et .Net, JSON pour javascript, AMF pour flash, YAML pour Ruby, CSV, etc)
    - le mécanisme pour lier mes entités entre elles par des hyperliens (cf. CXF Sub Resource Locators)

    Pour ce qui est des annotations @ProduceMime, @ConsumeMime, etc. ; elles me semblent utiles seulement dans les cas très limités de restriction du nombre de format de réponse accepté (e.g. seulement xml) et ne seront donc utilisés que rarement.

    Cyrille (Xebia)

Laisser un commentaire