Archive

Posts Tagged ‘spring’

Stateless is priceless : la vidéo

Les vidéos de la session que j’ai eu l’honneur de présenter au Ch’ti JUG sur le thême des applications Web sans session sont maintenant disponibles sur Parleys: partie 1 et partie 2.

Grand merci à Loïc pour le montage.

Publicités
Étiquettes : , ,

WebService "Contract First" avec Spring-WS

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

Étiquettes : ,

Lecture de la semaine

C’est reparti avec les articles qui ont retenu mon attention cette semaine.

  • Versioning des Services REST.
    Sur le Blog Octo, Benjamin Magan nous propose une stratégie pour le versioning des Services REST.
    La technique proposée est élégante et repose sur la négociation du contenu et l’entête « Content-Type ». Le client indique à l’aide cet entête, non seulement le format de représentation des données (XML, JSON, …) mais aussi la version du service qu’il utilise.
    De cette manière, l’URL reste inchangée ce qui est important avec des services REST.
  • La vélocité des Bugs
    Alexandre Boutin nous explique sa vision au sujet de la comptabilisation des bugs et des story non fonctionnelles dans la vélocité de l’équipe.
    Pour Alexandre, il faut compter les story non fonctionnelles car elles apportent de la valeur en terme de productivité, performance ou encore qualité. Par contre il considère que les corrections de bugs n’apportent pas de valeur et le les comptabilise donc pas. Dans les commentaires de l’article, Claude Aubry nuance cet avis dans les commentaires en proposant de comptabiliser les corrections de manière séparée.
  • Intégration GWT/Spring Simple
    J’en ai rêvé, je m’étais promis de m’y intéresser, il l’a fait 🙂
    Enfin une solution simpliste pour que Spring instancie les services RPC de GWT et puisse donc y injecter proprement les dépendances et y appliquer les aspects qui vont bient (gestion de transaction, sécurité,  …). Merci ! (via onGwt)


  • Plus de projets en échec en 2008
    Sur le blog de Pyxis, Martin Proulx nous présente les statistiques du Standish Group à propos des succès des projets logiciels. En résumé, les chiffres se dégradent avec seulement 32% de projets en succès (délai, couts, périmètre). Il est certain que les méthodes agiles à elles seules ne vont pas permettre de passer à 100% de succès, mais j’en suis convaincu, beaucoup d’entreprises gagneraient à changer une méthode qui perd, à remettre en cause leur organisation et à essayer les méthodes agiles.
Étiquettes : , , ,

Support de GWT dans Spring

Didier Girard a créé une demande dans le JIRA du projet Spring en vue d’ajouter le support de GWT.

Si comme moi vous pensez que cette cohabitation peut s’améliorer si les gurus de chez Spring se penchent dessus, votez pour cette demande.

Étiquettes : ,

Spring JMS : Augmenter les performances

A plusieurs occasions, j’ai eu l’occasion de conseiller l’utilisation de Spring JMS car cette API simplifie énormément la manipulation de l’API JMS qui il faut l’avouer n’est vraiment intuitive.

En effet l’API JMS nécessite de manipuler 6 objets (QueueConnectionFactory, QueueConnection, QueueSession, Queue, MessageProducer, TextMessage) pour simplement envoyer un message texte !

Avant de pouvoir utiliser l’api Spring JMS, il faut configurer une ConnectionFactory  (Exemple avec Active MQ) :

<bean name="activeMqConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://theactivemqserver:61616" />
</bean>

Ensuite, il faut récupérer un objet JmsTemplate dans lequel la ConnectionFactory aura été injectée.

Enfin, l’envoi d’un message peut se faire de différentes manières mais un simple appel de la méthode convertAndSend pourra suffir.

Il se trouve que par défaut le JmsTemplate peut limiter les performances des applications car il entraine la création des objets Connection, Session et MessageProducer pour chaque envoi.

La solution peut se trouver du coté du provider JMS qui comme ActiveMQ peut proposer une ConnectionFactory adaptée en gérant un pool d’objets Connection, Session  et MessageProducer.

La solution peut aussi venir d’un objet fourni par Spring depuis la V2.5.3 : CachingConnectionFactory cette ConnectionFactory peut encapsuler n’importe quelle autre ConnectionFactory et mettre en place le cache de Connection, Session et MessageProducer.

Dans mon cas, l’utilisation de la CachingConnectionFactory a résolu nos problèmes. Un profiling de l’application avait montré que nos Threads passait leur temps à ouvrir des Session JMS.

Étiquettes : ,