Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

22nov/094

Flex BlazeDS – Spécifier la configuration BlazeDS à l'exécution (services-config.xml et context-root)

Dans le tutorial précédent, on a vu comment spécifier la configuration de BlazeDS à l'application Adobe Flex au moment de la compilation. On va voir dans cet article, comment la spécifier à l'exécution, et les avantages que cela apporte. Cette démarche est aussi valable pour la définition de la configuration LiveCycle pour vos applications Flex / Air.

Cet article est une traduction de l'article de Christophe Coenraets: Externalizing Service Configuration using BlazeDS and LCDS

Vue d'ensemble de la configuration de BlazeDS / LCDS

Lorsque les développeurs commencent à utiliser les RemoteObject, ils vont se demander quand et à partir de quel emplacement est lue la configuration serveur.

Cette question remonte assez vite quand une application cesse de fonctionner et que vous venez de la déplacer de serveur ou tout simplement de la mettre en ligne.

Quand vous créez un nouveau projet BlazeDS ou LCDS dans Flex Builder, vous sélectionnez J2EE comme "Application Server Type". Cela ajoute un argument de compilation pointant vers votre fichier services-config.xml. Si vous jetez un oeil du côté des propriétés de votre projet Flex Builder, vous verrez quelque chose comme:

-services "c:\blazeds\tomcat\webapps\samples\WEB-INF\flex\services-config.xml"

