Nos DSI pensaient avoir passé un cap en mettant en place des infrastructures de site web client, boutique en ligne, support… Ca a été difficile, notamment pour rendre disponible sur des applications Internet des services de coeur de SI, qui n’avaient pas du tout été conçus dans cette logique, mais au moins on espérait en avoir fini avec les remises en cause.

Et bien non: les tablettes tactiles arrivent, iPad, tablettes Android, etc., y compris en B2B, et elles vont changer certains des métiers, dont la vente et la distribution. Et comme les applications Internet, elles vont poser de nouvelles difficultés en nécessitant un accès selon de nouvelles modalités à des services parfois (souvent) profondément enfouis dans nos systèmes d’information.

(Lire la suite…)

L’architecture SCA (Service Component Architecture) reste une initiative démocratisée relativement récemment même si la version 1.0 a été publiée il y a plus de deux ans maintenant. L’annonce d’Oracle Fusion 11G a récemment rappelé son support par différents grands éditeurs. Il n’en reste pas moins que son périmètre d’utilisation n’est pas forcément évident, d’autant plus qu’il s’agit d’un des nombreux sigles associés à SOA : WS-*, BPEL, JBI, SDO… Nous allons tâcher au sein de cet article de clarifier les potentialités de cette norme et de proposer des contextes qui me semblent propices pour en tirer profit.

(Lire la suite…)

Mr Jourdain fait de la prose ou des vers sans qu’il n’en sût rien. Bon, nous le savons depuis la 5e ! Et comme Molière avait le don d’écrire des universalités humaines et intemporelles, il est certain qu’aujourd’hui autour de nous et dans bien des domaines il y a des Mr Jourdain qui s’ignorent. Projetons donc ce monsieur Jourdain dans l’IT de 2009. Quelle pourrait être la chose qu’il fît depuis pas mal de temps sans qu’il n’en sût rien. Ne serait ce pas de la SOA par hasard ? Reprenons une définition communément rencontrée d’un service. Je cite rapidement et pour l’essentiel :

• Standardisation : Les services exposés respectent les mêmes règles de standardisation.
• Couplage lâche : Le contrat de service impose un couplage lâche vis-à-vis de ses clients
• Autonomie : Le service est autonome car il ne fait pas appel à aucun autre système tiers. Il n’en n’est pas dépendant. Ce qui par ailleurs le rend prédictible.
• Abstraction : Le contrat de service n’expose que les informations essentielles à son invocation.
• Composition : Le service peut participer à une composition d’appel de services.
• Sans état : Le service ne conserve aucun état (résultats d’exécution ou autres).

(Lire la suite…)

Cet article est le deuxième d’une série de 3 articles traitant de la stratégie de test d’une architecture REST. Il fait suite au billet sur le test unitaire d’une ressource REST. Pour rappel nous allons, par l’exemple, mettre en pace une stratégie de test sur un code d’exposition de web services REST en Java. L’exemple de code se basera sur le framework REST Jersey, implémentation de référence de Sun de la JSR-311 déjà présentée dans un précédent article . Le but de ces trois articles est de présenter un harnais de tests pouvant couvrir la mise en place de Web services REST. Ce deuxième article s’attardera sur les tests d’intégration tandis qu’un prochain article traitera des tests de recette.
(Lire la suite…)

Cet article est le premier d’une série de 3 articles traitant de la stratégie de test d’une architecture REST. Il fait suite au billet sur les types de test utilisés sur un projet Agile. Par l’exemple, nous allons mettre en place une stratégie de tests sur un code d’exposition de web services REST en Java. L’exemple de code se basera sur le framework REST Jersey, RI de Sun de la JSR-311 déjà présenté dans un précédent article. Le but de ces trois articles est de présenter un harnais de tests pouvant couvrir la mise en place de Web services REST. Ce premier article s’attardera sur les tests unitaires tandis que les suivants étudieront les tests d’intégration puis les tests de recette.

(Lire la suite…)

Trop souvent les démarches SOA adressent uniquement les problématiques d’architectures techniques et fonctionnelles, au dépend des enjeux humains et organisationnels inhérents à la transformation qu’impose la SOA au SI.

(Lire la suite…)

La JSR 311 JAX-RS [Java^TM API for RESTful Web Services] est le pendant REST de la JSR 224 JAX-WS [Java^TM API for XML-Based Web Service]. Elle marque la volonté de la part de la communauté Java de cadrer, tout comme pour la stack WS-*, le développement des applications JAVA orientées ressources. Bien qu’étant sur le point d’être finalisée (dernier stade : Final Approval Ballot), elle est déjà implémentée par la plupart des frameworks REST du moment (Jersey, RESTeasy, CXF, une extension Restlet…).

La suite de ce billet présente les annotations de la JSR en regard des principes REST qu’elles mettent en œuvre.

(Lire la suite…)