BlazeDS

Le XKE (Xebia Knowledge Exchange) de Juillet a été l’occasion de présenter BlazeDS. En effet, depuis Décembre 2007, Adobe a décidé de mettre en Open Source (sous licence LGPL v3) une partie de sa solution serveur, et le moins que l’on puisse dire est que Flex et BlazeDS font de plus en plus parler d’eux. Nous avons donc voulu étudier de plus près cet outil.
À travers ce billet, nous verrons ce qu’est exactement BlazeDS, pourquoi en avoir besoin ? Et quels services offre-t-il ?

• Les limites de Flex
• BlazeDS à la rescousse
• Architecture Blaze DS
• BlazeDS et Spring
• BlazeDs dans la pratique
• Une alternative : GraniteDS
• Quelques liens

Les limites de Flex

Afin de faire communiquer une application Flex avec un serveur sans utiliser BlazeDS, deux choix s’offrent aux développeurs :

• HTTPService : un service HTTP retourne des données au format XML (ou autres)
• WebService : appel à des services web au standard SOAP.

Il est possible d’utiliser le premier choix avec Java par le biais de librairies (xstream…). Cette solution peut s’avérer relativement lourde et possède une contrainte majeure.

BlazeDS à la rescousse

Qu’est-ce que BlazeDS ?

BlazeDS est un sous-ensemble du Live Cycle Data Services (LCDS) qui permet entre autres de faire du remoting, du data push…

Le Live Cycle Entreprise Suite est une plateforme qui est déployée sur serveur d’application J2EE. Cette plateforme permet de développer, déployer, configurer et exécuter des services. Voici les services que propose cette offre :

Parmi les offres d’Adobe sur le sujet, il y a aussi :

• Live Cycle Data Services Express : cette offre est similaire au LCDS à la différence près que celle-ci est gratuite, mais ne s’applique qu’à une seule application par CPU.
• Live Cycle Data Service Community Edtion : cette offre permet d’avoir du support et des accès aux builds concernant BlazeDS.

Architecture Blaze DS

BlazeDS est disponible sous plusieurs formes :

• Un ensemble de jars indépendants, pouvant être embarqués dans votre application.
• Une webapp complète (ear), pouvant être déployée sous Tomcat (par exemple).

L’architecture de BlazeDS repose sur une servlet et un ensemble de fichiers XML à configurer. La servlet permet entre autres

• de localiser et invoquer des services Java
• de sérialiser/désérialiser des objets entre les données Flex et Java.

BlazeDS s’intègre à votre application web via le fichier web.xml. On y déclare la servlet, les fichiers de configuration à charger au startup, ainsi qu’un Listener permettant de gérer la session Flex.

...

flex.messaging.HttpFlexSession
MessageBrokerServlet
flex.messaging.MessageBrokerServlet
services.configuration.file /WEB-INF/flex/services-config.xml
1

