Dans l’article précédent nous avions abordé la mise en œuvre des implémentations JAX-RS Jersey et RESTEasy ainsi que celles de CXF et Restlet.

Nous nous intéresserons dans cette seconde partie aux tests unitaires.

Avant d’entrer dans le détail je souhaiterais attirer votre attention sur le fait que toutes ces implémentations offrent la possibilité de faire tourner des tests dans des serveurs embarqués, ce qui tient du test d’intégration et non du test unitaire.

Voyons maintenant dans quelle mesure chaque implémentation offre la possibilité de mocker le serveur.

CXF

Grosse déception ici : CXF n’offre pas de framework de test permettant de mocker le serveur…

On est donc limité à priori à tester nos services dans le serveur embarqué Jetty…

Il est cependant possible de s’en sortir en utilisant les classes de test de Spring :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:testMockContext.xml" })
public class TestMockService {
	@Autowired
	private ServletTransportFactory servletTransportFactory;
 
	@Test
	public void testGet1() throws IOException, ServletException {
		MockHttpServletRequest request = new MockHttpServletRequest("GET", "/someResource/1");
		request.setContent(new byte[]{});
		MockHttpServletResponse response = new MockHttpServletResponse();
		ServletDestination destinationForPath = servletTransportFactory.getDestinationForPath("/");
		destinationForPath.invoke(new MockServletContext(), request, response);
 
		assertEquals(HttpServletResponse.SC_OK, response.getStatus());
 
		assertEquals("{\"someBean\":[{\"someAttribute\":\"someValue\"}]}",
				response.getContentAsString());
	}
}

MockHttpServletRequest, MockHttpServletResponse et MockServletContext sont des classes de spring-test.
Afin d’avoir accès à la ServletTransportFactory il vous faudra importer le fichier cxf-servlet.xml dans votre configuration Spring de test :

1

<import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>

Enfin, l’appel à setContent, ligne 10, est nécessaire pour ne pas provoquer de NullPointerException de la part de CXF qui effectue un appel à getInputStream sur la requête sans vérifier si la valeur de retour de la méthode est null ou non.

Jersey

Jersey met à disposition du développeur un framework de test plutôt complet. La documentation est malheureusement un peu avare d’exemples et si l’utilisation de Spring avec les serveurs embarqués ne pose pas de problèmes particuliers, c’est une autre histoire dès lors que l’on souhaite utiliser le module jersey-test-framework-inmemory.

Afin d’utiliser le framework de test de Jersey, vos classes de test doivent en principe hériter de JerseyTest qui fait tout le travail d’initialisation et de configuration dans son constructeur qui n’a du coup pas accès aux beans Spring.

Afin d’avoir un test qui tourne avec le module de test inmemory et Spring, le résultat final ressemblera du coup à peu près à ceci :

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
30
31
32

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:WEB-INF/applicationContext.xml" })
public class TestServiceInMemory {
	private JerseyTest jersey;
 
	@Autowired
	SomeService someService;
 
	@Before
	public void before() throws Exception {
		jersey = new JerseyTest(new InMemoryTestContainerFactory()) {
			protected com.sun.jersey.test.framework.AppDescriptor configure() {
				DefaultResourceConfig rc = new DefaultResourceConfig();
				rc.getSingletons().add(someService);
				rc.getClasses().add(org.codehaus.jackson.jaxrs.JacksonJsonProvider.class);
				return new LowLevelAppDescriptor.Builder(rc).contextPath("poc-jersey").build();
			};
		};
		jersey.setUp();
	}
 
	@Test
	public void testGet1() {
		String result = jersey.resource().path("/someResource/1").get(String.class);
		assertEquals("{\"someBean\":[{\"someAttribute\":\"someValue\"}]}", result);
	}
 
	@After
	public void after() throws Exception {
		jersey.tearDown();
	}
}

RESTEasy

Tout comme Jersey, RESTEasy fournit tout un framework de test. Là aussi la documentation est plutôt succincte, mais en revanche son intégration avec Spring s’est avérée nettement plus simple voire intuitive.

A titre d’exemple voici le même test que précédemment adapté au framework de test de 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

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:WEB-INF/applicationContext.xml" })
public class TestMockedService {
	private Dispatcher dispatcher = MockDispatcherFactory.createDispatcher();
 
	@Autowired
	private SomeService someService;
 
	@Before
	public void before() {
		dispatcher.getRegistry().addSingletonResource(someService);
	}
 
	@Test
	public void testGet1() throws URISyntaxException {
		MockHttpRequest request = MockHttpRequest.get("/someResource/1");
		MockHttpResponse response = new MockHttpResponse();
		dispatcher.invoke(request, response);
 
		assertEquals(HttpServletResponse.SC_OK, response.getStatus());
 
		assertEquals("{\"someBean\":[{\"someAttribute\":\"someValue\"}]}", response.getContentAsString());
	}
}

On appréciera la simplicité du code.
Mon cœur qui balançait jusqu’à présent entre Jersey et RESTEasy penche cette fois définitivement en faveur de RESTEasy.

Restlet

Restlet est un peu à part puisqu’il propose sa propre API qui ne nécessite pas de tourner dans un serveur d’application. De fait il est relativement facile d’écrire des tests unitaires avec ce framework :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:WEB-INF/applicationContext.xml" })
public class TestMockedService {
 
	@Autowired
	private MyJaxrsApplication jaxrsApplication;
 
	@Test
	public void testGet1() throws URISyntaxException, IOException {
		Request request = new Request(Method.GET, "/someResource/1");
		request.getResourceRef().setBaseRef("/");
		request.setOriginalRef(request.getResourceRef());
		request.setRootRef(request.getResourceRef().getBaseRef());
		Response response = new Response(request);
		jaxrsApplication.getJaxRsRestlet().handle(request, response);
 
		assertEquals(HttpServletResponse.SC_OK, response.getStatus().getCode());
 
		assertEquals("{\"someBean\":[{\"someAttribute\":\"someValue\"}]}", response.getEntity().getText());
	}
}

Performances

Un dernier élément intéressant est celui des performances. J’utilise pour ma part le plugin Infinitest pour Eclipse, il est donc essentiel que mes tests s’exécutent le plus rapidement possible.
Le tableau suivant inclut les résultats obtenus pour le même test avec, puis sans serveur embarqué. Chaque implémentation utilisant un serveur embarqué différent j’ai indiqué le nom de ce dernier à chaque fois :

Conclusion

Si la communauté derrière Jersey est semble-t-il plus active que celle derrière RESTEasy (impression personnelle basée uniquement sur la fréquence de sortie des milestones), ce dernier me paraît plus mature et surtout mieux pensé, surtout lorsque l’on aborde la question des tests unitaires.

CXF qui est pour sa part très puissant nécessite davantage de travail de configuration que ses deux concurrents. Il lui « suffirait » pourtant d’un mécanisme de détection automatique des services JAX-RS (et pourquoi pas JAX-WS ?) et des providers disponibles, ainsi que d’un vrai framework de test pour venir sérieusement les titiller.

Restlet, enfin, n’étant pas de base une implémentation de JAX-RS, fait plus figure de curiosité dans ce comparatif, même si côté performances dans les tests unitaires il s’en sort en seconde position derrière RESTEasy…

Au final, si à mon sens RESTEasy est aujourd’hui en tête, les quatre frameworks évoluent rapidement et mon classement pourrait être complètement chamboulé d’ici quelques mois. Il faut donc les surveiller de près… En outre, je ne me suis intéressé dans ces deux articles qu’au standard JAX-RS et il serait sans doute intéressant de voir ce qu’auraient à offrir d’autres framework REST tels que Restlet bien sûr, mais aussi Spring.

Pour finir voici un tableau récapitulatif :

A noter que la note configuration tient compte de la qualité de la documentation et que dans le cas de Restlet les notes ne tiennent compte que de son utilisation dans le cadre bien particulier défini dans ces deux articles.

Suggestion d'articles :

1. Les implémentations JAX-RS (1)
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

Il y a quelque temps l’envie de développer une petite application Java RESTFul m’a pris subitement. Je me suis donc penché sur les différentes implémentations JAX-RS et voici le résultat de mon investigation.

Je me suis tout de même posé quelques contraintes :

• que mon code Java soit complètement indépendant de l’implémentation JAX-RS choisie ;
• pouvoir facilement intégrer mes services avec Spring ;
• ne produire et consommer que du JSON en utilisant l’API Jackson ;
• pouvoir facilement mettre en place des tests unitaires.

Ce qui m’amène à comparer trois implémentations : CXF (version 2.3.2), Jersey (version 1.5), RESTEasy (version 2.1.0.GA) et Restlet (version 2.0.5).

CXF, Jersey et RESTEasy utilisent Jettison pour produire et consommer du JSON. Or Jettison est un outil de mapping JSON/XML or je souhaite effectuer un simple mapping POJO/JSON. Raison pour laquelle j’opte pour Jackson.

Je partirai du principe qu’une certaine connaissance de JAX-RS, Spring et Maven est acquise par mes lecteurs.

Concernant les performances, je ne m’attarderai pas dessus car il s’avère qu’elles se tiennent dans un mouchoir de poche.

Les sources sont disponibles sur Github.

