Un expresso sans sucre

Contract First vs Code First

La méthode la plus répandue pour exposer des WebServices en Java est la méthode dite “Code First” : on développe un composant Java et on s’appuie ensuite sur un outil pour exposer ce composant sous forme de WebService. Cet outil va analyser les signatures des méthodes de votre composant et va générer un descripteur de WebService : le WSDL. Le développeur jette ensuite un oeil (ou pas) à ce descripteur et se félicite de ne pas avoir eu à écrire ce fichier très verbeux.

Un autre développeur récupère le fameux descripteur WSDL et utilise un autre langage ou un autre outil pour générer le code client et c’est la que les choses se compliquent souvent.

Je vais prendre comme exemple un service de recherche dans un annuaire, ce service permet de rechercher des personnes à partir de leur nom, prénom et ville de résidence. Deux critères sont obligatoires : le nom et la ville de résidence.

Voici l’interface Java qui correspond au service :

@WebService
public interface AnnuaireService {
	List<Personne> rechercher(String nom, String prenom, String ville);
}

Une fois ce service déployé à l’aide de la pile de WebService CXF, le WSDL généré déclare le type suivant pour représenter le message de recherche :

<xs:complexType name="rechercher">
	<xs:sequence>
		<xs:element minOccurs="0" name="arg0" type="xs:string" />
		<xs:element minOccurs="0" name="arg1" type="xs:string" />
		<xs:element minOccurs="0" name="arg2" type="xs:string" />
	</xs:sequence>
</xs:complexType>

Cette déclaration n’est pas utilisable dans l’état, les critères de recherche ne sont pas nommés et tous les critères sont marqués comme optionnels (minOccurs=0).
Il est donc necessaire d’annoter l’interface Java pour permettre à CXF de générer un WSDL plus significatif.

@WebService
public interface AnnuaireService {
	List<Personne> rechercher(
		@WebParam(name="nom") String nom,
		@WebParam(name="prenom") String prenom,
		@WebParam(name="ville") String ville);
}

Les critères de recherche sont maintenant nommés dans le WSDL :

<xs:complexType name="rechercher">
	<xs:sequence>
		<xs:element minOccurs="0" name="nom" type="xs:string" />
		<xs:element minOccurs="0" name="prenom" type="xs:string" />
		<xs:element minOccurs="0" name="ville" type="xs:string" />
	</xs:sequence>
</xs:complexType>

La spécification JAX-WS ne permet pas de rendre les paramètres obligatoires.

Il existe bien sur des solutions de contournement pour que le WSDL soit plus conforme au contrat du service, mais cet exemple trivial nous montre que la génération du WSDL à partir du code Java necessite d’enrichir le code avec des méta données et que le résultat ne permet pas d’utiliser le WSDL généré comme contrat solide entre le producteur et les consommateurs.

Pour que le WSDL reprenne son rôle de contrat, il est important qu’il spécifie le plus précisément possible les messages d’entrée et de sortie du WebService. La démarche “Contract First” met justement l’accent sur la contractualisation des messages échangés.

Contract First avec Spring WS

Le descripteur WSDL reste très verbeux et la perspective de gérer ces fichiers à la main est assez effrayante. Rassurez vous, nous allons nous contenter de décrire les messages en entrée et sortie à l’aide de XML Schema (XSD).
Une fois ces messages décrits, nous allons nous appuyer sur JAXB et Spring-WS pour implémenter le contrat.

Voici le schéma décrivant le message de recherche dans l’annuaire :

<element name="rechercherRequest">
	<complexType>
		<annotation>
			<documentation>
				Message d'entrée pour la recherche dans l'annuaire
   		</documentation>
		</annotation>
		<sequence>
			<element name="nom" type="string" />
			<element name="prenom" type="string" minOccurs="0" />
			<element name="ville" type="string" />
		</sequence>
	</complexType>
</element>

Une configuration rapide de la génération des objets Java à partir du XML Schema à l’aide de maven 2 :

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>jaxb2-maven-plugin</artifactId>
	<version>1.3</version>
	<executions>
		<execution>
			<goals>
				<goal>xjc</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Et voici l’objet qui correspond à la requête :

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "nom",
    "prenom",
    "ville"
})
@XmlRootElement(name = "rechercherRequest")
public class RechercherRequest {

