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.

Pourquoi?

Partons d’une autre question: Pourquoi les applications iPhone sont-elle majoritairement agréables à utiliser et ont-elles contribué notablement au succès de ces smartphones?

Si je peux avancer une réponse, ce serait parce qu’elles partagent une charte ergonomique stricte et qu’elles sont construite autour de certains modes d’interaction. Ces modes d’interaction sont intuitifs, mais limités, et les applications sont conçues autour de cette limite. Elles sont également conçues autour des cas d’utilisation spécifiques les plus courants: les use cases d’un smartphone sont différents de ceux d’un PC. On va par exemple utiliser un PC pour réserver un billet d’avion, alors que le smartphone va permettre de s’enquérir des horaires, des retards et de s’enregistrer.

La même dichotomie se retrouve sur les tablettes tactiles vs les applications pour PC, même sur des applications d’entreprise. Imaginons un système de vente, permettant de réaliser une souscription de téléphonie mobile, un upgrade de forfait, un changement de mobile… Le cas d’usage de l’application sur PC est celui d’un opérateur en centre d’appel ou en agence, qui a déjà réalisé le dialogue avec son client et passe à la phase administrative, assis à son poste, alors que le client attend. La phase intense d’échange avec le client est plus ou moins terminée, les choix sont faits.

La même application sur tablette aura une autre orientation: elle va pouvoir être utilisée dès le début de la vente, alors que les choix ne sont pas réalisés. Le vendeur est en proximité physique avec le client, il dialogue avec lui et la tablette est une aide pour ce dialogue, y compris pour le client lui-même qui la voit et interagit avec. Le vendeur peut comparer des terminaux, tester la couverture, montrer des options, choisir des offres… Il n’est pas concentré sur son interaction avec son ordinateur, mais sur celle avec son client.

Du coup, il apparaît que l’application qui justifie d’introduire une tablette tactile en distribution ne peut pas être un simple portage technique, mais demande une réécriture avec une logique d’interaction différente. Reformater les écrans d’une application Web ou d’un portail donnant accès à plusieurs applications conçues pour un PC ne suffit pas. Il faut tout repenser en partant des cas d’utilisation les plus importants, en utilisant la grammaire d’interactions de la tablette et en veillant à ne pas détourner l’utilisateur du dialogue avec son client. Ceci implique alors d’accéder aux données et aux services du système d’information d’une manière différente des application traditionnelles, parce que la logique différente de l’application tablette et les contraintes techniques de la tablette impliquent des services et modalités d’accès nouveaux.

Alors, que faire?

Nous pouvons nous inspirer des démarches mises en oeuvre pour créer des applications Internet. On considère les applications Internet comme mouvantes, multiples, parfois jetables, parfois même non issues de l’entreprise mais réalisées par des tiers. Elles doivent pouvoir être réalisées rapidement avec une expertise spécifique, mais sans devoir à chaque fois affronter la complexité du système d’information et sa dette technique.

Pour ce faire, on mettait en place des couches de services spécifiques, isolant cette galaxie d’applications légères et agiles de la complexité du coeur de système d’information. Je propose de suivre une même démarche pour les applications tablettes, en mettant en place une couche de services adaptés à leurs besoins spécifiques, intégrant des services métiers, et peut-être des services techniques partagés.

En plus des cas d’utilisation spécifiques, quelles contraintes techniques nouvelles? Nous pouvons citer:

• des protocoles légers (REST / JSON par exemple), parce que la bande passante et la capacité de traitement du terminal « tablette » sont plus limitées que sur un PC;
• un écran = un service, parce que la fluidité de l’interaction est primordiale, et que la capacité du terminal est limitée;
• des données simples, parce que l’utilisateur doit rapidement s’y retrouver et que le terminal tablette ne doit pas avoir à réaliser de conversion de données complexes (pas de modèle pivot trop riche!).

Comment créer cette couche de service?

Ne pas la créer: la faire émerger. S’inspirer de l’excellente session de l’USI 2009 de mes camarades Benoît Guillou et Dominique Jocal. L’essence est d’utiliser deux patterns de définition de service:

• au départ, un service est créé pour une application, sans préoccupation de réutilisation. Il est défini par un contrat entre un client et un fournisseur, qui repose sur sa signature et le cas d’utilisation de ce client. On a un pattern « consumer contract », ou « contrat client », où on ne se préoccupe pas de réutilisation, seulement d’adéquation avec un besoin. On respecte néanmoins les bonnes pratiques d’implémentation des services (nommage, granularité, gestion d’états…) et de développement;
• lorsque des services similaires sont nécessaires pour plusieurs clients (au moins trois!), on peut envisager une mutualisation et mettre en place un pattern « consumer-driven contract ». Le contrat de service lie un fournisseur et plusieurs clients. Il repose sur la signature de service et la somme des cas d’utilisation par les clients.

Pourquoi ces patterns? Ils rendent les services facilement testables, et transparents d’utilisation. Le service respecte le contrat s’il passe une somme de tests d’utilisation. On favorise ainsi une approche de développement et de design reposant sur les tests, cruciale pour sécuriser un service qui doit être d’autant plus fiable qu’il est utilisé en plusieurs endroits, et donc susceptible de générer plus de perturbations s’il dysfonctionne.

En synthèse?

Les tablettes arrivent, préparons-nous à en tirer partie, pour la satisfaction de nos clients et de nos salariés. Elles nous offrent l’occasion de tirer partie des enseignements collectés sur les applications Internet pour accélérer le développement d’applications utiles, performantes et agréables. Elles vont enfin nous permettre de construire des infrastructures SOA pragmatiques, dans un modèle adaptable (possibilité de réagir rapidement par rapport aux besoins nouveaux) plutôt qu’adapté (couvrant parfaitement un besoin – réel ou théorique – tel que compris à un instant donné). Ne nous en privons pas!