Sans plus attendre, revêtons notre bleu de travail, calons notre crayon derrière l’oreille et mettons les mains dans le cambouis…

Le service

Voici le code – on ne peut plus simple – du service que l’on se propose de déployer :

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

@Path("/someResource")
@Service
public class SomeService {
	@Resource
	private BeanRepo beanRepo;
 
	@GET
	@Produces(MediaType.APPLICATION_JSON)
	public List<SomeBean> getSomeBeans() {
		return beanRepo.getAll();
	}
 
	@GET
	@Produces(MediaType.APPLICATION_JSON)
	@Path("{index}")
	public SomeBean getSomeBean(@PathParam("index") int index) {
		return beanRepo.get(index);
	}
 
	@PUT
	@Consumes(MediaType.APPLICATION_JSON)
	public void saveSomeBean(SomeBean someBean) {
		beanRepo.save(someBean);
	}
}

On remarquera l’utilisation des annotations @Produces et @Consumes qui indiquent que l’on ne produit et consomme ici que du JSON.

CXF

On ne présente plus CXF, la stack par excellence pour développer des services en Java supportant tous types de transports et de protocoles et aux performances qui ne sont plus à démontrer.

Et si vous n’êtes toujours pas convaincus, allez donc jeter un œil aux articles référencés ici ou là.

Certains argueront qu’utiliser CXF pour du REST c’est comme aller chercher un couteau suisse pour ouvrir une bière quand un simple décapsuleur était à portée de main…

Dépendances

La documentation de CXF est très bien fournie à ce niveau. Cependant l’artifact Maven cxf-rt-frontend-jaxrs ramène toutes les dépendances permettant d’effectuer des mappings XML ainsi que Jettison, ce dont je n’ai pas besoin.

Afin de n’importer que le strict nécessaire mon POM ressemble donc à ceci :

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

<dependency>
	<groupId>org.apache.cxf</groupId>
	<artifactId>cxf-rt-frontend-jaxrs</artifactId>
	<version>${cxf.version}</version>
	<!-- Since we use jackson, we can get rid of Jettison and all XML stuff -->
	<exclusions>
		<exclusion>
			<groupId>org.apache.xmlbeans</groupId>
			<artifactId>xmlbeans</artifactId>
		</exclusion>
		<exclusion>
			<groupId>com.sun.xml.bind</groupId>
			<artifactId>jaxb-impl</artifactId>
		</exclusion>
		<exclusion>
			<groupId>org.codehaus.woodstox</groupId>
			<artifactId>woodstox-core-asl</artifactId>
		</exclusion>
		<exclusion>
			<groupId>org.codehaus.jettison</groupId>
			<artifactId>jettison</artifactId>
		</exclusion>
		<exclusion>
			<artifactId>cxf-rt-databinding-aegis</artifactId>
			<groupId>org.apache.cxf</groupId>
		</exclusion>
	</exclusions>
</dependency>

Configuration Spring

CXF gérant différents types de transports et de protocoles, il nécessite davantage de configuration que ses « concurrents » avec notamment l’import des fichiers de configuration CXF, le namespace jaxrs à définir et enfin la déclaration et configuration systématique de chaque service…

En outre la documentation n’explique pas très clairement comment intégrer Jackson et si vous êtes nouveau sur CXF il vous faudra parcourir toute la documentation avant de comprendre comment ajouter un provider à un service REST (ce qui en fin de compte n’est pas bien compliqué comme le montre la suite).

L’essentiel de la documentation se trouve ici et là. Pour faire court, le principe est de fournir un provider JSON à nos services :

1
2
3
4
5
6
7
8

<jaxrs:server id="someService" transportId="http://cxf.apache.org/transports/http">
	<jaxrs:serviceBeans>
		<bean class="com.octo.rest.SomeService" />
	</jaxrs:serviceBeans>
	<jaxrs:providers>
		<bean class="org.codehaus.jackson.jaxrs.JacksonJsonProvider" />
	</jaxrs:providers>
</jaxrs:server>

Simple certes, mais il faut le faire pour chaque service !

On notera l’attribut transportId sur la balise jaxrs:server, qui par défaut vaut http://schemas.xmlsoap.org/wsdl/http (donc du SOAP, ce qui n’est pas vraiment ce que l’on veut).

Il est possible de ne pas avoir à redéfinir le provider pour chacun de ses services, mais il faut creuser un peu dans les classes de CXF. En l’occurrence il suffit de manipuler directement la ProviderFactory :

1
2
3
4
5

<bean class="org.apache.cxf.jaxrs.provider.ProviderFactory" factory-method="getSharedInstance">
	<property name="userProviders">
		<bean class="org.codehaus.jackson.jaxrs.JacksonJsonProvider" />
	</property>
</bean>

Bref CXF qui est génial pour faire du SOAP et du RPC dans tous les sens dans des architectures hétérogènes tout en garantissant d’excellentes performances n’est ici clairement pas la solution la plus pratique à mettre en œuvre.

Jersey

C’est l’implémentation de référence de JAX-RS, simple, efficace et performante.

Afin d’utiliser Jackson avec Jersey il nous faut :

• importer l’artefact jersey-json
• mettre à true la propriété com.sun.jersey.api.json.POJOMappingFeature au niveau de la servlet Jersey dans le web.xml. Cette propriété indique que l’on souhaite mapper nos POJO directement sur du JSON au lieu du XML.

Ce dernier point est parfaitement expliqué dans la documentation par ailleurs assez complète.

Enfin, la configuration Spring est on ne peut plus simple puisqu’il suffit d’activer la gestion des annotations.

Dépendances

Là encore un nettoyage est nécessaire si l’on ne souhaite importer que l’essentiel :

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

<dependency>
	<groupId>com.sun.jersey.contribs</groupId>
	<artifactId>jersey-spring</artifactId>
	<version>1.5</version>
</dependency>
<dependency>
	<groupId>com.sun.jersey</groupId>
	<artifactId>jersey-json</artifactId>
	<version>1.5</version>
	<exclusions>
		<exclusion>
			<groupId>org.codehaus.jackson</groupId>
			<artifactId>jackson-core-asl</artifactId>
		</exclusion>
		<exclusion>
			<groupId>org.codehaus.jackson</groupId>
			<artifactId>jackson-mapper-asl</artifactId>
		</exclusion>
		<exclusion>
			<artifactId>jaxb-impl</artifactId>
			<groupId>com.sun.xml.bind</groupId>
		</exclusion>
		<exclusion>
			<artifactId>jettison</artifactId>
			<groupId>org.codehaus.jettison</groupId>
		</exclusion>
	</exclusions>
</dependency>

Jersey est donc extrêmement simple à mettre en œuvre et s’avère largement suffisant pour mon utilisation.

RESTEasy

Pour finir voici l’implémention de JBoss de JAX-RS. Ses avantages sont principalement :

• son intégration assez poussée avec le serveur JBoss
• son intégration avec, outre Spring, Spring-MVC, Guice, Seam

Comme les autres implémentations, RESTEasy utilise Jettison par défaut comme provider JSON. Pour utiliser Jackson, il suffit d’importer l’artefact resteasy-jackson-provider et le tour est joué.

J’ajouterai que RESTEasy fournit probablement la documentation la plus complète des trois implémentations.

Dépendances

Une fois de plus il faudra faire du nettoyage dans le POM :

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
30

<dependency>
	<groupId>org.jboss.resteasy</groupId>
	<artifactId>resteasy-spring</artifactId>
	<version>2.1.0.GA</version>
	<exclusions>
		<exclusion>
			<groupId>org.jboss.resteasy</groupId>
			<artifactId>resteasy-jaxb-provider</artifactId>
		</exclusion>
		<exclusion>
			<artifactId>resteasy-jettison-provider</artifactId>
			<groupId>org.jboss.resteasy</groupId>
		</exclusion>
	</exclusions>
</dependency>
<dependency>
	<groupId>org.jboss.resteasy</groupId>
	<artifactId>resteasy-jackson-provider</artifactId>
	<version>2.1.0.GA</version>
	<exclusions>
		<exclusion>
			<groupId>org.codehaus.jackson</groupId>
			<artifactId>jackson-core-asl</artifactId>
		</exclusion>
		<exclusion>
			<groupId>org.codehaus.jackson</groupId>
			<artifactId>jackson-mapper-asl</artifactId>
		</exclusion>
	</exclusions>
</dependency>

On notera qu’alors que l’artefact resteasy-jackson-provider n’importe bien que l’essentiel, ce qui offre un avantage intéressant comparé à ses concurrents. resteasy-spring importe malheureusement indirectement des providers via resteasy-core qu’il me faut exclure.

Restlet

Restlet est initialement une solution Java RESTFul conçue pour fonctionner de manière autonome contrairement aux frameworks précédents.
Restlet propose néanmoins diverses extensions dont une offrant la possibilité de le faire fonctionner au sein d’un conteneur de servlets, une autre offrant le support JAX-RS et une autre le support de Spring.
Par conséquent cette partie de l’article n’est pas forcément pertinente dans le sens où elle montre une utilisation de Restlet plutôt bancale, mais me semble néanmoins intéressante.

Dépendances

Un petit nettoyage du POM s’impose pour ne garder que l’essentiel :

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
30
31
32
33
34

