Par Marc Bojoly, le 24 août 2009 |
Catégorie:
L'Atelier de l'architecte |
Pas de commentaires |
Imprimer
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…)
Par Sylvain Fagnent, le 25 mars 2009 |
Catégorie:
Chronique |
1 commentaire |
Imprimer
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…)
Par Benoit Guillou, le 24 février 2009 |
Catégorie:
L'Atelier de l'architecte |
Pas de commentaires |
Imprimer
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…)
Par Benoit Guillou, le 17 février 2009 |
Catégorie:
L'Atelier de l'architecte |
1 commentaire |
Imprimer
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…)
Par Olivier Mallassi, le 21 novembre 2008 |
Catégorie:
Management et méthodologies |
2 commentaires |
Imprimer
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…)
Par Benoit Guillou, le 27 septembre 2008 |
Catégorie:
L'Atelier de l'architecte |
3 commentaires |
Imprimer
La JSR 311 JAX-RS [JavaTM API for RESTful Web Services] est le pendant REST de la JSR 224 JAX-WS [JavaTM 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…)