Suggestion d'articles :

1. SCA, quel apport pour la SOA?

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.

Introduction à SCA

Cette norme est désormais portée par le consortium OASIS.
L’architecture SCA se base sur la notion de composants indépendants à la fois du langage et de la technologie. Son objectif est de standardiser la notion d’injection et d’interface pour tous les middlewares et tous les langages. Cela doit permettre d’écrire des composants en Java, C++, Cobol, BPEL etc. et de les interconnecter plus simplement qu’en combinant l’ensemble des technologies de web services nécessaires pour arriver au même résultat. Dans l’optique de cette norme, pour être efficace, une architecture SOA nécessite d’être implémentée à base de composants configurables. Les services web deviennent alors les interfaces de ces composants SCA. Ceux-ci comportent dans la terminologie de la norme :

• Des services, c’est à dire les interfaces exposées
• Des références, c’est à dire les interfaces d’autres services que ce composant consomme
• Des propriétés, qui permettent de le configurer

Composant SCA

.
SCA va de paire avec la norme Service Data Object qui vise à fournir un accès à toutes les sources de données pour tous les langages. SDO permet de définir un ensemble de données (un DataSet) que l’on peut extraire, modifier, échanger – par exemple entre composants SCA – et redonner à la source de données pour reporter les modifications.

Quelle limitation SCA permet de résoudre ?

Aujourd’hui en 2009, on cherche à l’intérieur d’une application à réutiliser du code par assemblage de classes, utilisation de frameworks. Les SI sont moins en silot que par le passé : différentes applications utilisent un service web que propose une application dépositaire d’une fonction partagée. Aujourd’hui cependant chaque application utilise un nombre modéré de services externes, réellement partagés avec d’autres applications.
L’objectif de SCA – faciliter la réutilisation des services en les combinant – trouve peu d’écho aujourd’hui ou le nombre de services utilisés reste modéré.

Alors existe-t-il des limitations que SCA permettrait de résoudre? Nous pensons que les difficultés d’assemblage de services, la complexité liés aux nombreuses normes SOA et de couplage au mode de transport peuvent nécessiter une réponse globale comme SCA si une application est réalisée majoritairement par assemblage de briques métier à forte granularité et développées par des équipes différentes. Lors de l’université du SI, le rendez-vous annuel des geeks et des boss organisé par Octo Technology, Jean-René Lyon a présenté au cours de sa session The times they are a changing la vision d’une informatique différente où les applications seraient construites à 80% à partir de fondations métier communes assemblées (à partir de 11 min. 30 dans la vidéo).
Dans l’optique d’une informatique basée ainsi sur la réutilisation massive de très nombreux composants métiers, des limitations pourraient apparaître au niveau de l’assemblage et SCA pourrait être une réponse unificatrice. Cependant, le développement informatique actuel ne fonctionne pas (encore ?) de cette façon.

Positionnement de SCA aujourd’hui

Aujourd’hui, le SI reste composé d’applications dialoguant entre elles via des services. L’application est homogène, développée par une seule équipe. Sa modularité interne doit rester souple, simple à mettre en oeuvre, car la priorité reste la livraison de l’application complète et non la réutilisation. Le framework Spring de par sa simplicité est devenu le standard de fait pour organiser la modularité à l’intérieur d’une application.
Le dialogue avec le monde extérieur, exposition et consommation de services partagés, écrits dans des technologies différentes, reste d’un autre domaine : celui de l’intégration. Le coût du dialogue avec les autres équipes (dans quel élément du WSDL se trouve la date valeur?), la coordination des cycles de vie (montée de version, compatibilité), les soucis de disponibilité dans le cas d’un service distant font que le SI n’est pas une agrégation homogène de composants mais plutôt une intégration de différentes applications. De très nombreuses solutions existent. Là encore SCA n’apporte rien de nouveau face à l’intégration par injection des piles web services comme CXF dans Spring.
Aujourd’hui SCA est mis en avant dans les solutions des éditeurs d’EAI ou d’ESB : cela structure ces produits et cela assied leur image de pérennité. Cependant dans la pratique deux EAI implémentant SCA comme Oracle Fusion Middleware ou Tibco ActiveMatrix ne peuvent pas échanger des composants SCA développés l’un avec l’autre. L’accès depuis l’un de ces produits à un composant SCA exposé par une application nécessitera un paramétrage équivalent à un appel de web service.
Aujourd’hui SCA apparaît plus comme un standard de plus dont la valeur ajoutée reste faible par rapport aux outils déjà en place.

SCA peut-il améliorer mon architecture SOA?

Aujourd’hui les problématiques techniques traitées par SCA sont bien connues et peuvent être gérées de différentes manières, SCA -étant l’une d’entre elle. Aboutir à une architecture de fondations telle que décrite par Jean René Lyon nécessite de résoudre d’autres enjeux primordiaux préalablement à une n ième standardisation de packaging

• réussir l’adaptabilité du composant: rendre paramétrable et extensible un composant fait appel à des techniques de design et de construction d’interface et d’implémentation interne spécifiques, qui plus est au niveau composant et non au niveau applicatif. On ne peut pas dire que les bonnes pratiques soient servies sur un plateau, on aurait aimé que SCA traite ce point là où les manques sont bien plus nombreux.
• la gestion des données : un composant contrat doit stocker des données. Chaque composant doit il créer un silo de données, charge à l’assemblage de coordonner les différents silos?
• la dynamique d’un projet multi-équipes : comment définir une représentation commune de deux métiers? SCA s’appuie sur XML ou sur les interfaces de langages objets maîtrisés depuis près de 10 ans. Les outils sont là mais la réalisation d’une interface de service reste un travail complexe

