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

19jan/110

TTFX Bordeaux #3 : Messaging et Remoting le Jeudi 03 février à 18h30 à l’ENSEIRB

Petit relai d'informations sur cette rencontre des TTFX bordelais.

banniere

Le programme a l'air sympathique:

  • Le FUG, et news du monde Flash
  • Flex, BlazeDS, LCDS et LCCS
  • Flex et le Remoting AMF
  • Flex et le messaging (chat, data push)
  • Flex et le Data Management
  • Flex et LiveCycle Collaboration Service

Cette fois ci Michaël CHAIZE, Platform Evangelist pour Adobe et auteur du blog RIAGORA, vient nous parler échange client-serveur.

Pensez donc à cliquez sur le lien ci dessous pour vous inscrire et réserver vos places :

http://ttfx201102.eventbrite.com/

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.

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".