LCDS se compose de 3 composants principaux : le remoteObject, le MessageService, et le DataService.

Le remoteObject fonctionne avec le protocole AMF, et permet d'invoquer des classes Java côté serveur. On peut également mettre en place un classmapping, qui permettra donc comme son nom l'indique de transférer des VO entre Flex et le serveur et vice-versa. De plus, on pourra utiliser une fonction de token pour tracker les interactions entre le client et le serveur. Enfin, on peut se servir de la gestion des utilisateurs directement côté serveur,en utilisant les rôles de JRun.

Le MessageService fonctionne lui avec le protocole RTMP, le même que celui qu'utilise FMS, et permet, comme son nom l'indique de gérer la transmission de messages entre le client et le serveur. Ces messages pourront contenir des informations simples (texte, par exemple) ou bien des objets plus complexes (objets persos par exemple). Nous pouvons aussi filtrer les messages, afin de savoir exactement qui envoie quoi et qui reçoit quoi. Cette gestion peut se faire côté client (le client recevra tous les messages, mais, après tri n'en affichera que certains), ou bien côté serveur, ce qui permettra d'alléger les besoins en ressource serveur et bande passante (seuls les messages correspondant aux bons destinataires sont renvoyés). Concernant l'authentification, là encore elle pourra se faire côté serveur, en utilisant les rôles de JRun.

Le DataService est pour moi le composant le plus avancé. En partie dérivé du composant MessageService, il utilise le même protocole, et permet d'invoquer des classes Java côté serveur. On mettra alors en place un classmapping, qui permettra de transférer des VO entre Flex et le serveur et vice-versa. De plus, on pourra utiliser une fonction de token pour tracker les interactions entre le client et le serveur.et on pourra aussi se servir de la gestion des utilisateurs directement côté serveur,en utilisant les rôles de JRun. Mais tout ceci se fera en temps réel et c'est là le grand avantage de ce composant. En effet, dès qu'un utilisateur modifiera sur son client des données, les modifications seront automatiquement transmises au serveur qui se chargera alors de "pousser" ces nouvelles données sur les autres clients connectés. De plus, cela permet de voir en temps réel ce que fait chaque utilisateur (pratique pour un chef d'équipe par exemple). Lorsque plusieurs mêmes données seront modifiées en même temps par plusieurs clients, le serveur générera un conflit que l'on pourra traiter sur le client (on affichera par exemple les différences et l'utilisateur pourra choisir quelles données sont prioritaires.). Enfin, ce composant permet la mise en cache des données reçues, ce qui dans le cas d'une application AIR qui devra pouvoir fonctionner aussi en mode déconnecté s'avèrera très utile. Ainsi, les données saisies ou modifiées sur le client en mode offline se verront automatiquement "poussées" sur le serveur dès que la connexion avec le serveur sera rétablie.

Ces trois composants permettent donc de mettre en place un système de gestion de données très performant, en utilisant un serveur dédié, et en facilitant l'intégration aux environnements J2EE. Vous n'êtes pas obligés de réécrire votre logique métier, les classes java utilisées par le serveur ne seront qu'un pont entre votre système d'information actuel et le ou les applications Flex/AIR.

Si vous êtes intéressés par une formation sur cette technologie de pointe, rendez-vous sur mon site de formation, sur lequel je propose un programme concernant LCDS.

Voila...