A mon sens, aujourd’hui, l’architecture SOA ne souffre pas de difficultés techniques mais avant tout de difficultés méthodologiques. Lorsque celles-ci seront levées petit à petit, la quantité de code réutilisé pourra croître. Si cela doit passer par une plus forte agrégation de services, ou par plus de paramétrage (évolution du service vers le composant), SCA pourrait avoir sa place mais la concurrence sera forte avec les technologies en place. Pour conclure nous vous donnerons trois références qui adressent ces difficultés méthodologiques

• La session une démarche pour réaliser des services durables qui aborde les difficultés méthodologiques de réaliser des services web dans un SI
• L’initiative du CEISAR qui réalise des publications sur l’architecture d’entreprise et dont la prochaine publication annoncée par Jean René Lyon dans sa session portera le thème des fondations d’entreprise

Par Dominique Jocal et Marc Bojoly

Suggestion d'articles :

1. OpenESB/Sun Java CAPS 6, quel avenir?
2. Spring-Batch : par quel bout le prendre ?
3. Un SI pour des tablettes (tactiles)

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).

Le formalisme posé, maintenant, prenons notre regard de béotien et cherchons qu’est ce que l’on pourrait appeler effectivement service. Décréter qu’un système (application ou pas) devient un service, décréter que l’on va mettre en place une architecture SOA, c’est tout à fait louable mais croyez vous que cela se décrète ? Imposer peut être, pendant un temps. Si le système répond aux attentes il deviendra service dans les faits sinon, il sera contourné et patatras, il tombera aux oubliettes. Et des services en fait il y en a peu. Car l’épreuve du temps et la patine font naître ou disparaître les candidats aux services. Pardon ? Cela vous fait penser à une forme de darwinisme. L’analogie est pertinente en effet ! Prenons une architecture autour d’un ou des systèmes COBOL disons mis en place il y a déjà pas mal de temps (durée à l’appréciation du lecteur). Ces services COBOL, se sont pérennisés dans le temps, les moins utiles ont disparu, les autres se sont enrichis, ont été challengés par les utilisateurs (entendons les applications). Les plus « résistants » sont restés : sorte de sélection naturelle.

Bien que l’on puisse les spécifier les services naissent, meurent et surtout évoluent dans le temps pour aboutir pour ceux qui sont en effet utilisés à des services métier transverses, fiables, stables et simples. Pour quelle échelle de temps ? Des années. Pardon ? Oui des années la stabilité d’un service transverse s’obtient au bout de plusieurs mois voire années ? Mais comment peut-il être adopté s’il met autant de temps à se stabiliser ? C’est que dès le départ il aura répondu à un besoin (une attente) fort qui fait que beaucoup l’auront adopté, puis challengé, amélioré et au final stabilisé il aura du passer toutes ces épreuves pour être admis au rang des services. Ou bien il va naitre dans un coin du SI pour une application donnée seule, puis digne d’intérêt une deuxième va vouloir l’utiliser, puis une troisième etc., sans qu’au départ on ait pu l’imaginer. Finalement, être un service cela ne se décrète pas, cela se mérite.

Prenons un autre exemple que sont les portails. On disait (il y a 5 ans) que tout allait être service et que l’on pourrait agréger des dizaines de services dans notre portail. Au final, que consulte l’utilisateur lambda : le CAC40, la météo et l’horoscope. C’est peu. Certains rétorquerons, dans « le monde professionnel monsieur, les services sont autrement plus nombreux et complexes ». Essayons ! Qu’est ce qui est susceptible d’intéresser et de motiver une équipe pour développer son application en s’appuyant sur des services transverses. Simple d’usage, transverse, performant, fiable et stable, si l’un de ces critères n’est pas respecté, le risque de rejet des utilisateurs (applications) est élevé. Prouvez-le ! Bon. S’il n’est pas transverse, peu d’applications l’utiliseront, est ce alors un service ? Performance : si son temps de réponse dégrade mes propres performances, je vais très vite l’abandonner. Fiabilité : un SLA en décalage (non compatible) avec le mien : c’est qu’il n’est pas fiable à mes yeux. Continuons, instable, aïe celui-ci est délicat, car on ne peut le juger que dans la durée. De plus, au début le service risque d’évoluer et c’est normal. Mais il n’en reste pas moins que si les couts de maintenance et de tests côté utilisateurs sont trop importants (suite aux évolutions) cela me fera réfléchir à une alternative via un développement maison par exemple. Complexe à consommer/utiliser : une notice de plus 3 pages, une ambigüité des cas d’utilisation et/ou de la gestion d’erreurs me feront prendre un risque d’un usage biaisé voire erroné.

Alors dans les back office COBOL (plutôt ancien ;-) ) que constate t on ? Qu’il existe des services transverses exposés depuis pas mal de temps et qui « rendent bien service ».

Des exemples, tirés de la vraie vie :

• calculer de l’octroi de crédit pour un tiers (Finance),
• récupérer un numéro de téléphone disponible (Telecom),
• la CB XXX XXX est-elle en opposition (Monétique),
• ouvrir un compte (Multi métier),
• obtenir les ratings d’un tiers (Finance),
• déclarer un sinistre (Assurance),
• éditer un chèque de remboursement/indemnisation (Assurance),
• obtenir un devis/tarification d’un produit (Multi métier, ….),
• souscrire à un produit (Multi métier, …).
• …

