Adobe Flex Tutorial - Adobe Flex Tutorial

Flex Client / Serveur

Communication avec le Client

Les applications Flex sont capables d'échanger de la donnée de plusieurs manières, plus ou moins complexes. Souvent lorsque l'on parle de "data communication" dans les applications Flex, on pense à la communication client-serveur, du type RPC (Remote Procedure Call / Appels de procédures distantes). Cependant, cette communication peut aussi s'effectuer uniquement du côté client.

Au minimum, toutes les applications Flex requièrent un élément du côté client qui est le fichier SWF exécuté par Flash Player. Certaines applications Flex utilisent même plusieurs fichiers SWF joués dans une ou plusieurs instances du Flash Player sur la machine cliente. La partie client d'une application Flex est capable de plusieurs types de communication, suivant l'usage que vous en aurez.

Il y a trois manières pour faire communiquer une application Flex et le client:

Local Connections

Une Local Connection permet à 2 fichiers SWF de communiquer, tant qu'ils sont exécutés sur la même machine client au même moment. Ces fichiers SWF peuvent être joués dans deux instances différentes de Flash Player. Ils peuvent même être joués sur plusieurs types d'environnements. Par exemple, un SWF peut être joué dans le navigateur web pendant qu'un autre est embarqué dans un exécutable.

Shared Objects

Les Shared Objects locaux permettent à l'application de stocker et de récupérer de la data persistante sur la machine cliente. Par exemple, un utilisateur peut sauvegarder ses préférences que l'application pourra récupérer automatiquement la prochaine fois que l'application est jouée.

External Interface

External Interface est un mécanisme par lequel une application Flex peut communiquer avec l'environnement sur lequel elle est hébergée. Cela permet de lancer une application Flex comme partie intégrante d'une autre application.

Local Connections

Vous pouvez utiliser les Local Connections pour faire communiquer 2 fichiers SWF, même s'ils sont lancés sur deux instances différentes du Flash Player. De plus, les LocalConnection vous permettent de communiquer entre du contenu Flash 9 (applications Flex par exemple) et du contenu plus ancien (Flash 8 et inférieur). Les applications Flex peuvent charger toutes sorte de fichier SWF, qu'il soit publié par Flex ou par l'IDE Flash. Cependant, puisque les applications Flash 9 utilisent une machine virtuelle différente par rapport à du contenu Flash plus ancien, il n'est pas possible pour une application de communiquer directement avec un SWF publié depuis Flash 8 ou inférieur. Si une application Flash 9 charge un SWF Flash 9, elles peuvent communiquer directement.

La communication par les LocalConnection est une solution à ces problèmes d'interopérabilité, car elle est supportée par toutes les versions de Flash Player

Flex LocalConnection – Exemple de LocalConnection simple

Flex LocalConnection – Communication en Cross-Domain

Shared Objects

De nombreuses applications ont besoin de stocker de la données persistante sur la machine du client, et les applications Flex n'y font pas exception. Par exemple, une application Flex peut afficher une page démarrage pour les nouveaux utilisateurs, et que l'on donne à l'utilisateur la possibilité de cacher cette page de démarrage s'il revient souvent. Bien que l'on puisse stocker ces préférences de manière distante, la méthode la plus commune est de stocker les préférences du côté client.

La sécurité de Flash Player à une haute priorité chez Adobe, c'est pourquoi Flash Player ne peut pas écrire de fichiers arbitrairement sur l'ordinateur du client. Cependant, Flash Player a une zone spéciale sur la machine du client ou il peut écrire des fichiers spécifiques qui sont contrôlés et gérés entièrement par Flash Player. Ces fichiers sont appelés "local shared objects" (objets partagés en local), et vous pouvez utilisr de l'ActionScript pour écrire et lire ces fichiers.

Flash Player utilise la classe flash.net.SharedObject pour gérer l'accès à la données stockée dans ces Shared Objects. Bien que la donnée soit stockée dans des fichiers côté client, l'accès à ces fichiers est contrôlé exclusivement par l'interface SharedObject. Cela simplifie le travail avec les shared objects et cela améliore la protection des application Flex contre les programmeurs mal intentionnés.

