Article publié par Guillaume Arnaud le 2 décembre 2011.
Catégorie(s) : Architecture
Article publié par Guillaume Arnaud le 2 décembre 2011.
Catégorie(s) : Architecture
Article publié par Yves Amsellem le 14 novembre 2011.
Catégorie(s) : Architecture
Voilà 11 ans que Roy Fielding a introduit REST, le style d’architecture original du web appliqué aux échanges inter-applications. Reposant sur HTTP, il promet économie, simplicité et profit des structures réseau en place. Voyons comment l’implémenter via un client JavaScript — présenté ici — communiquant avec un serveur Java — présenté dans un article connexe –. Le code clé-en-main est disponible sur GitHub.





Le client JavaScript que nous allons déployer repose sur jQuery — un framework de haute productivité —, nous lui adjoindrons BackboneJS, un framework MVC REST, et RequireJS, un chargeur de modules à la demande.
Article publié par Yves Amsellem le 14 novembre 2011.
Catégorie(s) : Architecture
Voilà 11 ans que Roy Fielding a introduit REST, le style d’architecture original du web appliqué aux échanges inter-applications. Reposant sur HTTP, il promet économie, simplicité et profit des structures réseau en place. Voyons comment l’implémenter via un client JavaScript — présenté dans un article connexe — communiquant avec un serveur Java — présenté ici –. Le code clé-en-main est disponible sur GitHub.
JAX-RS — Java API for RESTful Web Services — standardise l’implémentation de REST en Java (une API + une servlet). Nous retiendrons son implémentation de référence, Jersey, et la déploierons sur un serveur Jetty-Embedded (le code clé-en-main dispose d’un main effectuant le déploiement ; pas besoin d’installer de serveur).
Les web services REST sont des ressources. Une ressource est identifiée par un nom du domaine, produit, commande, etc. HTTP définit 7 verbes pour manipuler les ressources :
Une fois déployée, la servlet Jersey mappe l’url /resource/* ; la partie cliente est disponible sur /index.html. Le web.xml définit deux filtres Jersey afin de loguer les trames HTTP des échanges client-serveur.
Article publié par Yves Amsellem le 17 mars 2011.
Catégorie(s) : Architecture, Java / JEE
Format privilégié pour les échanges inter-applications, XML est l’objet de nombreuses bibliothèques Java. Cependant, ces bibliothèques masquent toutes le data binding qu’elles effectuent ; la transformation d’un document XML en grappe d’objets. Nous voilà bien démunis dès lors qu’une application produit du XML comme une simple chaîne de caractères. L’utilisation d’API bas niveau (DOM, XPath) — attachées à la structure du document — se révélant fastidieuse, la majorité des implémentations JAX-RS (Jersey, CXF) ont retenu la même API de haut niveau — concentrée sur les données — : JAXB. Faisons de même.
Article publié par Alexis Kinsella le 13 octobre 2010.
Catégorie(s) : Architecture, Java / JEE
Nous avons vu dans un premier article comment initier le développement d’un composant Apache Camel, puis dans un second comment implémenter ses différentes classes.
A ce stade de notre développement nous sommes déjà en mesure d’utiliser pleinement notre composant, mais nous ne pouvons pas encore en assurer sa qualité. Pour cela, il est nécessaire d’ajouter à notre composant différentes classes de test. Bien que la testabilité de frameworks d’intégration puisse parfois paraître difficile, le projet Apache Camel fournit tous les outils nécessaires permettant de répondre à ce besoin. Nous verrons donc dans cet article comment tester le composant que nous avons développé.
Pour finir, nous verrons comment intégrer notre développement à un projet Camel, ainsi que les limites de notre composant et les solutions pour résoudre ces limitations.
Article publié par Alexis Kinsella le 6 octobre 2010.
Catégorie(s) : Architecture, Java / JEE
Nous avons vu dans un premier article comment initier le développement d’un composant Apache Camel. Cependant, nous n’avons pas encore abordé son développement à proprement parler et notre composant ne permet pas encore de communiquer avec les serveurs Apple. Nous allons donc voir dans cet article comment implémenter les différentes classes nécessaires au bon fonctionnement de notre composant.
Pour rappel l’objectif est de développer un composant capable de communiquer avec l’Apple Push Notification Service, qui permet d’envoyer des notifications aux appareils mobiles d’Apple (iPad, iPhone, iPod Touch).
Article publié par Alexis Kinsella le 30 septembre 2010.
Catégorie(s) : Architecture, Java / JEE
Le projet Apache Camel est un framework d’intégration basé sur l’implémentation de patterns d’intégration d’entreprise connus. Il permet d’implémenter des règles de routage et de médiation à partir d’un DSL Java ou bien via des configurations Spring au format Xml.
Apache Camel utilise la notion d’URIs, ce qui permet de travailler facilement avec différents types de transport ou modèles d’échange de messages, tels que HTTP ou JMS. De la même manière, Apache Camel est capable de travailler avec différents formats de données (Csv, Xml, Json, …).
L’utilisation des composants fournis out of the box permet de travailler avec de nombreux protocoles et formats de données. Mais qu’en est-il lorsqu’un connecteur vient à manquer?
Pour répondre à cette question, le projet Apache Camel propose une API complète permettant d’implémenter soi-même des composants adaptés à son besoin.
Article publié par Mohamed-Hamza Benmansour le 2 septembre 2010.
Catégorie(s) : Architecture
La vie terrestre des ESB, aura été courte. À peine compris et apprivoisés, les voilà qui s’envolent vers d’autres cieux. En effet, depuis quelque temps, on commence à percevoir les premières initiatives d’ESB dans les nuages comme celle de la firme WSO2 avec sa plateforme Stratos ou encore celle de Savoir technologies, dans le milieu hospitalier, où la mise en place d’un ESB dans les nuages a facilité les échanges des données des patients entre les différents départements.
Dans la suite de ce billet, nous allons essayer d’analyser cette tendance émergente en revenant brièvement sur :
Article publié par Christophe Heubès le 25 juin 2010.
Catégorie(s) : Architecture
Le modèle de maturité de Richardson (Richardson Maturity Model) est un modèle qui décompose l’approche REST en trois étapes qui introduisent progressivement les principaux éléments de REST (Ressources ; Verbes et Codes retours HTTP ; Contrôles hypermédia) pour passer d’un modèle RPC sur HTTP à un modèle RESTFul.
Ce modèle a été développé par Léonard Richardson. Léonard Richardson est, entre autres, co-auteur du livre « Restful Web Service » publié chez O’Reilly.
Martin Fowler a récemment publié un papier à propos du Modèle de Maturité de Richardson intitulé « Richardson Maturity Model: steps toward the glory of REST ». Dans ce papier, Martin Fowler déroule et commente le Richardson Maturity Model au travers d’un cas d’utilisation simple (réserver un rendez-vous chez le médecin).
Ce billet présente le Richardson Maturity Model en s’appuyant en grande partie sur le papier de Martin Fowler. Au programme :
Article publié par Xebia France le 24 février 2010.
Catégorie(s) : Architecture, Exploitation, Java / JEE, Méthodes agiles, Performance, WOA

Nous sommes heureux de vous proposer le nouveau catalogue de formation Xebia Traning :
Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.
Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.
Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.