Tous ces services, au sein des entreprises sont relativement peu nombreux et sont en fait les services frontaux métiers qui ont fait leur preuve et qu’un grand nombre d’applications comprennent et utilisent. Ils masquent la complexité des implémentations sous jacentes. Si l’on devait regarder plus précisément s’ils respectent le formalisme évoqué ci-dessus. On s’apercevrait que oui. Mais vous l’avez compris le débat n’est pas là. D’ailleurs, l’article de Anne Thomas Manes ( SOA is Dead; Long Live Services) constate d’une manière assez similaire qu’en parlant SOA chacun s’est perdu dans des débats technologiques sans fin en oubliant l’essentiel : l’architecture et les services.

Alors que dans les faits, juste à côté de lui, de la SOA, pardon du service, Mr Jourdain en faisait dans son SI depuis des lustres, sans qu’il n’en sût rien. Quoi que, il fallait juste lui dire. Peut être alors se serait il poser les bonnes questions quand il a voulu faire de la SOA.

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.

USE CASE (Rappel)

RESTune est une application fictive de vente de musique en ligne. Cette application permet :

• de lister l’ensemble des albums : GET http://…/albums
• de récupérer un album en fournissant son identifiant : GET http://…/albums/12133
• de créer un album : POST http://…/albums

Architecture générale de l’application (Rappel)

RESTune est une application Java classique n-tiers :

• une couche DAO (framework Hibernate)
• une couche Service
• une couche Webservice (framework Jersey + JAXB pour la sérialisation / désérialisation)
• une gestion des beans par le framework Spring

Le test d’intégration

Par définition, le test d’intégration valide la cohérence d’une fonctionnalité dans son ensemble. Dans le cas de l’implémentation d’une ressource REST, il est nécessaire de traverser toutes les couches de l’application – de l’appel HTTP au WS REST jusqu’à la base de données dans notre exemple. Cette fois, l’ensemble de notre pile logicielle Spring + Hibernate + Jaxb + Jersey sera mise en jeu. Le but n’est bien évidemment pas de tester les frameworks mais l’utilisation qui en est faite et la cohérence de l’ensemble.

Environnement léger de test d’intégration

Le dispositif présenté ci-dessus permet de disposer sur le poste développeur d’un serveur d’application (Jetty) et d’une base de données en mémoire (HSQLDB). Ces deux outils ont, en autres, la particularité d’être légers et rapides. L’intérêt de ce dispositif est de créer un contexte se rapprochant le plus possible de la réalité (serveur d’application + base de données) tout en ne sacrifiant pas les performances. Cette plateforme permet d’exécuter des tests sur le poste développeur tout en s’autorisant à passer sur une plateforme d’intégration moyennant configuration (via Maven par exemple – cf ).

La classe de test AbstractWebRunnerTestCase permet de lancer un Jetty, de déployer l’application RESTune décrite par son fichier web.xml. L’utilisation du client Jersey permet de simplifier la manipulation de ressources REST par rapport à un client HTTP tel HTTPClient. A noter que ce client, prévu initialement pour faciliter les tests unitaires du framework Jersey, est un maintenant un composant a part entière du framework. Il peut donc permettre de réaliser la partie Cliente d’une application REST, tout comme tester une autre implémentation REST que Jersey (RESTLET, RESTeasy, …).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public abstract class AbstractWebRunnerTestCase {
private static int port = 9797;
private String url;
private static Server server;
private static Client client;
 
protected AbstractWebRunnerTestCase() {
this.url = String.format("http://localhost:%s/", port);
}
// Helper pour manipuler les ressources
protected WebResource getResource(String relativeUrl) {
String realUrl = url + relativeUrl; return client.resource(realUrl);
}
@BeforeClass
public static void setUp() throws Exception {
server = new Server(port);
 
// On lance le serveur Jetty
WebAppContext webAppContext = new WebAppContext("src/main/webapp", "/");
webAppContext.setConfigurationClasses(new String[] { "org.mortbay.jetty.webapp.WebInfConfiguration",
"org.mortbay.jetty.webapp.WebXmlConfiguration", });
server.addHandler(webAppContext); server.start(); // Création d'un client Jersey client = Client.create();
}
@AfterClass
public static void tearDown() throws Exception {
if (server != null)
server.stop();
}
}

Prenons l’exemple de la recherche d’album par identifiant : GET http://…/albums/{id}

Le code à tester

1
2
3
4
5
6
7

@GET
@Path("/{id}")
@Produces(MediaType.APPLICATION_XML)
public AlbumXmlBean getAlbumById(@PathParam("id") Long id) throws AlbumNotFoundException {
Album album = albumService.getAlbumById(id);
return new AlbumXmlBean(album);
 }

Méthode testée unitairement, il reste cependant à vérifier :
- Le Verbe http autorisé (configuré par l’annotation @GET)
- Le MediaType autorisé @Produces(MediaType.APPLICATION_XML)
- L’utilisation des Providers / ExceptionMappers (cf JSR-311)
- L’Enchainement des traitements et intégration des couches applicatives (JAXB, appel au DAO, appel à la DB).

Exemple de test d’intégration du cas Nominal

Ce test traverse l’ensemble des couches de l’application, de l’appel HTTP à l’appel à la base de données. Il permet de valider entièrement la réponse en vérifiant le code retour http et le contenu de la réponse.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:applicationContext.xml" })
public class AlbumsResourceIntTest extends AbstractWebRunnerTestCase {
@Autowired
HibernateTemplate hibernateTemplate;
@Test
public void getAlbumByIdNominalCase() {
// Setup
Album kidA = new Album();
 kidA.setReleaseDate(new Date());
 kidA.setTitle("Kid A");
 hibernateTemplate.save(kidA);
 AlbumXmlBean expectedKidAXmlBean = new AlbumXmlBean();
 expectedKidAXmlBean.setId(kidA.getId());
 expectedKidAXmlBean.setTitle(kidA.getTitle());
 // Test
WebResource resource = getResource("albums/" + kidA.getId());
 
// Assert
// Validation du code retour
ClientResponse clientResponse = resource.get(ClientResponse.class); assertEquals(Status.OK.getStatusCode(), clientResponse.getStatus());
 
// Validation de l'entité contenu dans la réponse
AlbumXmlBean retrievedAlbumXmlBean = resource.get(AlbumXmlBean.class);
assertNotNull(retrievedAlbumXmlBean);
assertEquals(expectedKidAXmlBean, retrievedAlbumXmlBean);
 }
[...]
}