MessageBrokerServlet
/messagebroker/*

...

La MessageBrokerServlet est le point d’entrée unique du framework. Elle est paramétrée par la lecture du fichier services-config.xml. Celui-ci pilote :

• La définition des services : remoting, messaging, proxy.
• La définition de channels : ce sont les canaux de communication utilisés pour envoyer et recevoir des données entre le client et le serveur.
• Chaque channel possède un unique endpoint, qui correspond à la classe BlazeDS qui devra traiter les messages issus de ce channel.
• La définition des paramètres de logs.
• La définition de la sécurité.
• La définition de paramètres de redéploiement.

Nous détaillerons le contenu de ce fichier, ainsi que de tous les autres cités dans cet article, dans une prochaine série de billets qui traiteront de la prise en main de BlazeDS.

BlazeDS offre 3 types de communication (proxy, messaging, remoting, détaillés ci dessous) , qui sont communément paramétrés dans trois fichiers xml distincts.

Ces fichiers de configuration possèdent tous les mêmes structures et définissent :

• les propriétés du service : nombre maximal de connexions, utilisation du ssl…
• les adaptateurs : BlazeDS offre nativement un certain nombre d’adaptateurs, qui permettent d’encapsuler le message émis par Flex (voir exemples ci-après).
• les destinations disponibles : chaque destination possède un ensemble de propriétés qui la caractérisent (url, wdsl, file JMS…) ainsi qu’un ou plusieurs canaux de communication. Ces canaux doivent bien sûr être préalablement déclarés dans le fichier services-config.xml.

Les services de type Proxy

Ces services sont une extension de ce qui existe nativement dans Flex.
En effet, Flex permet déjà d’invoquer des destinations HTTP que ce soit en REST ou en SOAP. Cependant, ces invocations sont parfois complexes, Flex ne pouvant invoquer que des destinations que si elles se trouvent dans le même domaine que l’hôte de l’application Flex (à moins de passer par un fichier xml de cross domain).
BlazeDS joue alors le rôle de proxy, et permet de contacter n’importe quelle destination HTTP, sans se soucier de la problématique de domaine.
De même, pour les destinations SOAP, un ensemble d’adaptateurs permettent d’ignorer la rédaction de l’enveloppe SOAP, prise en charge par le framework.

Les services de type Messaging

Ces services traitent les problématiques de type publish / suscribe et data push.
Ils fonctionnent également grâce à un système d’adaptateurs, qui permettent de s’affranchir de la rédaction des enveloppes techniques (BlazeDS propose nativement un adaptateur JMS par exemple).

Pour le messaging, deux types de channels peuvent, en théorie, être utilisés :

• le Real-Time Messaging Protocol (RTMP): permet de maintenir une connexion entre le client et le serveur, ainsi le client n’a pas besoin d’interroger le serveur à intervalle régulier.
• l’Action Message Format (AMF) : interroge le serveur pour de nouveaux messages.

Mais en réalité, BlazeDS supporte assez mal le channel RTMP (à l’instar de LCDS).

Il reste donc l’AMF qui peut être de 3 types :

• Simple polling : protocole de message par défaut. Le client sonde le serveur régulièrement pour obtenir de nouveaux messages.

• Real time polling (long polling) : le serveur maintient la requête d’interrogation du client jusqu’à ce qu’il y ait un message pour le client. Dès que le message est disponible, celui-ci est envoyé au client.

• Real time streaming : garde la connexion ouverte le temps d’une « conversation ».

Les services de type Remoting

Ces services permettent l’invocation distante d’objets (Java dans le cas qui nous occupe, mais aussi PHP.)
Ils supportent les appels RPC via RemoteObject. Ces appels sont effectués grâce au protocole AMF3. L’architecture d’AMF3 est similaire à SOAP mais est plus rapide, car elle ne manipule que du code binaire.

BlazeDS et Spring

BlazeDS propose la possibilité de s’intégrer à certains frameworks dans le monde Java, en particulier Spring. Spring permet, entre autres, de gérer le cycle de vie des services (IoC), et BlazeDS doit être configuré de manière à dialoguer avec Spring qui se chargera de localiser les services à invoquer.
En effet, le contexte Spring n’est pas le même que celui de BlazeDS. Il faut donc implémenter une factory (FlexFactory) qui se chargera de faire le lien entre Spring et BlazeDS.

La configuration, relativement simple, sera détaillée dans le Hands On.

BlazeDs dans la pratique

BlazeDS apparaît comme le compagnon naturel de Flex pour se plugger sur des back ends Java. Voilà pour la théorie, mais qu’en est-il du point de vue de la pratique ? C’est que nous verrons prochainement dans une série d’articles qui nous verra explorer une large palette de fonctionnalités de BlazeDS.

Une alternative : GraniteDS

GraniteDS est un projet open source (LGPL). Il fournit des services que BlazeDS ne supporte pas (mais présents dans LCDS) comme la gestion des données, l’intégration avec des EJB, le support de la sécurité avec Acegi, et également la possibilité d’utiliser Hibernate directement au sein de l’ActionScript.
Historiquement, GraniteDs était le premier outils d’intégration OpenSource pour Flex.
Selon vos besoins, GraniteDS peut être une bonne solution pour communiquer avec une application Flex, en particulier si vous voulez profiter des fonctions d’intégration du framework (gestion des sessions Hibernate et donc du lazy loading entre autres).
Le fondateur du projet,Franck Wolff, revenait pour InfoQ, en février dernier, sur les principales fonctionnalités de GraniteDs, sur son avenir et sur le face à face avec BlazeDs.

Quelques liens

• Le guide officiel du développeur BlazeDS
• Le Flex developper center d’Adobe
• Un agrégateur de ressources Flex
• La présentation de James Ward, évangéliste Flex, donnée au Paris JUG.
• Le blog du même James Ward, contenant notamment une étude de performance.
• Le blog de Zee Yang contenant de nombreux tutoriaux et exemples.
• Le blog de Julien Lestel, en français dans le texte