ZK - Simply Rich

Architecture du framework

Description générale

Le framework est séparé en deux parties. Une partie, écrite en Javascript, est embarquée côté client et est chargée d'écouter les évènements de l'interface et de notifier le serveur. L'autre partie, écrite en Java, reste côté serveur. Cette dernière se décompose en deux pour s'occuper d'une part de la compilation à la volée et du rendu et d'autre part de la gestion des évènements et de la mise à jour des composants.

L'architecture est dite "server centric" c'est-à-dire que les traitements sont effectués côté serveur. Ce choix a été fait dans le but de conserver un traitement des données métier sur le serveur. Il est important de garder cette logique pour ne pas avoir une réplication de ces traitements sur le client. Nous verrons ainsi quels données transitent entre le serveur et le client et quelles sont leurs conséquences.

Les trois principales composantes de ce framework sont le ZK Loader, l'AU Engine et le Client Engine. La description de ces trois entités suit le déroulement de l'animation ci-dessus.

Loader

La première étape est la requête reçue par le serveur. C'est une requête HTTP classique. A la réception, le ZK Loader est invoqué par le conteneur web. Il charge alors la page, l'interprète et créer les composants. Pour ne pas prendre trop de temps pour le calcul des composants, ceux-ci sont cachés en mémoire. Grâce à un procédé proche de celui des JSP appelé Dynamic Servlet Page, les composants sont interprétés à runtime.

La page demandée par le client est alors générée et envoyée. Seuls les composants nécessaires sont envoyés car les différents scripts Javascript fournis par ZK sont modulés. Ces composants sont réutilisés par la suite ce qui évite au client de télécharger les ressources plusieurs fois. Le ZK Loader est appelé chaque fois qu'une page est demandée par le client.

Client Engine

La page est reçue par le client qui accède à l'interface générée par le moteur de rendu de son navigateur. Le composant embarqué est écrit en Javascript. Il n'est téléchargé qu'une seule fois par le client grâce au mécanisme de cache des navigateurs.

Le Client Engine fonctionne alors sur le modèle classique des applications lourdes. Il récupère les évènements générés par le client et notifie l'AU Engine. C'est ici qu'intervient le modèle AJAX. Des requêtes XML sont envoyées au serveur afin de transmettre les évènements.

Les communications entre le client et le serveur sont allégées grâce à une gestion intelligente de ces évènements. Ils sont envoyés par groupes et une détection des redondances d'évènements est mise en place. Si l'utilisateur effectue par exemple deux modifications d'un même champ, la modification ne sera effectuée qu'une seule fois à la deuxième valeur directement.

Asynchronous Update

Le dernier composant du framework est celui chargé de traiter les évènements. Son fonctionnement est mis en oeuvre par l'utilisation de handlers. Chaque évènement est attaché à une page et peuvent être gérés les uns à la suite des autres. Ces handlers peuvent être suspendus pour certaines conditions comme lors d'une attente de confirmation de la part de l'utilisateur de l'application.

L'AU Engine reçoit les évènements et les met dans une queue d'évènements. L'application principale les récupère de la queue et met à jour les composants si cela est nécessaire.

L'application via les handlers d'évènements effectue ses traitements et exécute sa logique métier. Cette étape est celle qui fait intervenir l'existant de votre architecture. Vous verrez ici que rien n'a besoin d'être modifié. L'application peut accéder aux autres ressources et sous-couches.

Une fois les composants modifiés, l'AU Engine renvoi alors au client les nouvelles informations. La communication se fait toujours au-dessus du modèle AJAX. Le client n'est notifié que des modifications à effectuer. La réponse contient simplement les instructions de modification du DOM et éventuellement de nouvelles données pour l'affichage.

Spécificités techniques

Du point de vue de la programmation, vous remarquerez qu'aucun développement n'est demandé en ce qui concerne les communications entre le client et le serveur. Vous remarquerez également le modèle simple ne nécessitant pas de connaissances sur les threads. Pourtant, la serveur est toujours capable de traiter des requêtes pour différentes pages simultanément grâce aux handlers attachés aux pages.

Un interpréteur du Java léger, BeanShell, est embarqué dans le framework ZK. C'est la raison pour laquelle il est possible d'écrire directement du code Java dans les pages webs. D'autres langages (ruby, JSP...) sont utilisables de la même manière grâce à d'autres interpréteurs. On retrouve ainsi le confort de développement pour le web qui a fait le succès de langages comme le php ou le ruby.