Adobe^® Flex^™ Tutorial

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.

Voici une implémentation simple:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
	applicationComplete="configSrv.send()">

	<mx:Script>
	<![CDATA[

	import mx.controls.Alert;
	import mx.messaging.channels.AMFChannel;
	import mx.messaging.ChannelSet;
	import mx.rpc.events.ResultEvent;

	private var channelSet:ChannelSet;

	private function configResultHandler(event:ResultEvent):void
	{
		var xml:XML = event.result as XML;
		var amfEndpoint:String = "" + xml..channel.(@id=="amf").@endpoint;
		if (amfEndpoint == "")
		{
			Alert.show("amf channel not configured", "Error");
		}
		else
		{
			channelSet = new ChannelSet();
			var channel:AMFChannel = new AMFChannel("my-amf", amfEndpoint);
			channelSet.addChannel(channel);
			ro.channelSet = channelSet;
			ro.getProducts();
		}
	}

	]]>
	</mx:Script>

	<mx:HTTPService id="configSrv" url="config.xml" resultFormat="e4x" result="configResultHandler(event)"/>

	<mx:RemoteObject id="ro" destination="product"/>

	<mx:DataGrid dataProvider="{ro.getProducts.lastResult}" width="100%" height="100%"/>

</mx:Application>

Pour laquelle, le fichier de configuration ressemble à:

<?xml version="1.0" encoding="utf-8"?>
<config>
	<channels>
		<channel id="amf" endpoint="http://localhost:8400/lcds-samples/messagebroker/amf"/>
	</channels>
</config>

Avec ce type de configuration, vous pouvez partir d'un projet Flex Builder classique (c'est-à-dire non lié à un Application Server Type).

Cet exemple en particulier n'est pas très flexible. Il assume que vous allez toujours travailler avec un canal AMF et que l'application à seulement besoin de connaître l'URL du endpoint (point d'accès). C'est une option convenable si vous travaillez avec des RemoteObject, mais si vous travaillez avec du messaging, (Producer / Consumer), vous allez aussi devoir externaliser le type de canal à utiliser (AMF Polling, long polling, streaming, RTMP, etc.).

Avant de créer ce type de configuration dynamique, vous pouvez jeter un oeil du côté du Flex ActionScript Framework qui fait cela très bien ou de certains frameworks comme Swiz.

• Flex BlazeDS – Spécifier la configuration BlazeDS à la compilation (services-config.xml et context-root)
• Flex BlazeDS – RPC Fault: faultCode="InvokeFailed" faultDetail="Couldn't establish a connection to 'echoServiceDestination'"
• Flex BlazeDS – Tutorial Application Java Remoting avec BlazeDS Turnkey
• Flex BlazeDS – Introduction à BlazeDS
• Flex BlazeDS – Configurer son environnement BlazeDS avec Turnkey