    @XmlElement(required = true)
    protected String nom;
    protected String prenom;
    @XmlElement(required = true)
    protected String ville;
 ....
 

Certes c’est verbeux mais c’est du codé généré donc pas de couts d’intégration ou de maintenance.

Voici maintenant la signature du composant Java qui prend en charge la requête :

@Endpoint
public class AnnuaireEndpoint {
	@PayloadRoot(localPart = "rechercherRequest", namespace = "http://yellowpages.tartachuc.org")
	public RechercherResponse rechercher(RechercherRequest request) {

....

Une première annotation @Endpoint marque la classe et la rend detectable par le “component-scan” de spring. La seconde annotation @PayloadRoot indique quel message est traité par la méthode.

Cette mise en oeuvre de Spring-WS permet d’assurer un contrat WSDL soigné tout en ne pénalisant pas la productivité des développements. Dernier avantage, cette démarche impose de concevoir les messages échangés ce qui favorisera des messages plus expressifs et simples  qui facilitent l’utilisation des services tout en évitant d’exposer directement les objets “privés”.

Je me suis rendu compte que j’avais oublié d’indiquer ici que j’utilise Twitter notamment pour partager ma veille techno.
Vous pouvez suivre tout cela sur mon compte twitter. J’ai également ajouté mes derniers Tweet dans le bandeau de droite.

Je fais plein de truc intéressants en ce moment mais je n’ai pas le temps  ne prends pas assez le temps de vous en parler ici.

Bonnes fêtes

Je vous propose de lire cette excellente traduction de l’article de Tobias Mayer “Scrum does anything” . On y trouve beaucoup d’analogies très pertinentes et le rôle de Scrum y est très bien expliqué.
Bonne lecture

Cette année encore, l’Agile Tour passera par Lille: son beffroi, ses moules-frites, ses bières et ses agilistes sympathiques.

L’année précédente, nous avons attiré 80 participants environ, de tous horizons et couvrant une large palette des métiers du logiciel en région. Les commentaires sur la conférence ont été unanimement positifs grâce essentiellement à la qualité du contenu donc des intervenants.

Nous cherchons à transformer l’essai et à installer durablement l’agilisme dans le paysage du développement logiciel lillois.

Agile Tour Lille 2009 se déroulera le 30 octobre, de 13h30 à 18h30 dans l’ancienne friche industrielle Le Blan-Lafont transformée par l’arrivée d’Euratechnologies (http://www.euratechnologies.com/).

A partir de 19h30, un OpenSpace permettra de poursuivre les échanges dans un cadre moins formel et plus interactif.

Nous avons donc besoin de vous ! Ceci est un appel à tous les agilistes du monde: extreme programmeurs, scrumistes ou autres, français ou non, développeurs, coachs, chefs de projets ou autres. Venez partager vos expériences, vos idées, vos outils, vos méthodes de travail, vos désirs et vos déceptions, bref tout ce qui peut avoir trait à l’agilisme, proposez-une présentation, un atelier, un retour d’expérience…

Pour ce faire, deux solutions:
- déposer une session en ligne sur le site Agile Tour 2009
(voir http://www.agiletour.org/fr/node/add/forum pour le formulaire en ligne. Il est nécessaire de disposer d’un compte)
- envoyer un mail contenant votre propostion aux organisateurs d’Agile Tour Lille (agile-tour-lille@googlegroups.com)

Agile Tour Lille 2009 est soutenu localement par :
- ProxiAD (http://www.proxiad.com)
- Norsys (http://www.norsys.fr)

Le 21 Septembre, le ChtiJUG organise une session animée par Emmanuel Bernard qui travaille pour JBoss sur Hibernate et plus particulièrement sur Hibernate Search et Hibernate Validation.

C’est Norsys qui accueille cette session dans nos locaux de Ennevelin.

Dépêchez vous de vous inscrire, les places sont réservées à vitesse grand V.

Sami Jaber a publié une vidéo de démonstration du mode OOPHM de GWT 2.0.

OOPHM est l’acronyme de “Out Of Process Hosted Mode”, ce mode va permettre d’exécuter le mode Hosted dans un navigateur classique simplement équipé d’un plugin pour communiquer avec la JVM.

Thales a publié une vidéo qui décrit la mise en place des pratiques Agile.

Les pratiques sont présentées sous le sigle Lean mais les principes des méthodes agiles et le vocabulaire Scrum sont omniprésents.

Merci à eux !

En ce moment je travaille sur des tests de performance d’une application GWT.

Comme d’habitude au petit déjeuner je consulte mon newsreader et je tombe sur cette annonce de l’équipe Google.

Le Debug Panel permet d’analyser finement les performances d’une application GWT vu du client. A commencer par de lancement de l’application : temps passé à télécharger les scripts, temps passé dans le onModuleLoad.

Cet outil permet également de écomposer les appels de services RPC : temps de sérialisation , temps passé à poster les donnés vers le serveur, temps de receptin des données en retour, temps de désérialisation et durée de mise à jour de l’interface.

Il y a des journées qui commencent moins bien

Mon collègue Sébastien a publié un nouvel article, au programme cette fois : les tests unitaires avec le SDK iPhone.