Il faut savoir que la class SharedObject vous autorise aussi à travailler avec des shared objects distants. C'est pourquoi vous allez peut-être remarquer que l'API de la classe SharedObject inclut de nombreuses propriétés et méthode qui ne sont pas présentées ici. Les shared object distant permettent la synchronisation de données en temps réel sur plusieurs clients, mais ils nécessitent aussi un logiciel côté serveur tel que Flash Media Server.

External Interface

Les applications Flex ont besoin de l'environnement Flash Player pour fonctionner. C'est pourquoi il est assez commun de penser qu'un application Flex est confinée à Flash Player. Cependant, il est entièrement possible pour une application Flex de communiquer avec l'application qui l'héberge (host application). Par exemple, si une application RIA Flex est lancée à l'intérieur d'un navigateur web, l'application peut interagir avec le navigateur. Si l'application Flex est lancée à l'intérieur d'un exécutable, elle peut interagir avec l'exécutable. Cela permet de créer des applications intégrées qui vont bien au delà de Flash Player.

La communication entre l'application Flex et celle qui l'héberge se fait via une classe de Flash Player appelée flash.external.ExternalInterface. ExternalInterface vous permet de faire des appels synchrones aux méthodes de l'application host depuis l'application Flex, et vice-versa.

Communication avec un Serveur

La communication avec des données distantes se fait à l'exécution. Elle ne réside pas strictement sur le client, mais requiert une communication au réseau pour envoyer et recevoir de la données entre le client et le serveur. Les applications Flex supportent de nombreuses techniques de communication distante, basées sur des standards. Voici les trois grandes catégories de communication avec des données distantes (remote data communication) pour les applications RIA Flex:

Communication par Requête/Réponse HTTP

Cette catégorie consiste en plusieurs techniques qui se cumulent. En utilisant le composant HTTPService du framework Flex ou la classe API URLLoader de FlashPlayer, vous pouvez envoyer ou charger de la donnée non-compressée comme des blocs de texte, de la data encodée dans une URL ou des paquets XML. Vous pouvez aussi envoyer et recevoir des paquets SOAP en utilisant le composant WebService du framework Flex. Et vous pouvez utiliser une technologie appelée Flash Remoting, pour envoyer et recevoir des paquets AMF, qui utilise un protocole binaire similaire à SOAP (mais considérablement plus léger). Chaque technique à le même but qui est d'envoyer des requêtes et de recevoir des réponses en utilisant HTTP ou HTTPS.

Communication en temps réel (Real-Time)

Cette catégorie concerne les connexions socket persistantes. Flash Player supporte deux types de connexions: celle qui requiert un format spécifique pour les paquets (XMLSocket) et celles qui autorise les connexions brutes (Socket). Dans les deux cas, la connexion socket est persistante entre le client et le serveur, permettant au serveur d'envoyer des data au client (push data), ce qui est impossible en utilisant les techniques standard de requête/réponse HTTP.

Communication par Upload/Dowload de fichiers

Cette catégorie concerne l'API FileReference, qui est native à Flash Player et qui autorise l'upload de fichiers et de téléchargement direct depuis un application Flex.

Parmi ces trois catégories, il est assez simple de distinguer la communication par Upload/Download des deux autres types. De manière claire, la communication Upload/Download s'applique uniquement pour les cas où l'application à besoin de télécharger ou d'upload un fichier. Cependant, la distinction entre les requête/réponses HTTP et la communication temps réel n'est pas si évidente.

La communication par requête/réponse HTTP est bien plus commune que la communication temps réel. Bien que la communication de données en real-time soit nécessaire pour les applications qui ont besoin d'un faible temps de latence, elle ajoute une en-tête réseau à l'application car elle requiert une connexion socket persistante pour chaque utilisateur. A l'inverse, la communication par requête/réponse HTTP est toujours initiée par le client sous la forme d'une requête. Le serveur retourne une réponse au client, en la connexion est ensuite refermée jusqu'à ce que le client fasse une autre requête. Dans la plupart des cas, le modèle requête-réponse est le plus efficace.

Comprendre les différentes stratégies de Data Communication

Communication par Requête/Réponse HTTP