Les possibilités offertes par Maven Gestion des configurations

Les tests d’intégration peuvent être exécutés à deux niveaux grâce à la gestion profils Maven. En effet, Maven offre la possibilité, par simple configuration, de gérer différents environnements (développeur, intégration, recette, production par exemple).

Test d’intégration développeur

Sur le poste développeur, priorité à la rapidité d’exécution. Etant donné qu’il y a un appel HTTP + JDBC, on ne se place plus dans une problématique de test unitaire mais bien de test d’intégration. Ces tests pourraient donc être qualifiés de tests d’intégration développeur.

1

mvn test –Pdeveloppement

Moyennant configuration dans le POM, les tests seront exécutés dans un environnement « développement » (Jetty + HSQLDB).

Test d’intégration

Le test d’intégration se doit de s’effectuer dans un environnement le plus proche possible de celui de production. Ce profil chargera donc l’environnement d’intégration complet : on peut par exemple garder Jetty pour l’exécution des tests mais attaquer la base d’intégration (avec ses propres données, son propres schémas, …). Plus complet mais aussi plus long à tester ! Ce genre de tests pourra être évité sur le poste du développeur et être exécuté par l’automate de build (tous les soirs par exemple).

1

mvn test –Pintegration

Il est donc possible de séparer les tests unitaires des tests d’intégration grâce à la configuration Maven.
Le plugin Jetty

1

mvn jetty:run

Le plugin Jetty (maven-jetty-plugin) permet de pouvoir lancer un serveur d’application léger et de déployer l’application en cours de développement. Un fois lancé, Jetty prend automatiquement en compte les modifications de code et de configuration. Cela peut notamment servir de démo pour que vous puissiez tester avec votre browser web préféré. Il est possible par exemple avec Firefox et son plugin Poster de tester le POST d’un XML sur une url.

Conclusion

Les tests d’intégration permettent de tester l’ensemble de la fonctionnalité offerte par la ressource, en invoquant l’ensemble de la pile logicielle. Ces tests sont par essence plus longs à jouer. La plateforme de test Jetty + HSQLDB est une réelle alternative permettant de tester au plus vite, dans un environnement plus riche que celui proposé par les tests unitaires. Maven offre de plus la possibilité de pouvoir piloter l’environnement sur lesquels ces tests sont exécutés par simple configuration. L’automate de build pourra alors construire l’application en exécutant au préalable les tests d’intégration sur une plateforme plus complète. Ces tests permettent de mitiger les risques sur :

• Les codes retour et le contenu des réponses
• L’utilisation des annotations du framework Jersey
• MIME Type
• L’utilisation des Providers / ExceptionMapper
• L’URI de la ressource
• La sérialisation / désérialisation des objets

Prochainement, nous étudierons plus en détails le test de recette d’une ressource REST. Pour être plus précis, ce dernier article exposera un moyen de réaliser et d’automatiser les tests de recette, autre moyen de valider/assurer la non-régression d’un service et d’avoir un feedback au plus tôt.

NB : Le code de RESTune est disponible ici.

Suggestion d'articles :

1. La stratégie de test d’une architecture REST (1/3) – Test unitaire d’une ressource
2. REST en JAVA avec la JSR-311
3. Versioning de services REST

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.

Use Case

RESTune est une application fictive de vente de musique en ligne. Cette application permet :

• de lister l’ensemble des albums : GET http://.../albums
• de récupérer un album en fournissant son identifiant : GET http://.../albums/12133
• de créer un album : POST http://.../albums

Architecture générale de l’application

RESTUne est une application Java classique n-tiers :

• une couche DAO (framework Hibernate)
• une couche Service
• une couche Webservice (framework Jersey + JAXB pour la sérialisation / désérialisation)
• une gestion des beans par le framework Spring

Le test unitaire

Le test unitaire est le premier maillon de la stratégie de test. Partant de la loi du Defect Cost Increase (plus un défaut est détecté tard, plus il coûte cher), le test unitaire (ou test du développeur) joue un rôle crucial. Il permet de valider que le code développé est conforme aux intentions du développeur. Partant du principe que tout test rejouable est de facto un test de non-regression, l’ensemble des tests unitaires d’une application constitue un patrimoine inestimable. Un test est par définition répétable, automatique, indépendant mais surtout pour le développeur impatient, il doit être rapide ! Nous allons donc mettre en place une stratégie de test unitaire légère et rapide.
Pour rappel, Michaël Feathers définit dans Working Effectively With Legacy Code un test unitaire de la façon suivante :

• Il ne communique pas avec la base de données
• Il ne communique pas avec d’autres ressources sur le réseau
• Il ne manipule pas un ou plusieurs fichiers
• Il peut s’exécuter en même temps que les autres tests unitaires
• On ne doit pas faire quelque chose de spécial, comme éditer un fichier de configuration, pour l’exécuter

Le pattern « couche d’exposition fine »