Quand vous compilez votre application, les valeurs requises du services-config.xml sont intégrées au SWF. Pour faire simple, le fichier services-config.xml est lui à la compilation et pas à l'exécution comme on pourrait le penser. Pour rendre les choses plus abstraites, vous pouvez utiliser des tokens comme {server.name}, {server.port} et {context.root} dans le fichier services-config.xml. Cependant, {content.root} sera substitué à la compilation alors que {server.name} et {server.port} sont remplacés à l'exécution en utilisant le nom du serveur et le numéro de port du serveur par lequel le SWF a été chargé (c'est la raison pour laquelle vous ne pouvez pas utiliser ces tokens pour des applications Air).

Heureusement, le framework Flex propose une API ActionScript permettant de configurer vos canaux à l'exécution et d'externaliser complètement votre configuration de service de votre code. En effet, vous ne voulez pas recompilez votre application quand vous la déplacez de serveur. Cela marche de cette manière:

var channelSet:ChannelSet = new ChannelSet();
var channel:AMFChannel = new AMFChannel("my-amf", "http://localhost:8400/lcds-samples/messagebroker/amf");
channelSet.addChannel(channel);
remoteObject.channelSet = channelSet;

Ce n'est cependant toujours pas ce que l'on souhaite car l'URL du endpoint est toujours en dur dans le code de l'application Flex. L'étape suivante est donc de passer cette valeur d'URL à l'exécution. Il y a de très nombreuses manières de passer ces valeurs au SWF à l'exécution comme les flashvars par exemple. Ici, on va lire un fichier de configuration en utilisant un HTTPService au démarrage de l'application. Ce fichier de configuration inclus (entre autres) les informations nécessaires à la création du ChannelSet en ActionScript.

22nov/090

Flex BlazeDS – Spécifier la configuration BlazeDS à la compilation (services-config.xml et context-root)

Dans les tutoriaux d'initiation à BlazeDS Turnkey, on a spécifié la configuration de votre serveur applicatif Tomcat (intégré à BlazeDS Turnkey) au moment de la création du projet. On a ainsi spécifie l'emplacement du fichier services-config.xml de BlazeDS qui contient la définition des canaux de communication entre l'application client et le serveur applicatif. On a aussi précisé le "context-root" qui représente le dossier de votre serveur applicatif contenant votre Web Application. Pour spécifier toute cette partie configuration, il est très simple de le faire au moment de la compilation mais vous pouvez aussi le faire au moment de l'exécution pour pouvoir changer votre configuration à partir d'un fichier XML par exemple.

On va voir ici comment préciser la configuration à la compilation.

Utilisation des tokens dans le fichier services-config.xml

Avant de poursuivre, il faut bien comprendre comment fonctionne le fichier services-config.xml. Ce fichier contient ce que l'on appelle des "tokens". Ces tokens sont des identifiants qui vont être remplacés à l'exécution de l'application par des valeurs correspondant au contexte d'exécution de l'application.
Par exemple, vous pouvez voir des lignes comme:

<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf"
     />

Dans l'URL, on voit bien le token {server.name}, entouré par des crochets. Ce token va être remplacé au moment de l'exécution par le nom du serveur. Par exemple, si votre application s'exécute à l'adresse http://www.mondomaine.com/monAppli/monSwf.swf, Flex va automatiquement remplacer {server.name} par www.mondomaine.com. Et de même pour {server.port}.

Le token {context.root} est, lui, remplacé au moment de la compilation.

Note aux utilisateurs d'applications Adobe Air connectés à BlazeDS

Si vous comptez utiliser votre application web BlazeDS depuis une application Adobe Air, vous ne pourrez pas utiliser ces token. En effet, Adobe Air ne pourra pas deviner la valeur de {server.name} car votre application est une application bureautique, qui n'est pas hébergée sur un serveur. Vous devrez donc spécifier l'URL complète de votre service comme par exemple:

<endpoint url="http://your_server_name:8400/samples/messagebroker/streamingamf"
     />

Spécifier le fichier services-config.xml à la compilation

Quand vous compilez votre application Adobe Flex, vous pouvez spécifier l'emplacement du fichier de configuration au compilateur. Le fichier services-config.xml définit les URL des canaux que l'application Adobe Flex utilise pour communiquer avec le serveur BlazeDS. Les URLs des canaux sont compilées dans le SWF final.

15nov/093

Flex BlazeDS – RPC Fault: faultCode="InvokeFailed" faultDetail="Couldn't establish a connection to 'echoServiceDestination'"

Ce article explique comment résoudre un problème que vous pouvez avoir avec BlazeDS. Voici l'erreur exacte qui correspond à la propriété "fault" du FaultEvent:

Received fault: [RPC Fault faultString="[MessagingError message='Destination 'echoServiceDestination' either does not exist or the destination has no channels defined (and the application does not define any default channels.)']" faultCode="InvokeFailed" faultDetail="Couldn't establish a connection to 'echoServiceDestination'"]

Bien sûr, dans votre cas, le nom du service ne sera pas "echoServiceDestination". Cette erreur se produit quand vous essayer d'appeler une méthode d'un RemoteObject et vient en fait d'un problème de configuration. Voici un bout de code contenant le RemoteObject qui pose problème:

<mx:RemoteObject id="remoteObject"
 destination="echoServiceDestination"
 result="resultHandler(event);"
 fault="faultHandler(event);"/>

Comme le dit le détail de l'erreur, la destination voulue ne peut pas être accédée. Comme votre serveur applicatif ne la trouve pas, il va chercher un "fallback", c'est-à-dire une destination par défaut sur votre serveur.

Dans la plupart des cas, cela signifie que votre application n'as pas réussi à lire le fichier de configuration de services services-config.xml. Il n'arrive donc pas à trouver la route vers la destination que vous lui donnez.

Vérifiez vos paramètres de compilation

Même s'il y a d'autres manières de le faire, vous pouvez renseigner le chemin vers le fichier de configuration services-config.xml comme paramètre de compilation par l'option -services comme ceci:

-services "C:\blazeds\tomcat\webapps\samples\WEB-INF\flex\services-config.xml" -locale en_US

Définir le fichier de configuration des services dans l'application cliente

Au moment de la création du projet…

Si vous avez crée votre projet de 0, vous avez sûrement définit au moment de la création, le type de serveur applicatif (J2EE, Colfusion, PHP, …) ainsi que les différentes informations associées (Root Folder, Root Url et Context Root). Vérifiez que vous avez bien configuré ces options pour qu'elle pointe vers la bonne application BlazeDS. Pour voir un exemple de création de projet BlazeDS de 0, consultez ce tutorial:

Flex BlazeDS – Tutorial Application Java Remoting avec BlazeDS Turnkey

15nov/093

Flex BlazeDS – Tutorial Application Java Remoting avec BlazeDS Turnkey

Ce tutorial Adobe Flex avec BlazeDS va vous expliquer comment monter votre première application Java en liaison avec une application Flex. On va ici utiliser le service RPC (Remote Procedure Call) de BlazeDS pour la communication. Afin de faciliter l'explication, on va utiliser la version "Turnkey" de BlazeDS qui est directement livrée avec un serveur d'application Tomcat. Si vous n'avez pas encore installé BlazeDS Turnkey, suivez ces instructions:

Flex BlazeDS – Configurer son environnement BlazeDS avec Turnkey

Création du projet Java

Vous allez avoir besoin d'un projet Java pour la partie serveur de l'application. Tout d'abord, ouvrez Eclipse et créez un nouveau projet Java:

  • Dans le menu d'Eclipse, choisissez File > New > Project
  • Dans l'arbre, choisissez Java Project comme type de projet puis Next
  • Sur la page "Create a Java Project":
    • Entrez "blazeds-server" comme nom de projet
    • Sélectionnez "Create project from existing source", et entrez le chemin vers la webapp "sample" comme par exemple "C:\blazeds\tomcat\webapps\samples\WEB-INF"
    • Next
  • Sur la  page "Java Settings", assurez-vous que le Default output folder soit à "blazeds-server/WEB-INF/classes" puis Finish

Cette configuration de projet vous permet de conserver le code source de vos classes Java dans le dossier WEB-INF/src. Ces classes seront automatiquement compilées dans le dossier WEB-INF/classes.

Création des classes Java

Le service de Remoting (RPC) est un des services inclus dans BlazeDS. Ce service permet au client d'accéder aux méthodes des Plain Old Java Object (POJO = "bon vieux objets Java") sur le serveur.

Dans cet exemple, on va déployer une classe, EchoService.java, sur le serveur qui va renvoyer la String passée par le client. Le code suivant montre la définition de EchoService.java:

package remoting;
public class EchoService
{
    public String echo(String text) {
        return "Server says: I received '" + text + "' from you";
    }
}

Pour créer cette classe, faîtes clic droit sur le projet Java que vous venez de créer puis New > Class. Comme nom de package, entrez "remoting" et comme nom de classe, EchoService:

remoting-1

Vous le voyez, cette classe est très simple. La méthode echo() prend un argument de type String et le retourne avec un texte supplémentaire. Une fois que la classe EchoService.java est compilée, elle sera placée dans WEB-INF/classes/remoting. Notez que les classes Java n'ont pas à importer ou à référencer des ressources BlazeDS.

Création de la destination de remoting (remoting-config.xml)

Une "Remoting Destination" expose une classe Java pour que votre application Adobe Flex puisse l'invoquer de manière distante. La propriété "id" de la destination est le nom logique que votre application Flex utilise pour faire référence à la classe distante, ce qui élimine le besoin d'avoir une référence vers un nom complet de classe Java (fully qualified) codé en dur. Ce nom logique est lié au nom de la classe Java dans le configuration de la destination qui se trouve dans remoting-config.xml.

Pour créer cette Remoting Destination:

  • Dans le projet blazeds-server, ouvrez le fichier remoting-config.xml situé dans le dossier "WEB-INF/flex". Si vous l'ouvrez dans Eclipse, passez en vue "Source" pour avoir le code directement.
  • Plusieurs destinations, fournies avec Turnkey sont déjà présentes. Rajoutez la votre:
<destination id="echoServiceDestination" channels="my-amf">
    <properties>
        <source>remoting.EchoService</source>
    </properties>
</destination>
  • Enregistrez le fichier

L'élément XML "source" référence la classe Java et l'attribut "channels" fait référence au canal qui va être utilisé, ici appelé "my-amf".