<dependency>
	<groupId>org.restlet.jee</groupId>
	<artifactId>org.restlet.ext.jaxrs</artifactId>
	<version>2.0.5</version>
	<exclusions>
		<exclusion>
			<artifactId>jaxb-impl</artifactId>
			<groupId>com.sun.xml.bind</groupId>
		</exclusion>
		<exclusion>
			<artifactId>jaxb-api</artifactId>
			<groupId>javax.xml.bind</groupId>
		</exclusion>
		<exclusion>
			<artifactId>org.restlet.lib.org.json</artifactId>
			<groupId>org.restlet.jee</groupId>
		</exclusion>
		<exclusion>
			<artifactId>stax-api</artifactId>
			<groupId>javax.xml.stream</groupId>
		</exclusion>
	</exclusions>
</dependency>
<dependency>
	<groupId>org.restlet.jee</groupId>
	<artifactId>org.restlet.ext.spring</artifactId>
	<version>2.0.5</version>
	<exclusions>
		<exclusion>
			<artifactId>spring-webmvc</artifactId>
			<groupId>org.springframework</groupId>
		</exclusion>
	</exclusions>
</dependency>

Un peu de code

Il va nous falloir un minimum de code supplémentaire qui va servir de glue entre Restlet, JAX-RS, Spring et mon conteneur de servlets.
Cette « glue » se limite à une classe :

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
30
31
32
33
34

@Component("jaxrsApp")
public class MyJaxrsApplication extends JaxRsApplication {
	@Autowired
	public MyJaxrsApplication(final ApplicationContext context) {
		super();
		add(new Application() {
			private Set<Class<?>> classes = new HashSet<Class<?>>();
			private Set<Object> singletons = new HashSet<Object>();
			{
				if (context.getBeansWithAnnotation(Path.class) != null)
					for (Object bean : context.getBeansWithAnnotation(Path.class).values())
						classes.add(bean.getClass());
				singletons.add(new JacksonJsonProvider());
			}
 
			@Override
			public Set<Class<?>> getClasses() {
				return classes;
			}
 
			@Override
			public Set<Object> getSingletons() {
				return singletons;
			}
		});
 
		setObjectFactory(new ObjectFactory() {
			public <T> T getInstance(Class<T> jaxRsClass)
					throws InstantiateException {
				return context.getBean(jaxRsClass);
			}
		});
	}
}

Je n’entrerai pas ici dans le détail du fonctionnement de Restlet – ce qui serait hors sujet -, néanmoins certains éléments nécessitent quelques précisions.
La classe Application est celle de la JSR-311 dont les méthodes getClasses et getSingletons sont censées retourner les classes ou singletons correspondant à des ressources REST ou des providers.
Il semblerait logique de fournir les ressources REST via la méthode getSingletons en allant les chercher dans le conteneur IoC de Spring. Malheureusement Restlet ne permet cela pour l’instant que pour les providers, les ressources devant nécessairement être fournies par la méthode getClasses.
Fort heureusement, la classe JaxRsApplication possède la méthode setObjectFactory qui va nous permettre de définir de quelle manière Restlet va instancier les classes renvoyées par la méthode getClasses.
Il faut ensuite configurer la servlet SpringServerServlet dans le web.xml en lui fournissant en paramètre le nom du bean Spring correspondant à l’application Restlet :

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

<servlet>
	<servlet-name>Restlet</servlet-name>
	<servlet-class>org.restlet.ext.spring.SpringServerServlet</servlet-class>
	<init-param>
		<param-name>org.restlet.application</param-name>
		<param-value>jaxrsApp</param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>
 