Le test unitaire se borne à valider la couche d’exposition de services. Dans les applications Web classiques, il est préférable de ne laisser que très peu de logique au niveau de la couche présentation. D’un point de vue design, l’application y gagne en lisibilité et en testabilité. Il est facile de faire le parallèle avec la couche d’exposition. Plus elle sera fine et ne comportera des données propres à l’exposition, plus elle sera simple à tester. En REST, l’exposition de services se fait bien entendu au moyen de ressources.

La JSR-311 se basant sur des beans annotés, il est simple de tester unitairement ces beans hors de tout contexte. Nous allons donc tester notre ressource Album en isolation.
Le code d’exposition de la ressource est le suivant :

@Singleton
@Path("/albums")
public class AlbumsResource { 

@Context
private UriInfo uriInfo;
@Inject
AlbumService albumService;
[...]
@POST
@Produces(MediaType.APPLICATION_XML)
@Consumes(MediaType.APPLICATION_XML)
public Response postAlbum(AlbumXmlBean albumXmlBean)
{
Album album = albumXmlBeanToAlbum(albumXmlBean);
try {
albumService.save(album);
}
catch (AlbumAlreadyExists e) {
return Response.status(Status.CONFLICT).entity("Album with title " + album.getTitle() + " already exists").build();
}
AlbumXmlBean albumXmlBeanAfterSave = albumToAlbumXmlBean(album);
// Building URI
UriBuilder uriBuilder = uriInfo.getAbsolutePathBuilder();
URI uri = uriBuilder.path(albumXmlBeanAfterSave.getId().toString()).build();
return Response.created(uri).entity(albumXmlBeanAfterSave).build();
}
[...]
}

Le pattern Mock Object

Le pattern Mock Object ou bouchonnage permet d’isoler ma ressource Album de ses dépendances et de se conformer à la définition de test unitaire faite par Feathers. Nous allons donc mocker les couches inférieures grâce au framework Unitils. Unitils est un framework qui permet de simplifier les tests unitaires. Il permet entre autres de simplifier l’écriture de Mock grâce à EasyMock.

@RunWith(UnitilsJUnit4TestClassRunner.class)
public class AlbumsResourceUTest {
// Objet du test
@TestedObject
AlbumsResource albumsResource;

// Mock + injection dans l'objet du test
@RegularMock
@InjectIntoByType
AlbumService albumService;

// Mock + injection dans l'objet du test
@RegularMock
@InjectIntoByType
UriInfo uriInfo;

// Simple mock
@Mock
UriBuilder uriBuilder;
[...]
}

Easymock permet en un minimum de code de disposer d’objet mocké que l’on va pouvoir maîtriser afin de mener à bien nos tests. Pour information, la méthode EasyMock.expect(…) permet de valider l’utilisation des objets mockés (nombre d’appel, arguments, …) tout en manipulant leur comportement.

Exemple : Test unitaire du cas nominal

Ce test permet de valider le comportement nominal du service. Il vérifie la réponse de la ressource, le code retour ainsi que l’appel à la méthode sous-jacente albumService.save().