Vous pouvez travailler sur le modèle requêt-réponse de trois manières: via de simples HTTP services, web services, et Flash Remoting. Chacun a le même but, qui est d'envoyer une requête et d'en recevoir la réponse. La méthode que vous choisirez dépend d'abord du type de service que vous avez de disponible. Par exemple, si vous voulez charger du XML depuis un document XML, vous devriez utiliser un simple HTTP service. Cependant, si vous voulez appeler la méthode d'un web service, vous devriez utiliser la communication par web service.

Services HTTP Simples

La plus basique des communications HTTP requête-réponse utilise ce que l'on appelle les services HTTP simple. Parmi ces services on peut trouver des choses telles que du texte et des ressources XML, aussi bien dans des documents statiques que dynamiques (générés par une page ColdFusion, un servlet ou une page ASP.NET. Ces services HTTP concernent aussi des pages qui lancent des scripts lorsqu'elle sont appelées pour par exemple, insérer ou updater de la données dans une base de données, ou envoyer un email. Vous pouvez utiliser les services HTTP pour exécuter ces comportements serveur, pour charger de la données ou le deux.

HTTPService

URLLoader

Web Services

Flash Player n'a pas de support natif pour les Web Services SOAP. Cependant, Flex propose un composant WebService qui utilise le support des requêtes/réponses HTTP mais aussi le support du XML pour vous permettre de travailler avec des Web Services SOAP. Il y a deux manières de travailler avec le composant Flex WebService: en utilisant du MXML et en utilisant de l'ActionScript.

Flash Remoting

Flash Remoting est une technologie basée sur la communication HTTP type requête/réponse. Flash Remoting a de nombreux avantages, dont:

Data serialization et deserialization sont gérées automatiquement. Cela signifie que quand vous envoyez un objet Date depuis une application Flex, elle est automatiquement convertie au type correspondant sur le serveur (et vice-versa). C'est aussi possible pour les types de données personnalisés.
Flash Remoting utilise AMF, qui est un protocole de transfert binaire, ce qui assure une taille de paquet minimale pour la transmission de données
AMF est un format de transfert nativement compris par Flash Player, ce qui signifie que la data serialization et deserialization sur le client est automatique et rapide
Parce qu'une plateforme reçoit les requêtes sur le serveur et le délèguent aux services correspondant, ces services peuvent être des classes standards du serveur. Ce qui veut dire que peut (voire aucune) adaptation n'est requise pour utiliser des service existants avec Flash Remoting

Flash Remoting est supporté nativement par Flash Player, donc aucune librairie supplémentaire n'est nécessaire pour l'implémentation du côté client pour l'appel de services Flash Remoting. Cependant, sur le serveur, vous aurez besoin d'une passerelle (gateway) capable de recevoir et d'envoyer des paquets AMF en HTTP, serializer et deserializer de l'AMF, et déléguer les requêtes vers les services appropriés.

Voici une liste des principales passerelles Flash Remoting:

AMFPHP (PHP)
OpenAMF (Java)
WebORB (.NET, Java, Ruby On Rails)
Fluorine (.NET)
Adobe Flash Remoting MX (Java, .NET)
ColdFusion (la passerelle Flash Remoting fait partie de l'installation standard de ColdFusion)

> Flash Remoting – Envoyer des requêtes en utilisant NetConnection

Connection Temps-Réel / Socket

Flash Player supporte les connections socket bas-niveau et persistantes, ce qui permet de créer des applications temps réel ayant un faible délai de latence. De plus, avec l'utilisation de sockets binaires (binary sockets), vous pouvez créer des applications Flex qui communiquent directement avec des services autrement inaccessible à Flash Player. Par exemple, les connections binary socket permettent de créer des clients mail, des clients VNC, et bien plus.
Il y a 3 types de connections socket disponibles depuis les applications Flex:

XML Sockets

Connections Socket qui requièrent un protocole de communication spécifique

Binary Sockets

Connections binaire directe

RTMP

Real Time Messaging Protocol est utilisé aussi bien pour les médias (video, audio, etc…) que pour la transmission de données temps réel. RTMP est supporté par Flex Data Services, Flash Media Server, et d'autres applications tierces.

Upload/Download de Fichiers

Les applications Flex supportent l'upload et le download (téléchargement) de fichier en utilisant la classe flash.net.FileReference. Vous pouvez permettre à l'utilisateur de télécharger ou uploader un ou plusieurs fichiers à la fois.