Accueil > Non classé > Blazé du remoting ? Utilisez Spring-flex !

Blazé du remoting ? Utilisez Spring-flex !

Introduction

Logo Spring

Suite à la mise en place d’un environnement de développement Flex en Open Source, je vous propose aujourd’hui de simplifier l’utilisation de BlazeDS grâce à Spring BlazeDS Integration (Spring-flex).

La description suivante, traduite de l’introduction faite sur le site officiel, résume bien les buts recherchés :

Spring BlazeDS Integration est une réponse à une demande de la communauté qui souhaitait avoir une solution pour construire des RIA propulsées par Spring, utilisant Adobe Flex pour la technologie client. […] Bien qu’il était possible d’utiliser BlazeDS pour se connecter à des services gérés par Spring, ce n’était pas réalisable de manière “naturelle” pour un développeur Spring, nécessitant d’avoir à maintenir une configuration XML BlazeDS séparée. Spring BlazeDS Integration change tout cela en transformant le MessageBroker de BlazeDS en un objet géré par Spring, ouvrant des perspectives vers une intégration plus complète qui suit le “Spring way”.

Dans cet article, nous allons voir les principes de base de Spring BlazeDS Integration : configuration, exposition des services et consommation par un client Flex. Un projet est réalisé en parallèle pour illustrer la théorie ; les exemples de code suivant en sont tirés. Le code source final est disponible à la fin de cet article. Si vous n’avez pas encore lu le précédent article, je vous invite à le faire car il explique de nombreuses notions qui seront réutilisées ici.

Mise en place de la webapp

C’est bien Mave(i)n(e)…

Une fois n’est pas coutume, nous allons utiliser Maven 2 pour créer le squelette d’application web qui sera utilisée par le client Flex :


1
mvn archetype:create -DgroupId=com.excilys.java -DartifactId=SimpleSpringFlex -DarchetypeArtifactId=maven-archetype-webapp

Retour aux sources

Ajoutons tout de suite les bonnes dépendances vers Spring-Flex :


1
2
3
4
5
<dependency>
  <groupId>org.springframework.flex</groupId>
  <artifactId>spring-flex</artifactId>
  <version>1.0.1.RELEASE</version>
</dependency>

Commençons par adapter le descripteur de déploiement web.xml :


1
2
3
4
5
6
7
8
9
10
11
12
13
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
  <display-name>Simple Flex Remoting with Spring-Flex</display-name>
  <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <url-pattern>/messagebroker/*</url-pattern>
    <servlet-name>dispatcher</servlet-name>
  </servlet-mapping>
</web-app>

Comme dans l’article précédent, nous mappons le pattern /messagebroker/* sur une servlet, sauf que maintenant ce n’est plus une MessageBrokerServlet, mais une DispatcherServlet Spring. Le travail de Spring va donc commencer ici. Profitons de la convention du framework qui ira chercher par défaut la configuration du conteneur Spring associée à cette servlet dans le fichier WEB-INF/dispatcher-servlet.xml :


1
2
3
4
5
6
7
8
9
10
11
12
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:flex="http://www.springframework.org/schema/flex"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
       http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
       http://www.springframework.org/schema/flex
       http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">


  <flex:messagebroker />
</beans>

Par rapport à une configuration classique, notez l’inclusion de l’espace de nommage “flex”, qui va rendre disponible la balise messagebroker. Celle-ci va nous permettre de créer un managed bean de type MessageBroker, qui va gérer les flux AMF (là aussi on profite de la configuration par défaut du bean, notamment pour le nom du fichier de configuration services-config.xml).

Exemple de Bean non managé par Spring

Création des services

Dans cette partie, nous allons faire du Java “classique”. Le but de la webapp créée au tout début de l’article est d’exposer des services à notre client Flex. Créons donc notre service, qui va permettre d’additioner deux nombres (calcul nécessitant de grosses ressources type cluster :P) :


1
2
3
4
5
6
7
package com.excilys.java.springflex.service;

public class MathService {
    public int add(int a, int b) {
        return (int)((2*(double)a/b) * ((double)b/(int)Math.sqrt(4)) + (b << 2) / 4); // Addition standard.
    }
}

Exposition (gratuite) de services

Il nous reste maintenant à rendre ce service accessible à notre application Flex. En utilisant BlazeDS directement, il faudrait ajouter chaque service dans le fichier WEB-INF/flex/services-config.xml. Avec Spring-flex, nous allons pouvoir minimiser cette configuration :


1
2
3
4
5
6
7
8
9
10
11
12
<services-config>
  <services>
    <default-channels>
      <channel ref="my-amf"/>
    </default-channels>
  </services>
  <channels>
    <channel-definition id="my-amf">
      <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"/>
    </channel-definition>
  </channels>
</services-config>

On se contente de dire que les services utiliseront par défaut le channel “my-amf”, avec l’endpoint /mesagebroker/amf. Pour exposer notre service, nous pouvons utiliser l’annotation @RemotingDestination :


1
2
3
4
5
6
7
//...
import org.springframework.flex.remoting.RemotingDestination;

@RemotingDestination
public class MathService {
  //...
}

Pour que ces annotations soient prises en compte, il faut bien évidemment utiliser la balise component-scan dans dispatcher-servlet.xml :


1
2
3
<bean xmlns:context="http://www.springframework.org/schema/context" ...>
  <context:component-scan base-package="com.excilys.java.springflex" />
</bean>

Appels depuis le frontend Flex

Nos services sont exposés, nous pouvons maintenant les consommer depuis du code Flex. Pour cela, nous utiliserons un RemoteObject de la même manière que dans l’article précédent. Le channel “my-blazeds” utilisera l’URL du DispatcherServlet :


1
2
3
4
<channel-definition id="my-blazeds" >
  <endpoint uri="http://localhost:8080/SimpleSpringFlex/messagebroker/amf"
     class="flex.messaging.endpoints.AMFEndpoint" />
</channel-definition>

Spring-Flex en action

Et après ?

Ajouter d’autres services (soustraction, multiplication, …) consiste à ajouter des méthodes dans MathService. Pour exposer d’autres classes de services, il suffit de les annoter avec un @RemotingDestination.

Si vos services  nécessitent une authentification préalable, il est possible de sécuriser les destinations avec Spring Security.

Enfin, pour la partie messaging, Spring BlazeDS Integration facilite l’envoi de messages entre clients Flex et/ou POJOs. Il est ainsi possible d’utiliser AMF ou JMS de manière similaire, grâce à une couche d’abstraction.

Nous venons de voir qu’une fois de plus, Spring nous propose un module assez simple d’utilisation qui permet de gagner en clarté de configuration et en rapidité d’exposition de services. La configuration XML est minimisée, les annotations font le reste. Et comme c’est bien pensé, ça s’intègre sans problème avec d’autres briques Spring liées par exemple à la sécurité. C’est-y pas beau çà ?

Code source

Pour bidouiller vous-même Spring-Flex, vous pouvez télécharger le code source du projet réalisé dans cet article.

Share