@Test
public void postAlbumNominalCase() throws URISyntaxException {
// Setup
Album album = new Album(); album.setTitle("In Rainbows");
album.setId(new Long(32));
albumXmlBean.setTitle("In Rainbows");
albumXmlBean.setId(album.getId());
URI expectedUri = new URI("http://test");

// Mock expectations
albumService.save(album);
EasyMock.expect(uriInfo.getAbsolutePathBuilder()).andReturn(uriBuilder);
EasyMock.expect(uriBuilder.path(album.getId().toString())).andReturn(uriBuilder);
EasyMock.expect(uriBuilder.build()).andReturn(expectedUri); EasyMockUnitils.replay();

// Test
Response response = albumsResource.postAlbum(albumXmlBean);

// Asserts
assertEquals(Status.CREATED.getStatusCode(), response.getStatus());
AlbumXmlBean returnedAlbumXmlBean = (AlbumXmlBean) response.getEntity();
assertTrue(response.getMetadata().containsKey("Location"));

URI returnedUri = (URI) response.getMetadata().get("Location").get(0);
assertEquals(expectedUri, returnedUri); assertEquals(albumXmlBean, returnedAlbumXmlBean);

Il est dès lors possible de construire tous les cas de test en pilotant ces mocks. Par exemple le test suivant valide qu’à la levée d’une exception AlbumAlreadyExistsException, le web service renvoie un code retour CONFLICT (409) :

Conclusion

Les tests unitaires sur un service web permettent de tester en isolation une ressource (sans Spring + Hibernate + Jaxb + Jersey). Quand on connait le contexte que traine chacun de ces frameworks, on s’aperçoit qu’on arrive à tester au maximum notre ressource de manière simple (manipulation de POJOs). Ces tests seront d’autant plus fréquemment rejoués qu’ils sont rapides à exécuter et participeront donc à la qualité générale de l’application. A travers ces tests, il est possible de valider que la ressource mise en place est conforme aux intentions du développeur :

• en vérifiant l’appel aux méthodes sous-jacente (vérification de l’appel de méthodes, des arguments)
• en simulant les exceptions et en validant le comportement de la couche d’exposition
• en validant les codes retours et le contenu des réponses répondant aux différents use cases du service

Le test unitaire est le premier maillon du harnais de tests. Nous verrons dans les articles suivants dans quelle mesure les tests d’intégration et les tests de recette participent eux aussi à la mise en place d’une stratégie de test efficace.

Rq : Vous pouvez me contacter si vous désirez le code complet de RESTune

Suggestion d'articles :

1. La stratégie de test d’une architecture REST (2/3) – Test d’intégration
2. REST en JAVA avec la JSR-311
3. Versioning de services REST

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.

La SOA doit aider à fédérer une communauté de partenaires et à maintenir l’adaptabilité du SI

Dans les échanges qu’a l’entreprise avec ses partenaires extérieurs divers, la nécessité de mettre en place et d’utiliser des services ne se discute plus. L’entreprise s’ouvre, s’interconnecte, fournit et consomme de l’information, participe à des chaînes de valeur : cherche à fédérer autour de sa plateforme. Dans l’extension de cette approche vers l’intérieur, l’entreprise cherche à maitriser les processus métier et à répondre à des enjeux tels que le cross-selling, le respect du time-to-market de nouveaux produits, la possibilité d’absorber des reconfigurations sectorielles…
La DSI occupe une place prépondérante dans cette transformation et les enjeux invoqués se déclinent alors essentiellement dans la mutualisation des règles métiers, la gouvernance et la qualité de la donnée, la gestion des échanges inter/intra entreprise, la recherche de l’efficacité des projets informatiques (en favorisant par exemple l’interopérabilité des applications de générations ou de technologies différentes) et l’adaptabilité du SI aux évolutions métiers.

Le SI  » mute  » d’un SI en silos vers un SI proposant des services partagés

Un consensus semble établi sur le fait que la SOA est un des meilleurs candidats pour adresser l’ensemble de ces enjeux. Mais les SI d’aujourd’hui sont constitués d’applications et de sources de données variées, basées sur des technologies hétérogènes et souvent gérées par des organisations cloisonnées. La SOA tire ses gênes de cette complexité et propose une architecture qui présente fonctions et informations du SI sous forme de « services » interopérables et faiblement couplés. L’architecture du SI s’organise alors à travers la factorisation des éléments communs, l’élimination des redondances, la réutilisation de services avec comme conséquence la « mutation » d’un SI en silo vers un SI proposant des services partagés

Reste qu’une telle mise en oeuvre est souvent synonyme de désillusions voire de douleurs…

• une augmentation drastique des dépendances entre les applications et les équipes avec des difficultés lors de la planification des développements, lors de la définition et la mise à disposition des contrats de services, des impacts sur les processus de gestion des évolutions ou de correction des anomalies qui doit prendre en compte les divers consommateurs, un  » run  » qui peut avoir à assurer la disponibilité de multiples versions de services, la promesse de découplage qui fait oublier que l’ensemble des applications mises à contribution risquent de devoir s’aligner sur le SLA le plus exigeant
• une mise en oeuvre prématurée d’outils comme les ESB ou les BPM. Utiliser à bon escient et dans des organisations suffisamment matures, ces outils permettent d’optimiser certains comportements (sécurité, routage, administration…). A l’inverse, ils peuvent devenir une contrainte et une source de complexité
• une approche uniquement  » bottom-up  » qui mène à des échanges points à points non maitrisés et une très faible réutilisabilité
• une approche uniquement  » top-down  » qui imagine des SI  » tout services «  ; créant des formats pivots  » a priori  » alors que beaucoup d’applications ne sont pas prêtes ou normalisant  » à tout va  » les référentiels au risque de limiter la performance générale des services

Une démarche SOA doit se décliner sur trois axes : les technologies, l’architecture du SI et les aspects organisationnels et humains

La mise en oeuvre d’une architecture SOA doit être pragmatique et dimensionnée en fonction de la complexité de l’architecture cible et de la maturité de l’organisation pour supporter humainement, techniquement et financièrement cette architecture.

Mais quelque soit le niveau de complexité et de maturité, la réalisation d’une architecture SOA se décline sur trois axes: les technologies, l’architecture du SI et les aspects organisationnels et humains.

L’axe technologique embrasse l’ensemble des aspects de l’architecture applicative et de l’expertise technique et vise à plus de simplicité. L’émergence d’architectures dites « orientées ressources » (ROA) et plus légères que les approches dites « classiques » (SOAP) rebattent les cartes et promettent de meilleures interopérabilité et productivité mais cela nécessite d’appliquer des principes d’architecture différents et potentiellement complémentaires. Parallèlement, la sécurisation des services doit privilégier une approche pilotée par les risques plutôt qu’une approche totalement sécuritaire et permettre l’utilisation de moyens techniques adaptés en termes de propriétés et de coûts. Enfin, les différentes plateformes de développement sont relativement matures mais reste à maîtriser leur déploiement (contract-first, code-first), industrialiser leur utilisation afin que leur usage dans le flux de développement ne soit un frein ni à la productivité, ni à la testabilité.

Le second axe regroupe les disciplines de l’architecture de SI, la modélisation des processus métier et promeut des architectures simples et évolutives, des standards opérationnels. Il est aujourd’hui nécessaire de mixer approche organique et approche légaliste. L’approche organique, permet de faire  » émerger  » des services au sein de projets et facilite la découverte d’une direction opérable à coûts et risques optimisés à partir d’un existant en terme de code, de compétences techniques et fonctionnelles. Mais cette approche sera cadrée par l’approche légaliste permettant d’aligner les différents acteurs sur une intention commune, une vision partagée. De ce mélange des deux approches apparaît une direction unique et utile : des modèles et des standards applicables rapidement par les projets et améliorés de façon continue grâce au « retour terrain ».

Enfin l’organisation et les dynamiques d’équipes devront évoluer pour « s’aligner » sur ces notions de « services » et intégrer un mode de développement lui aussi distribué. Des aspects souvent oubliés mais qui imposent à l’organisation de se transformer pour faire émerger des équipes responsables (c’est à dire garantes de la sémantique, de l’intéropérabilité, de la non régression, du SLA…) des services. Cette mise en oeuvre du changement, passera par l’adaptation des processus de développement, de l’organisation du travail et par la remise en cause de la classique contractualisation entre équipes. Cette transformation se traduira par une spécialisation des équipes par  » bouquet de services « , une diminution des chaines de responsabilités afin de polariser les équipes sur un unique but qu’est le « service », une évolution des processus de développement vers du plus « itératif-incrémental ».

Quant à la Gouvernance, cette dernière aura à charge de préciser les standards à appliquer sur chacun des ces trois axes.

Ainsi, pour que l’augmentation des dépendances entre services et équipes n’aboutisse pas à une paralysie générale lors de la transformation du SI vers une architecture de services, les équipes devront maîtriser les outils et méthodes de l’amélioration continue : développement incrémental et itératif, testabilité du SI, architecture organique, standards émergeants, responsabilisation des hommes

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.

Quels sont donc les apports de cette JSR dans le développement d’applications Java orientées ressources ? Afin de respecter le style architectural REST, il est nécessaire de suivre certaines règles. Ces règles vous pouvez les retrouver dans la thèse de Roy Fielding, le livre Restful Web Services ou avec une simple recherche sur le Web. Dans cet article, je me suis librement inspiré d’une présentation de Paul Sandoz (commiteur Jersey / JSR-311) à Java One. Les exemples de code présentés utilisent Jersey ^[1].

La ressource REST

En REST, une ressource représente une chose suffisamment importante à vos yeux pour être référencée. Ce n’est pas obligatoirement l’exposition d’un tuple de votre base de données. Cela peut tout aussi bien être le résultat d’un algorithme, un document, une liste d’objets sérialisés, … De manière générale, tout ce qui peut être stocké sur un ordinateur ou représenté sous la forme d’un flux de bits peut être considéré comme une ressource.

Les exemples présentés ci-après ont été développés grâce à Jersey, la RI (Reference Implementation) de Sun, qui semble à l’heure actuelle, être le framework REST plus mature. La version 1.0 devrait paraître à la fin du mois de Septembre. Il est dors et déjà utilisable en version 0.9 avec de multiples fonctionnalités (intégration avec Spring, client de test, …). Le but de cet article n’étant pas d’exposer les fonctionnalités de Jersey, nous resterons concentrés sur les spécificités de la JSR-311. Un article dédié à l’utilisation de Jersey paraîtra prochainement sur ce même blog.

On référence une ressource en lui associant un identifiant unique : on s’appuie sur la notion d’URI du protocole HTTP. C’est le moyen univoque d’accéder à une ressource.

Quelques exemples d’URI

• http://www.monserveur.com/customers : Pointe sur l’ensemble des clients

• http://www.monserveur.com/customers/12 : Pointe sur le client dont l’identifiant technique est 12

• http://www.monserveur.com/orders/XXXX/customers : Pointe sur les clients dont l’ordre à pour identifiant XXXX

Annotation @Path

La JSR-311 définit l’annotation @Path : elle permet de lier une ressource à une URI.

1
2
3
4
5

@Path(“/customers”)
public class CustomersResource {
@GET
public Customer getCustomer() {…}
}

1
2
3
4
5
6
7

@Path(“/customers”)
public class CustomersResource {
@GET
@Path(“/{email}”)
public Customer getCustomer(@PathParam(“email”) String emailAddress)
{…}
}

De même, @QueryParam(« maVar ») retourne la valeur du paramètre de l’url http://monServeur/monContexte/customers/{email}?maVar=12.

Principe 2 – Use standard methods : utilisation des méthodes HTTP

Les architectures REST doivent respecter le standard HTTP, tant dans les codes retours que dans l’utilisation même des verbes HTTP (définie par la RFC 2616 ).

Ces méthodes permettent de manipuler des ressources désignées par leur URI .

• GET sur http://www.monserveur.com/customers : Totalité des clients
• POST sur http://www.monserveur.com/customers : Création d’un client

@GET, @POST, @DELETE, @PUT, @HEAD

1
2
3

@GET
@Path(“/{email}”)
public Customer getCustomer(@PathParam(“email”) String emailAddress){…}

1
2
3
4
5
6
7
8
9
10
11
12
13

@Context
private UriInfo uriInfo; // Injecté directement dans la ressource
…
// Récupere le path courant
UriBuilder uriBuilder = uriInfo.getAbsolutePathBuilder();
 
// Crée l’uri pour accéder à la nouvelle ressource
URI uri = uriBuilder.path(customer.getId()).build();
 
// Retourne la réponse avec la nouvelle ressource
return Response.created(uri).entity(customer).build();
 
}