<servlet-mapping>
	<servlet-name>Restlet</servlet-name>
	<url-pattern>/*</url-pattern>
</servlet-mapping>

Conclusion

Nous voici arrivés à la fin de la première partie de ce tour d’horizon des implémentations JAX-RS.

Que peut-on conclure à l’issue de cette première partie ?

CXF est incontestablement très puissant, et justement trop en l’occurrence. D’un autre côté, si pour une raison quelconque je devais passer à une architecture hétérogène, je sais qu’un passage vers CXF serait parfaitement envisageable et que la transition se ferait sans douleurs, puisque consistant essentiellement en un travail de configuration Spring (certes rébarbatif).

Concernant Restlet, comme dit précédemment, ce n’est pas vraiment une utilisation normale du framework qui est proposée ici, celui-ci se positionnant plus comme une alternative à JAX-RS.

Jersey et RESTEasy offrent simplicité et performance et collent parfaitement à mes besoins.

A mon sens, le choix entre RESTEasy et Jersey dépendra en partie du choix du serveur d’application : si vous optez pour JBoss, RESTEasy offre des avantages certains.

D’un autre côté la communauté derrière le projet Jersey, dont la dernière version date de janvier, semble bien plus active que celle de RESTEasy.

Reste toutefois un point essentiel à aborder : les tests, que nous verrons dans un prochain article et qui pourraient bien faire pencher la balance.

En attendant vous pouvez déjà jeter un oeil aux sources.

Suggestion d'articles :

1. Les implémentations JAX-RS (2)
2. La stratégie de test d’une architecture REST (2/3) – Test d’intégration

En ce moment, on entend beaucoup parler de collaboratif, d’entreprise 2.0, de wiki, … et aussi d’Alfresco.

Logiciel libre, grosse communauté, architecture logicielle très proche de celle de Documentum mais avec des technologies plus récentes, Alfresco est une solution de gestion électronique de documents qui a semble-t-il tout pour plaire.

Cela dit tout le monde sait bien que la solution ultime et universelle n’existe pas et en vertu de cela je vous propose de faire une petite revue de l’adéquation entre des besoins courants et la manière dont Alfresco y répond, l’objectif étant de vous fournir un premier aperçu de ce qu’est Alfresco.

Cet article n’a pas pour but de vous « vendre » ou de vous décourager d’utiliser Alfresco mais simplement de donner un aperçu des possibilités du produit. N’hésitez pas à me faire part de vos remarques, demandes d’informations, …

J’ai besoin de stocker mes données de façon organisée.

Si votre besoin s’arrête à cela, un partage NFS ou CIFS sera amplement suffisant.

Si par contre vous avez besoin « d’intelligence » dans cette organisation des données, Alfresco pourrait répondre à votre besoin car il intègre un mécanisme d’orchestration d’actions qui peuvent se déclencher lorsque l’on touche à son dépôt de données. Pour faire simple il est possible d’enchaîner des actions à l’ajout, la modification ou la suppression d’une donnée sur le dépôt. Ces dernières pouvant aller de la simple copie à la transformation d’un format à un autre en passant par la notification automatique des ayant droit sur la donnée.

J’ai besoin de capitaliser sur une base de connaissances.

Cela tombe bien, Alfresco est justement avant tout une solution de gestion documentaire !

Dans Alfresco, toute donnée ajoutée est stockée en un point bien identifié sur un support de stockage de masse. La suppression d’une donnée ne la supprime pas du support mais la met en quinzaine voire plus longtemps si vous préférez. De cette manière, vous limitez le risque de perte accidentelle d’information.

J’ai besoin de mettre en place des workflows complexes des directions métiers sur les données stockées.

Alfresco utilise le moteur de workflow JBPM ce qui lui permet de traiter des workflows allant de la simple validation d’un document par un tiers à des processus complexes entièrement modélisés avec jBPM Process Designer par exemple.

En outre, les mécanismes d’orchestration d’actions sur le dépôt de données permettent de transformer, déplacer, copier, envoyer par courriel, … toute donnée stockée sur Alfresco.

J’ai besoin de pouvoir enrichir les données stockées.

Alfresco repose entièrement sur un mécanisme de modèle de données. Toute donnée stockée, des utilisateurs et leurs droits d’accès aux documents en passant par les répertoires sont des éléments d’un modèle de données.

Je dis ‘un’ et non ‘le’ parce que la solution est faîte de sorte que les développements spécifiques, les besoins métiers tels que l’enrichissement des données stockées sont effectués sous la forme de l’adjonction de modèles de données personnalisés au modèle livré d’origine.

Et puis de toutes façons, même d’origine, il y a déjà plusieurs modèles de données dans Alfresco à savoir :

• un pour les types de données comme les répertoires, les images, les documents;
• un pour les habilitations;
• un pour les workflows.

Enrichir est quelque chose de naturel et facile à effectuer pour Alfresco.

J’ai besoin de gérer finement les droits d’accès à mes données.

Si les habilitations par défaut ne conviennent pas, Alfresco permet de définir son propre modèle de permission. Autrement, sachez que les accès peuvent se gérer au niveau donnée, au niveau répertoire, que des quotas utilisateurs peuvent être appliqués.

En outre, Alfresco gère des rôles. Mais qu’est ce qu’un rôle ? Juste un ensemble de permissions. On affecte des rôles à des utilisateurs ou des groupes d’utilisateurs par donnée ou par répertoire.

Par défaut, les rôles suivants sont proposés, libre à vous de les enrichir :

• administrateur;
• coordinateur;
• collaborateur;
• contributeur;
• éditeur;
• lecteur.

Nous pourrons en parler plus longuement dans un autre article.

J’ai besoin d’avoir un accès distant à mes données.

Alfresco propose plusieurs méthodes d’accès aux données.

L’interface web-client

Interface web historique du produit, elle n’évolue plus aujourd’hui. Cette interface présente plusieurs particularités :

• accès quasi-exhaustif aux fonctionnalités de l’outil ce qui la rend inutilisable pour un utilisateur lambda;
• panneau d’administration bien fourni (gestion des groupes, des utilisateurs, des rôles, du dépôt, des workflows, …);
• capacité à être adaptée moyennant un peu de configuration (des xml à modifier et écrire peuvent influer sur tous les boutons de l’interface);
• doit tourner sur la même instance que le coeur d’Alfresco, la partie gestion documentaire.

Je vous déconseille d’utiliser cette interface sauf pour des besoins d’administration. Pour les métiers, il vaut souvent mieux développer une interface correspondant aux attentes se basant sur les API d’accès distant d’Alfresco.

L’interface share

Share est le nouveau client léger proposé par Alfresco. Il s’agit d’un site collaboratif orienté utilisateurs et non administrateur. Pas de panneau d’administration donc mais un fonctionnement sur le mode d’un portail comme Liferay consommant des services provenant du coeur d’Alfresco au travers de l’API REST.

API REST et SOAP

Alfresco expose ses fonctionnalités sous la forme d’une API REST eǵalement appelée Webscript et d’une API SOAP.

Ces deux API sont très complètes et permettent de concevoir des interfaces client léger ou lourd qui tourneront sur un serveur autre que le serveur de gestion documentaire, lui permettant ainsi de se concentrer sur sa tâche principale, la gestion documentaire.

L’API CMIS

Dernière née des API disponibles pour communiquer avec Alfresco, CMIS a été implémenté dans Alfresco 3 dans un effort d’intéropérabilité des accès aux dépôts de solutions de gestion documentaire. Concrètement, cette norme défini une interface standard pour accéder à un dépôt documentaire qu’il soit sous Alfresco, sous Sharepoint ou d’autres.

JCR et JCR over RMI

Si vous en avez besoin (intégration Liferay par exemple), le dépôt Alfresco implémente la norme JCR (JSR-170). Cette dernière peut être accédée en local ou au travers de RMI. Cependant, cette méthode est déconseillée par Alfresco qui mets plus l’accent sur le REST et sur l’API CMIS.

Actuellement nous avons un projet de plateforme collaborative basée sur Alfresco chez un client et ce dernier y est utilisé comme socle pour la gestion documentaire.

Dans les besoins exprimés, trois grandes catégories ont été dégagées :

• les besoins d’administration de la plateforme;
• les besoins d’accès à des données enrichies par le métier au travers d’une interface très ergonomique et graphiquement léchée;
• les besoins de type portail favorisant un travail collaboratif.

Ces trois types de besoins se retrouvent dans les modes d’accès proposés par Alfresco. L’administration est donc assurée par le panneau d’administration de l’interface web-client, les accès aux données enrichies par le métier se font au travers d’une interface REST consommée par un client léger Flex répondant aux attentes d’ergonomie et de graphisme et les besoins de type portail collaboratif sont traité avec l’interface share qui nous fourni une plateforme sur laquelle nous pouvons agencer des composants existants et ajouter ceux dont la partie métier requiert un développement spécifique.

Au final, nous obtenons un ensemble cohérent, performant et évolutif et nous avons gagné du temps par rapport à un développement spécifique à 100%.

Je veux intégrer Alfresco avec le portail Liferay.

Nous avons eu un demande de ce type pour un client qui voulait utiliser Alfresco avec Liferay comme portail.

Bien qu’Alfresco prétende qu’il s’intègre très bien avec Liferay, en pratique, nous avons constaté qu’il ne s’agit pas d’une intégration mais plutôt d’une communication. En fait, la norme portlet permet d’intégrer des contenus récupérés sous la forme de code HTML. C’est ce qu’Alfresco propose avec quelques portlets codées grâce à son API Webscripts mais elles sont surtout là en temps que preuve de concept que les Webscripts peuvent retourner des contenus HTML intégrables dans Liferay au travers d’une portlet de type iframe.

Charge donc à votre équipe de développement de concevoir les portlets et éventuellement des services REST côté Alfresco pour réaliser l’intégration. C’est la conclusion à laquelle nous en sommes venu eu égard aux besoins métiers du client et à l’inadéquation des Webscripts proposés par défaut. Cela dit, il était quelque peu prévisible qu’Alfresco ne prévoit pas le besoin spécifique demandé par notre client. L’essentiel ici est qu’Alfresco propose tout l’outillage nécessaire pour réaliser cette communication facilement et rapidement. En outre, si vous souhaitez que Liferay utilise Alfresco comme fond documentaire, c’est possible puisque les deux sont compatibles JCR (JSR-170).

J’ai l’obligation de m’interfacer avec l’annuaire d’entreprise et je ne veux pas de mécanisme de provisioning tiré par les cheveux.

Aucun problème ! Alfresco repose sur la LDAPFactory standard de la JVM. De fait, il supporte parfaitement l’intégration avec un annuaire LDAP, que ce soit AD, OpenLDAP ou un autre.

Certains annuaires ont des champs non standards. Alfresco gère facilement cela au niveau de ses fichiers de configuration.

Le provisioning par défaut est de créé un compte à la racine du dépôt. Cela peut être paramétré facilement et si un provisioning plus complexe est à mettre en oeuvre (création de dossier personnel et copie de données, …). Alfresco propose un mécanisme de modèle de dossiers et permet aussi de tout simplement développer une classe de provisioning spécifique.

Le déprovisioning par défaut est de ne pas supprimer le dossier personnel. Là encore, ce comportement peut être facilement modifié en modifiant la classe implémentant le mécanisme de déprovisioning.

Les opérations de synchronisation dans Alfresco sont ordonnancées par quartz. Ce dernier permet de configurer la fréquence des synchronisations tout comme dans une crontab standard.

En outre, Alfresco supporte plusieurs annuaires et fait une distinction entre synchronisation des utilisateurs et synchronisation des groupes. De cette manière, il est facile d’adapter sa configuration aux contraintes du SI.

Enfin, si vos annuaires limitent le nombre de réponses possibles, Alfresco, à partir de sa version 3.2 et dès maintenant dans la version labs supporte la pagination des requêtes LDAP.

Quartz ? Mais je ne veux pas de mécanisme d’ordonnancement interne dans les applications de mon système d’information

Pas de problème, Quartz est fourni par défaut et est configuré grâce à des beans Spring. Moyennant un peu de configuration et probablement quelques développements pour certaines tâches ne disposant pas de service REST ou SOAP exposé, il est tout à fait possible de le désactiver et de d’insérer ses tâches dans votre ordonnanceur central.

À titre d’exemple, nous avons failli le faire à un moment pour un client souhaitant que la synchronisation LDAP soit effectuée par son ordonnanceur central. Il faut savoir que dans Alfresco la synchronisation LDAP se fait en deux temps :

• extraction du contenu à synchroniser et création d’un fichier XML représentant les utilisateurs, groupes, …;
• insertion de ce contenu dans Alfresco.

Nous avons donc deux tâches, deux classes et un XML dont la structure est connue.

Pour sortir la synchronisation du produit, il suffisait de :

• coder un petit script aux normes de l’ordonnanceur central qui générerait l’XML attendu par Alfresco;
• l’insérer dans Alfresco en exécutant un programme Java d’import fourni dans le WAR d’Alfresco.

Petit problème cependant, ledit programme JAVA requiert de couper le serveur Alfresco durant la mise à jour… Pas de problèmes là non plus, il suffit alors de coder le service REST manquant pour effectuer l’import et plus besoin de couper le serveur. Ce service est assez simple puisque toute la mécanique d’import étant déjà présente dans Alfresco, il n’a qu’à récupérer un fichier XML.

La sécurité me demande des flux en ‘s’ partout.

Aucun problème, les flux LDAPS ou HTTPS sont parfaitement supportés.

Je dois mettre en place du SSO en interne et une connexion LDAP en externe.

Kerberos, NTLM, CAS, JAAS faîtes votre choix, le chaînage d’authentification est également supporté dans le cas où, par exemple, un accès extranet est mis en place avec un couple login/mot de passe et qu’un accès intranet utilise Kerberos.

Je veux une solution fonctionnant en grappe.

Alfresco est prévu pour ce type de configuration. L’effort de configuration spécifique est donc minimal.

En revanche, il faut savoir que si le mode grappe est supporté par défaut pour les instances d’Alfresco, toutes les instances doivent utiliser la même base de donnée et le même dépôt de données.

Base de données ? Mais je croyais que tout était sur un support de stockage !

En effet, c’est le cas pour toutes les données ayant un contenu.

Les utilisateurs, les répertoires (mais pas leur contenu), les méta-informations que vous avez utilisé pour enrichir vos données et vos workflows sont stockés sur une base de données qui en pratique n’est pas très chargée. Un simple MySQL suffit amplement.

Quels sont les bases de données supportées ?

Oracle, MSSQL, MySql, PostreSQL, Derby, … Le choix est large. De plus, la charge sur la base est minimale, Alfresco n’utilisant pas de schémas complexes et reposant massivement sur son indexeur, sur Hibernate et sur EHCache.

Et pour le stockage, quels sont les pré-requis ?

Le dépôt de données à besoin d’un support ayant surtout une capacité de stockage en accord avec vos besoins.

L’indexation des données représente en moyenne 30% du volume total de données stockées sur le dépôt. De plus, l’indexation étant effectuée sur un support de stockage (Lucene est la technologie utilisée), il est plus que recommandé d’utiliser un disque très rapide supportant les opérations de vérrouillage de fichiers).

Je veux segmenter mes données sur plusieurs dépôts.

Alfresco est aussi prévu pour ce type de configuration bien que l’exercice soit un peu plus complexe à configurer. En outre, vous avez toujours une seule base de données possible et donc la procédure de sauvegarde doit prendre en compte le fait que pour une base de données, deux dépôts physiques devront être sauvegardés.

Dans le cas où vous auriez en tête une partie interne ayant tout le dépôt et une partie externe, exposée sur internet qui ne doit avoir qu’un sous ensemble de données et en lecture seule, sachez que pour Alfresco ce n’est qu’un cas particulier d’une configuration en mode grappe. En pratique, il s’agit de mettre l’instance « lecture seule » en mode grappe avec l’instance accès complet et de configurer son index pour qu’il ne traite qu’un sous ensemble des données.

Nous avons récemment rencontré un cas similaire à Octo et notre solution a été une troisième voie qui évite la mise en place d’un second serveur Alfresco; consommer un service REST côté Alfresco permettant de récupérer ledit sous ensemble de données qui est marqué par un tag.

Je veux une solution simple à déployer et à mettre à jour.

Actuellement, Alfresco ne fonctionne qu’avec tomcat. L’application est livrée sous la forme d’un WAR que vous déployez et c’est tout !

Si vous souhaitez le faire fonctionner sur Jetty, Jboss, ou encore Websphere, un effort de développement est à prévoir pour corriger les bugs empêchant la portabilité du produit.

Je veux un traçage fin des évènements.

Alfresco dispose d’un mécanisme d’audit qui, une fois activé, permet de suivre à la trace les évènements sur chaque objet du dépôt. À configurer avec précaution pour éviter de faire exploser la taille de la base de données et de trop ralentir le serveur.

Je veux un socle extensible.

Basé sur Spring avec les mécanismes exposés plus haut, Alfresco est particulièrement adapté si vous souhaitez l’utiliser comme un socle sur lequel prendront place des projets métiers nécessitant de capitaliser sur les informations.

J’ai besoin d’un wiki.

Alfresco s’interface avec mediaWiki. Toutefois, si votre besoin de limite au wiki, il peut être plus intéressant de n’installer que mediaWiki et de le relier éventuellement à Alfresco plus tard, le jour où le besoin de mise en place de ce dernier sera réel.

J’ai besoin de solutions collaboratives avec un client léger.

Alfresco propose des interfaces web tels que share. Cependant, il ne couvre pas tous les besoins et surtout son développement peut être fastidieux. En effet, ce n’est pas le domaine où Alfresco excelle, pas le portail collaboratif aussi il vaut mieux considérer un interfaçage d’une solution collaborative plus poussée avec Alfresco au travers de REST ou de SOAP.

Le mieux est encore de profiter des possibilités de communication offertes avec Alfresco et de mélanger les types d’accès en fonction des besoins. Comme expliqué plus haut, cela nous a permis de répondre efficacement à un besoin client récemment.

Je veux que mes équipes soient rapidement opérationnelles pour mes développements spécifiques.

La nature extensible et libre d’Alfresco est particulièrement adaptée pour une prise en main assez rapide. De plus, une véritable communauté est présente notamment au travers des forums et l’architecture logicielle propre et claire du produit fait que le recours au support développement n’est pas souvent nécessaire même pour un développeur Java junior.

Attention tout de même, il est important de connaître Spring, Java 6 et tomcat pour pouvoir rapidement prendre en main le produit.

Je veux faire de l’Agile.

C’est tout à fait possible et c’est ce qu’Octo fait chez ses clients. Toutefois, sachez qu’appliquer strictement du TDD (développpement dirigé par les tests) avec Alfresco peut parfois se révéler être une tâche ardue, la totalité du code n’étant pas couvert par les tests et l’execution des tests unitaires demandant le lancement d’une mini instance d’Alfresco. Une personne expérimentées sur Alfresco est alors un bon moyen d’éviter bien des pertes de temps.
Nous avons rencontré pas mal de problèmes pour mettre en place les tests unitaires REST avec Alfresco à cause de quelques loudeurs comme la nécessités de lancer un mini Alfresco pour effectuer les tests unitaires. Cela dit, dans 80% des cas, les tests unitaires n’ont pas posé de problèmes et le produit étant libre, cela facilite et accélère grandement le dépannage en cas de blocage ce qui n’est pas négligeable.

Suggestion d'articles :

1. Architecture Dynamique basée sur la solution Grails
2. La fédération d’identité en entreprise
3. Tours JUG – Apache Maven, mise en œuvre en entreprise

Introduction

Le versioning de service est un thème à part entière dans les architectures orientée service tant il structure l’évolutivité d’un service. Les architectures REST n’échappent pas à la règle. Posant les principes généraux de l’architecture, Roy Fielding n’en a pas pour autant décrit tous les méandres. Il n’appartient donc qu’à nous, développeurs et architectes, de définir ce qu’est le versioning des services REST en respectant ces principes. Ce billet traitera donc la problématique de versioning des services REST.

Quand versionne-t-on ?

Les types de changement

Il existe différents types de changements

• On peut être amené à modifier des règles métiers soit parce qu’elles évoluent, soit parce qu’elles sont « bugfixées ».
• On peut être amené à enrichir la signature du service pour répondre à de nouveaux besoins.

Souvent le premier cas n’a pas d’impact sur la signature du service et nous le laisserons volontairement en dehors du scope de cet article même si quelques problématiques de versioning se posent.

Dans le second cas, les évolutions de signature (c’est-à-dire principalement des paramètres d’appels et de réponse) peuvent être soit compatible avec les versions antérieures soit incompatibles.

Changement compatible

Ce sont les changements qui respectent le principe de compatibilité ascendante. Ces changements n’ont aucun impact sur les clients existants, pour peu qu’ils soient correctement implémentés.

C’est-à-dire qu’il respecte les pratiques suivantes :

• Le client ne doit pas tenir compte de l’ordre des éléments dans une représentation (XML par exemple)
• Le client ne doit pas échouer lorsque des éléments sont rajoutés dans une représentation (XML par exemple)
• Le client ne doit pas échouer lorsque de nouveaux codes retours sont ajoutés
• Le client d’une représentation ne doit pas échouer lorsqu’une nouvelle représentation est ajoutée

Par exemple, pour une ressource Album représentée en XML :

1
2
3

<album>
<title>Dark Side of the Moon</title>
</album>

L’ajout d’un champ ne modifie en rien la structuration précédente du message.

1
2
3
4

<album>
<title>Dark Side of the Moon</title>
<artist>Roger Waters</artist>
</album>

Les clients existants ne doivent pas être impactés.

Les changements incompatibles

Les changements dit incompatibles impactent directement les clients existants. Sur l’exemple précédent, si un ou plusieurs clients utilisent l’élément « artist », le fait de passer d’un artiste par album à une liste d’artistes par album rend cet élément inutilisable par ces clients.

1
2
3
4
5
6
7

<album>
<title>Dark Side of the Moon</title>
<artists>
<artist>Roger Waters</artist>
<artist>David Gilmour </artist>
</artists>
</album>

Un client, même codé selon les règles de l’art du parsing XML, ne pourra pas absorber la modification. (nom, granularité, type, …)

Quand versionner une représentation ?

Les changements compatibles correspondront donc à un changement mineur, les changements incompatibles seront des changements majeurs. Ce sont ces derniers qui obligent une montée de version du service. On changera donc de version lorsque qu’un changement de comportement du service entraîne :

• un changement incompatible
• la création d’un lien vers une nouvelle ressource
• la dépréciation d’une ressource.

Le versioning en REST

Il existe plusieurs moyens de versionner.

Le versioning via URL

La première réponse à ce problème de versioning a été de rajouter un paramètre identifiant la version dans l’URL de la ressource.

Par exemple la version 1 d’une ressource album avec une représentation XML :

1
2
3
4
5
6

GET http://.../v1/albums/12133
 
<album>
	<title>The dark side of the moon</title>
	<artist>The pink floyds</artist>
</album>

Et la version 2 de la même ressource album avec une représentation XML aussi :

1
2
3
4
5
6
7
8
9
10
11

GET http://.../v2/albums/12133
 
<album>
	<title>The dark side of the moon</title>
	<artists>
		<artist>Roger Waters</artist>
		<artist>David Guilmour</artist>
		<artist>Nick Mason</artist>
		<artist>Rick Wright</artist>
</artists>		
</album>

Ce versioning est inspirée du modèle SOAP où la version est portée dans l’adressage du service. A chaque nouvelle version d’un service on définie une nouvelle URL et un nouveau schéma WSDL associé.

Cette approche ne nous satisfait pas sur plusieurs points :

Rupture avec les principes REST :

La plus importante est que cette approche est en rupture avec un des principes de REST : une ressource est identifiée par une URI sous entendu durable et stable dans le temps
L’introduction de la version dans l’URI implique de définir une URI différente par version de la ressource maintenue par le serveur.
Dans l’exemple précédent deux URI permettent d’accéder à la ressource Album.

De plus cette approche donne l’impression aux utilisateurs que l’album dans une version de l’API est une ressource différente du même album dans une autre version. Hors, ce qui a changé ici n’est pas la ressource mais une de ces représentations (la représentation au format XML pour être complet).

Exposition de paramètres techniques :

Cette approche rend visible directement au client une partie de la complexité de la gestion des versions de l’API.
En effet, nous faisons apparaître dans l’URI un paramètre purement technique, le numéro de version, alors que l’URI représente la dénomination fonctionnelle et unique de la ressource.

Best practice REST

« Content negotiation »

Une autre approche qui s’appuie sur le mécanisme de négociation de contenu du protocole http réponds entre autre à ces limitations. Revenons en deux mots sur la négociation de contenu : ce mécanisme permet à un client d’une ressource web de spécifier quelle(s) représentation(s) il préfère obtenir.

Techniquement parlant cette information se trouve dans la requête http dans une entête appelée Accept header. Voici un exemple de requête avec négociation de contenu :

1
2
3

GET http://... /albums/12133
Accept : text/xml, application/json 
…

Le serveur répondra de préférence un fragment XML, s’il le gère, une structure de données JSON dans le cas contraire.
Les types définis dans l’Accept header peuvent être soit des media types standardisés soit des types personnalisés.

Versioning par Accept

Selon la philosophie REST le client spécifie dans sa requête la représentation de la ressource à laquelle il souhaite accéder. Ceci est fait au travers du mécanisme de négociation de contenu explicité ci-dessus.

Ce mécanisme permet donc de véhiculer les informations liées aux différentes versions de l’API. Le client spécifie dans le Accept Header quelles sont les versions d’une représentation d’une ressource qu’il souhaite avoir, par ordre de préférence.

La gestion des versions de service REST au travers de ce mécanisme a un prérequis : l’introduction de media types non standard.

Si nous reprenons l’exemple du versioning précédent les types créés seront :

• application/vnd.octo.music-v1+xml associé au schéma XML de la version 1 de la représentation XML de l’album
• application/vnd.octo.music-v2+xml associé au schéma XML de la version 2 de la représentation XML de l’album

Par exemple la requête pour accéder à la version 1 de la ressource album avec une représentation XML :

1
2
3
4
5
6
7

GET http://.../albums/12133
Accept : application/vnd.octo.music-v1+xml 
 
<album>
	<title>The dark side of the moon</title>
	<artist>The pink floyds</artist>
</album>

Et la requête pour accéder à la version 2 de la ressource album avec une représentation XML :

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

GET http://.../albums/12133
Accept : application/vnd.octo.music-v2+xml 
 
<album>
	<title>The dark side of the moon</title>
	<artists>
		<artist>Roger Waters</artist>
		<artist>David Guilmour</artist>
		<artist>Nick Mason</artist>
		<artist>Rick Wright</artist>
</artists>		
</album>

Conclusion

La principale solution apportée au problème de versioning de services REST a été d’introduire le numéro de version dans l’URI. Nous lui préférons la solution utilisant la négociation de contenu et le versioning de représentations plus que ressources.
Ceci pour plusieurs raisons :

• Le versioning via URI enfreint un des principes fondamentaux de REST : Une URI  Une ressource
• Dans la philosophie REST les échanges sont pilotés par le client, c’est le client qui sait quelle représentation il peut manipuler. Ceci autant pour le format des données (xml, json, html, …) que pour la version de ces données. Ces deux cas doivent être traités au travers du même mécanisme : la négociation de contenu et le champ Accept Header.
• La négociation de contenu permet au client de définir les versions de représentation qu’il souhaite recevoir par ordre de préférence
• Les principaux framework REST offrent des fonctionnalités natives de gestion de contenu coté client et serveur

Dans un article futur nous pourrons décrire l’architecture technique/applicative impliquée par la gestion de versions via Accept Header. Nous pourrons ainsi répondre aux questions : Comment mettre à disposition une nouvelle version d’un service ? Comment supporter coté serveur deux versions majeures d’un service en même temps ? Comment connaître les versions utilisées par les clients du service ?

Benoît Guillou & Benjamin Magnan

Suggestion d'articles :

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

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

Lorsqu’on parle de ressource et de REST en général, on associe souvent la notion de services, une représentation XML ou JSON d’un résultat, d’une donnée…On ne pense que rarement à la notion de ressource comme pouvant retourner une IHM ou une portion d’IHM, c’est-à-dire, de la donnée mise en forme.

Ici, l’idée est simple : utiliser des ressources REST – proposant une représentation HTML – pour agréger et construire une nouvelle IHM côté client, dans le navigateur.

Une caractéristique intéressante de REST et des ressources est ce que l’on appelle la représentation ; la possibilité de fournir la même donnée sous des formats différents. Il est possible de spécifier le format dans l’url ou dans des en-têtes http. Peu importe en fait, la même donnée peut être fournie à la fois sous la forme XML, JSON et pourquoi pas HTML.

Comme dirait l’autre :  » y a plus qu’à « …alors utilisons une page HTML  » maitre  » qui agrège, au niveau du navigateur, des ressources REST ; à la fois un flux HTML, et une image qui dans notre exemple sera dynamiquement générée par Google Chart :

La page  » maitre  » fournit simplement un champ de saisie dans lequel l’utilisateur saisit un identifiant client. Les ressources GuiRessources et GoogleCharts sont alors demandées…La ressource GuiRessource retourne un fragment HTML qui permet de présenter un détail de personne (ici son nom, son adresse…) le tout mis en forme (dans cet exemple, simplement l’utilisation de type  » bold « ). La ressource est simplement implémentée comme suit (avec Jersey) :

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

@Path("/GuiRessource")
public class GuiRessource {
 @GET
 @Produces("text/html")
 @Path("/{id}")
 public String getGui(@PathParam("id") String id) {
  Client client = this.getClient(id);
  StringBuffer buffer = new StringBuffer();
  buffer.append("client id: ");
  buffer.append(id);
  buffer.append("
<div id="">  buffer.append(client.getPortefolio1());
  buffer.append("</div>
");
 
  buffer.append("
<div id="">
 
  //etc
  buffer.append("</div>
");
 
  return buffer.toString();
 }

Je vous passe la configuration du web.xml afin de prendre en compte la servlet Jersey. Etant une ressource, cette dernière peut facilement être requêtée, typiquement dans un navigateur. Dans notre exemple, voilà ce que ca donne pour la ressource cliente identifiée par le nombre 3.

La seconde ressource est en fait basée sur Google Chart. Il y a peu à dire…Google Charts affiche des graphiques différent suivant l’url spécifiée. Il est ainsi possible de spécifier le type de graphique, bien entendu les données du graphique…(saisissez cette url http://chart.apis.google.com/chart?cht=p3&chco=339933&chs=450×150&chd=t:10,50&chl=Class1|Class2| dans votre navigateur préféré…).

Reste alors à agréger tout cela, et c’est presque uniquement du JavaScript (en même temps vous étiez plus ou moins prévenu…)

1
2
3
4
5
6
7
8
9
10

 
<script src="..."><!--mce:0--></script>
 
clientId :
<input id="clientId" type="text" />
<div id="GuiRessources" style="background-color: #dddddd">  Gui Ressources</div>
<div id="results"></div>
<div style="float: left;">
 <img id="chart" src="&lt;a href=" alt="" />http://chart.apis.google.com/ "
 class="totable" /&gt;</div>

Le code de la page maître propose 3 grandes parties :

• Une méthode loadRessource() qui réalise un GET sur la ressource Client
• Une méthode reloadChart() qui provoque l’accès à Google Chart et l’affichage du graphique
• Une partie HTML qui permet l’affichage du champ de saisie du clientId et qui provoque l’appel aux méthodes précédentes sur la perte de focus.

A l’exécution, les ressources interagissent, l’intégration se réalise et donne lieu aux écrans suivants :

Il s’agit là d’une façon simplissime d’intégrer de l’IHM au niveau du navigateur et de proposer des ressources ayant potentiellement une représentation au format HTML et donc une mise en forme partageable, réutilisable.

Reste à ne pas tomber dans les extrêmes…

Suggestion d'articles :

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

Devoxx: Dev comme Développeur, Voxx comme voix…en bref, la voix du développeur.
C’est ainsi que débute la keynotes de la première édition de Devoxx, en fait la Nième du plus connu Javapolis et pour illustrer cette « voix », rien de mieux que celle d’un beat boxer ; franchement terrible !

javaFX à l’honneur de la Keynote

De la keynote matinale, l’envie est de ne retenir que la présentation sur JavaFX. Ils voulaient nous faire rêver mais on a vu des applications embarquant des vidéos…bref difficile d’imaginer de applications de gestion. JavaFX semble être une réponse de Sun au Adobe de Flex mais il reste quelques limitations:
- La plateforme. Là où Flex fonctionne sur un plugin présent sur une immense majorité des navigateurs, javaFX nécessite un JRE, une JVM
- Les nouvelles versions de JavaFX propose de faciliter l’intégration avec des outils classiques des designers comme PhotoShop et Illustrator. Reste que l’intégration avec Flex sera trés certainement plus évidente ne serait-ce que parce qu’il s’agit de la même compagnie et qu’ils ont bien compris cet enjeu de rapprochement des développeurs et des designers
- On pourrait penser que JavaFX présente l’avantage du langage Java – massivement maitrisé -. Mais en fait javaFX est aussi proche de Java qu’ActionScript.

Java7 et les APIs concurrentielles

L’implémentation qui a été faite des Threads depuis la première version de Java jusqu’à Java5 permettait de gérer l’asynchronisme plus que le parallélisem; ie. l’utilisation des multi coeurs. Java 5 introduit les Executor et les Tasks pour faciliter ce découpage en tâche d’assez haut niveau. java 7 veut utiliser au maximum les avancés des processeurs et faciliter la résolution de tâche qui peuvent être parallélisée au niveau d’une JVM (on ne parle pas ici de système distribué…). Les Apis fork/join facilite les opérations de tri de tableau, parcours d’arbre…Cette session est également l’occasion de découvrir comment fonctionne les piles dans ce type d’implémentation, un mécanisme de « work stealing » où chaque Worker Thread gère sa pile en FIFO et où les Worker Thread « amis » ont le droit de dépiler la pile des autres en FILO…

Et si le futur des RIAs était à Flex?

Autant vous le dire tout de suite, la session est « sponsorisé » par Adobe :o) mais sera l’occasion de voir de surprenantes démonstrations, de celles qui font imaginer de nouveaux patterns d’usabilité mais égalemnet d’apprendre quelques nouveautés de la prochaine mouture de Flex : Gumbo.
- le rapprochement Designer/Développeur. Des initiatives comme Catalyst, un nouveau format de fichier qui permet d’exporter/importer des fichiers d’outils comme Photoshop ou Illustrator vers Flex
- des améliorations de l’existant qui permettent de mieux séparer le code de logique de la définition du visuel; ie Spark Component Architecture. La définition du visuel peut se faire dans une sorte de fichier XML où l’on peut définir l’ensemble des comportements visuels des composants graphiques)
- des améliorations du modèle d’animations qui permettent la 3D, l’ajout d’effets. Ces améliorations sont principalement possibles grâce aux évolutions de la plateforme d’exécution: le player Flash
- le rapprochement de Spring, l’idée étant de faciliter l’intégration de plateforme type BlazeDS ou Lifecycle (pour son « presque équivalent » commercial)
- la nouvelle version du Flex Builder qui outille le développement jusqu’à faciliter le binding de table sur des DataGrid.

Quelques sessions sur JEE6

Une présentation de JPA 2.0 qui s’enrichi par rapport à sa précédente version.
- les options de mapping (nouvelles possibilités sur les jointures, PK…)
- la gestion des locks optimistes ou pessimistes. Certaines APIs évoluent également et permettent de mutualiser des opérations comme la sélection de l’objet et son lock…
- JP-QL reprend le principe des Criterias déjà présents dans Hibernate ou comment créer dynamiquement une requête

Et Web Beans qui cherche à standardiser Seam et cherche à proposer une couche de liant au dessus des composants déjà présents dans JEE (EJB, JSF Managed Bean…). L’idée principale reste de pouvoir agencer, l’ensemble de ces composants via des annotations spécifiques, le tout en masquant le composant Java; ie EJB, Java Bean, JSF Managed Bean. L’envie de standardisation va un peu plus loin en gérant les notions de scope (classiquement un scope session, request…) et en proposant des mécanismes – au final complexes – permettant de remplacer au déploiement les implémentations à utiliser.

C’est séduisant mais cela parait complexe…

Silverlight

Une assistance beaucoup moins nombreuse que pour la sesssion Flex. Pourtant ces deux sessions se sont beaucoup ressemblées :
- des widgets graphiques impressionants comme le « deep zoom »
- un fort accent sur la relation designer/développeur
- des outils de dévéloppements productifs (Visual Studio ou eclipse pour les uns, Expression Blend ou la suite Adobe pour les autres)
A noter : la possibilité d’utiliser un panel de langage de développement (C#, vb.NET ou ruby).

Un nouvel acronyme : le BDD ou Behaviour Driven Desgin (et non pas Business Driven Developpement :o) )

L’idée générale : « du TDD où le test est écrit via un DSL ». Cette approche rejoint celle poussée par les méthodes agiles et le pilotage par les tests: décrire fonctionnellement le système avant même de savoir comment il sera implémenté.
Il s’agit alors de décrire le test via un langage plutôt fonctionnel (Given, when, then) et d’y ajouter des closures (qui jouent le rôle de fixtures dans des solutions comme Greenpepper ou Fitnesse) permettant de s’interfacer avec le « System Under Test ». De la même manière, les assertions disposent d’une sémantique plus riche du type shouldBe plutôt qu’un simple assertEquals.

C’est un peu le même principe que des Fitnesse et des GreenPepper; à l’exception du wiki et en imaginant que le code des fixtures est fusionné avec la description fonctionnelle du test.

Des patterns et anti-patterns REST

Une session intéressante qui repose les points importants de REST :
1) Tout à un identifiant matérialisé par une URI
2) Lier les ressources les unes aux autres
3) Utiliser les verbes GET/POST/PUT/DELETE et donc éviter le « tunneling » sur POST et GET
4) Une ressource peut avoir plusieurs représentation (en conservant l’URI)
5) L’architecture REST est par essence sans état (Stateless)

L’objectif principal étant d’utiliser au maximum les possibilités du protocole HTTP et les services offerts par l’infrastructure comme les mécanismes de cache, de proxy ou d’indexation par des moteurs de recherche par exemple. Une piqure de rappel pragmatique qui fait du bien sans attaquer SOAP.

Envers (sans jeu de mot) et le versionning d’objet

Un framework s’intégrant nativement à hibernate et permettant par annotation de versionner les objets et de réaliser en quelque sorte une piste d’audit (ajout de metadata). Il devient alors possible de requêter un objet dans une certaine version, de savoir qui a modifié quelle propriété : un SVN pour Hibernate ;-).
Une limitation soulevée pendant la présentation reste l’augmentation des accès/écritures en base. A chaque modification, insertion de la version principale de l’objet, une insertion est réalisée pour conserver les modifications.

Voilà pour l’essentiel de la journée. Stay tuned!

By Fabrice Robini, Benoit Lafontaine, Olivier Mallassi

Suggestion d'articles :

1. Last day @Devoxx
2. Another day @ Devoxx
3. Les grandes tendances de Devoxx 2011

Cet article est la première partie d’une série de posts concernant la sécurité des services web.

Nous allons présenter dans cette première partie un aperçu de la norme WS-Security pour les services SOAP et les différentes possibilités pour sécuriser des services web.

Les architectures SOA se sont généralisées petit à petit au sein des entreprises pour construire des systèmes capables d’offrir des fonctionnalités partagées via des services.

Ces services peuvent être internes et ne concerner qu’une organisation ou être ouverts sur l’extérieur dans le cadre d’échanges B2B.

Dès lors que l’on propose de la valeur ajoutée ou transporte des données dites sensibles, ces services sont alors confrontés à des buts contradictoires :

• Exposer de l’information et la rendre facilement accessible à un tiers (personne ou système)
• Sécuriser l’information pour la rendre uniquement consommable par des personnes ou des systèmes habilités à la voir et à l’utiliser.

La sécurité est au cœur des préoccupations des entreprises pour garantir la cohérence et la pérennité des systèmes. Pour ce faire, la sécurité doit être prise en compte dès la conception des services web et ceci à tous les niveaux :

• Conception, spécification
• Architecture
• Développement
• Déploiement
• Exécution & exploitation

Au-delà du tout sécuritaire, une approche pragmatique de la sécurité pilotée par les risques est préférable. Rappelons les fonctions de sécurité disponibles qui pourront s’appliquer à des services:

• Authentification : le mécanisme qui permet de vérifier l’identité d’une personne/d’un système
• Habilitation : le droit d’accéder ou non à une fonctionnalité, à une donnée
• Intégrité (ou signature) : la non modification d’une donnée échangée
• Imputabilité : traçabilité des actions d’un individu sur un système
• Confidentialité (ou chiffrement) : la non lisibilité de la donnée par un tiers ne partageant pas un secret

Les stacks de sécurité des web services (WS-Security & co) sont à priori complexes et chers à mettre en œuvre. Toutefois, on peut trouver des exemples concrets où ces solutions ont un réel intérêt (signature des messages par exemple).

Nous allons présenter dans cet article un aperçu de la norme WS-Security pour les services SOAP et les différentes possibilités pour sécuriser des services web.

WS-Security

WS-Security est un standard pour sécuriser des services web SOAP uniquement. Ce dernier aborde les aspects classiques comme l’authentification, l’habilitation mais également des besoins plus rares comme le chiffrement, la signature. Cette norme s’applique uniquement au niveau des messages échangés et n’a aucun impact sur le protocole et le transport choisis. Il repose sur l’ajout d’éléments dans les headers/en-têtes SOAP. Ce standard appelé aussi WSS (Web Services Security) tente de normaliser les échanges sécurisés de messages et de garantir l’interopérabilité entre systèmes.

Des Profiles sont disponibles pour couvrir l’ensemble des problématiques liées à la sécurité (authentification, chiffrement et signature). Le consortium OASIS vise la standardisation des spécifications WS-* pour permettre une meilleure interopérabilité entre les technologies.

Authentification

L’authentification s’appuie sur la notion de token c’est à dire des headers SOAP capables de véhiculer les credentials (typiquement un login et un mot de passe) jusqu’au service cible. Le niveau de confidentialité de ces données échangées peut également être choisi (hash de password, chiffrement des données,.).

Les principaux tokens disponibles sont :

• User Name Token : échange de couples login/mot de passe
• SAML Token : échange de données d’authentification au format XML SAML
• X509 Token : échange de données d’authentification par certificat (authentification forte)

D’autres tokens permettent de l’authentification via des systèmes tiers comme Kerberos.

Voici un exemple de header avec un token user name non chiffré :

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

<s11 :Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "..." >
</s11><s11 :Header >
...
<wsse :Security>
</wsse><wsse :UsernameToken>
</wsse><wsse :Username>NNK</wsse>
<wsse :Password Type="...#PasswordDigest">
weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse>
<wsse :Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse>
< wsu:Created>2003-07-16T01:24:32Z< /wsu:Created>
 
 
...
</s11>
...

Chiffrement

Le chiffrement peut se faire via différents algorithmes, symétriques ou asymétriques. La norme WS-Security permet l’envoi de métadonnées du client de web service au web service cible (end-point) afin de décrire la méthode de chiffrement utilisée et permettre des échanges de clé si besoin.

Les messages sont constitués de plusieurs parties (header, message), chacune pouvant être chiffrée ou non selon la configuration choisie.

Voici un exemple de chiffrement du corps du message avec un certificat X509 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<s11 :Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:xenc="...">
</s11><s11 :Header>
<wsse :Security>
<xenc :ReferenceList>
<xenc :DataReference URI="#bodyID"/>
</xenc>
</wsse>
</s11>
<s11 :Body>
<xenc :EncryptedData Id="bodyID">
<ds :KeyInfo>
</ds><ds :KeyName>CN=Hiroshi Maruyama, C=JP</ds>
 
</xenc><xenc :CipherData>
</xenc><xenc :CipherValue>...//le message chiffré// </xenc>
 
 
</s11>

Ainsi, plutôt que d’utiliser une couche de transport gérant la confidentialité des données, on chiffre tout ou partie du message.

Signature

L’objectif de la signature est de garantir l’origine du message en échangeant un jeton chiffré avec un secret partagé (clé symétrique ou asymétrique). Elle se se fait via des certificats X509 et peut être appliquée sur des messages en clair ou chiffrés selon la configuration choisie.

Comme pour le chiffrement, il est possible de signer à la fois le corps des messages mais également leurs en-têtes.

Voici un exemple de header WS-Security avec une signature du corps du message à base de certificat X509 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<s11 :Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:xenc="...">
</s11><s11 :Header>
<wsse :Security>
<xenc :ReferenceList>
<xenc :DataReference URI="#bodyID"/>
</xenc>
</wsse>
</s11>
<s11 :Body>
<xenc :EncryptedData Id="bodyID">
<ds :KeyInfo>
</ds><ds :KeyName>CN=Hiroshi Maruyama, C=JP</ds>
 
</xenc><xenc :CipherData>
</xenc><xenc :CipherValue>...//le message chiffré// </xenc>
 
 
</s11>

WS-Security : une norme de plus en plus accessible

La norme WS-Security est vaste mais la complexité inhérente à la norme est de plus en plus masquée et devient même dans certains cas complètement externe aux développements applicatifs.

En Java par exemple, l’adoption de nouveaux frameworks et leur intégration avec Spring a favorisé la mise en place de WS-Security par simple déclaration au niveau de la configuration Spring. Un service SOAP peut donc intégrer un chiffrement ou une signature par simple ajout d’un bloc XML.

Des constructeurs d’appliances comme IBM vont également dans ce sens en proposant des boitiers dédiés à la sécurité des web services. Ces derniers sont capables de modifier à la volée des messages SOAP pour leur appliquer des fonctions de sécurité.

Où placer la sécurité ? Jusqu’où aller ?

Les fonctionnalités d’un système n’étant pas exposées aux mêmes risques et cela de façon uniforme, l’approche sécuritaire pilotée par les risques permet d’ajuster le niveau de combinaison et donc d’ajuster les coûts et délais induits lors de la mise en œuvre/exploitation.

Généralement, la plupart des services web implémentés dans les entreprises n’embarquent pas de brique sécurité à proprement parler et les organisations ont plutôt tendance à s’appuyer, dans la plupart des cas, sur les procédures et matériels existants pour la gérer au niveau de l’infrastructure. Cette démarche a l’avantage de ne pas ou peu impacter les développements applicatifs.

La mise en place de tout ou partie des 5 fonctions citées précédemment doit être étudiée selon le besoin de chaque contexte. Il sera ainsi possible de trouver le meilleur compromis pour mitiger les risques en combinant ces fonctions. Voici quelques exemples de combinaisons possibles :

• Contrôle d’accès aux services : utiliser un réseau sécurisé par des firewalls pour limiter la consommation de services à telle ou telle machine.
• Confidentialité des données échangées over HTTP : HTTPS pour le transport des données
• Confidentialité et intégrité pour des messages XML over HTTP: HTTPS pour le transport, signature personnalisée ajoutée dans le message XML
• Confidentialité et intégrité pour des messages SOAP : HTTPS pour le transport, signature du message avec WS-Security
• .

Le déploiement de la sécurité autour des services web va être principalement guidé par les contraintes de mise en œuvre (légale ou réglementaire de non répudiation, de confidentialité des données), le besoin en terme de confidentialité des données et la topologie des équipes infra, sécurité et projet au sein de l’entreprise :

• Le niveau de maitrise par les équipes de développement des frameworks et outils (IDE, stack SOAP ou REST, intégration sur les serveurs de développement),
• Le niveau de maitrise par les équipes de production des briques d’infrastructure et éventuellement des frameworks utilisés sur les projets (firewalls, reverse-proxy, appliance XML, PKI/Certificats.),
• La facilité de communication entre ces équipes est donc nécessaire pour mettre en production des services sécurisés et fluidifier les échanges,
• Les besoins d’interopérabilité entre les systèmes exposant ou consommant des services sécurisés.

Voici quelques exemples de combinaisons que nos architectes retrouvent souvent chez des clients.

Utiliser la sécurité des infrastructures

• Réseaux séparés ou de confiance (firewalls)
• (optionnel) VPN pour la confidentialité sur l’extranet/internet
• (optionnel) Authentification éventuellement déléguée à un VPN

Dans ce cas, la sécurisation repose intégralement sur les briques réseau. Elle n’impacte pas les équipes de développement ce qui rend la sécurité complètement transverse à l’application. Ce cas d’utilisation s’applique dans des échanges B2B avec des partenaires (réseau VPN dédié entre le producteur et le consommateur de services) ou dans les intranets.

S’appuyer sur les protocoles standards

• HTTP pour le protocole
• SSL pour la confidentialité
• Basic Auth pour l’authentification (user, mot de passe) (granularité au niveau de l’application)

Ces briques sont communes et maitrisées par l’ensemble des technologies utilisées dans les entreprises (Java, .Net, C/C++, Progiciels, .). Le pattern repose entièrement sur le protocole (HTTP+SSL) et permet d’assurer à la fois l’authentification et la confidentialité (les messages transite en clair dans un tuyau crypté HTTPS).

Cette typologie est la plus répandue aujourd’hui. On peut l’utiliser à la fois pour des échanges internes à l’entreprise pour des services sensibles que pour relations B2B classiques utilisant l’Internet (ex: banque qui fait de l’assurance vie en marque blanche). Ce mode de sécurisation est flexible puisque l’accueil de nouveaux clients ne nécessite aucune modification de configuration existante (pas de réseau à créer contrairement à la précédente).

S’appuyer sur les couches applicatives et des normes telles que WS-Security

• HTTP (synchrone) ou JMS (asynchrone) pour le protocole
• Authentification par Username Token en WS-Security
• Chiffrement des messages via WS-Security

Cette solution est plus complexe à mettre en œuvre puisqu’elle impacte les couches applicatives et nécessite que les messages soient échangés en SOAP.

En revanche, l’application de la sécurité au niveau du message permet sa circulation sur un transport non sécurisé (http sur Internet par exemple) et une interopérabilité accrue.

Cette solution est intéressante dans le cas de services très ouverts sur Internet qui doivent garantir un fort niveau de confidentialité/intégrité du message.

La suite de cette série d’articles illustrera quelques uns de ces cas d’application.

Références

• Octo Livre Blanc « Services Web : Choix Architecturaux »
• Octo « Gestion des identités »
• OASIS User Name Token Profile
• Spécification WS-Security
• Définition SAML

Suggestion d'articles :

1. Initiation à la sécurité des Web Services
2. Refactoring .NET avec UML, 1ère partie
3. Problèmes courants: Imprécision des calculs mathématiques (1ère partie)

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