Publié par

Il y a 11 ans -

Temps de lecture 7 minutes

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

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

Publié par

Publié par Pablo Lopez

Pablo est directeur technique chez Xebia et formateur Hadoop certifié par Cloudera au sein de Xebia Training .

Commentaire

6 réponses pour " BlazeDS "

  1. Publié par , Il y a 11 ans

    Excellent article, clair et précis. C’est très bien résumé.

  2. Publié par , Il y a 11 ans

    Oui je confirme, une synthèse claire, nette et précise. Exactement ce dont nous avons besoin face à cette multitude de solutions…

  3. Publié par , Il y a 11 ans

    Sur la base de billet très clair et précis.

    Afin de comprendre mieux les rouages de BlazeDS, rien de mieux qu’une approche par les mains dans le cambouis :) Je me suis lancé dans le développement d’un petit jeu de plateau multi joueurs (2 par partie pour le monment …) basé sur le protocol Realtime streaming de blazeds.

    Ce qui est intéressant est que je gère les abonnements aux flux real time au runtime vue qu’un seul flux real time est autorisé et que j’ai besoin d’une connexion HTTP supplémentaire pour envoyer des commandes au serveur.

    Seul bémol, si un proxy gère cache le contenu des pages entre le client et le serveur. Le stream est cassé :( , mais la solution de secours est de passer en mode pooling ce que sait faire blazeds également ;)

    http://www.zeugame.com/wob2/wob2.html

    Qu’en pensez vous? merci. vous pouvez me donner vos feedbacks par email à zeugame@gmail.com

    Merci

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.