1
2
3
4
5
6
7
8
9
10
11

@GET
 
@Consumes({”application/xml”})
 
@Produces({”application/xml”,”application/json”})
 
Order getOrder(@PathParam(”order_id”) String id) {
 
…
 
}

1
2
3
4
5
6
7
8
9

@Produces(”text/plain”)
 
Content getContent(){
 
…
 
return content;
 
}

1
2
3
4
5
6
7
8
9
10

@Produces(”text/plain”)
@Provider
public class ContentProvider implements MessageBodyWriter {
 
public void writeTo(Content p,Class type, Type genericType, Annotation annotations[],MediaType mediaType, MultivaluedMapOutputStream out) throws IOException {
 
out.write(”[Content] : “+ content.toString());
 
}…
}

1
2
3
4
5
6
7
8
9
10
11

@Provider
public class RuntimeMapper implements ExceptionMapper {
 
private Logger logger = Logger.getLogger(getClass());
 
public Response toResponse(IllegalArgumentException e) {
 
return Response.status(Status.BAD_REQUEST).entity(e.getMessage()).build();
}
}
}

Suggestion d'articles :

1. Des principes (ou quelques idées…) REST et du Mashup
2. La stratégie de test d’une architecture REST (2/3) – Test d’intégration
3. La stratégie de test d’une architecture REST (1/3) – Test unitaire d’une ressource