Atol, nouveau spot de Surf !

Mercredi dernier (15 octobre), j’étais à Munich pour apprendre à surfer !

Le cours était donné par la crème d’Alfresco : Michael « Uzi » Uzquiano (Director of WCM Products), soutenu par David « davidc » Caruana (Chief Architect) et Mike Farman (Director of ECM Products) ; et organisé par Nancy Garrity (Community Manager) en marge de la European Community Conference.

# Architecture

Tout d’abord et contrairement à ce que je disais en mai dernier, Surf n’est pas une évolution des Web Scripts, mais une plate-forme de développement Web à part entière, qui tire parti des Web Scripts, mais pas uniquement (et pas même forcément). Au final, une application Surf reste globalement un ensemble de fichiers XML.
La plate-forme Surf est orientée page, composant et contenu, ce contenu pouvant provenir d’où bon vous semble : un entrepôt documentaire Alfresco bien entendu, mais là encore pas uniquement ni forcément (Alfresco Network par exemple est une application Surf qui n’utilise pas du tout Alfresco).

La notion de contenu ici est également particulière dans le sens où du contenu peut être fourni par les pages et les composants eux-même. Disons pour simplifier qu’un contenu provient d’une source de données externe à l’application. Oui oui, j’ai bien dit externe : une application Surf utilisant Alfresco –probablement le cas le plus courant– n’est pas tenue d’être déployée sur la même machine que l’entrepôt Alfresco, il y accède par des requêtes HTTP sur les Web Scripts mis à disposition et qui donnent accès à toutes les APIs disponibles en Java (ou presque), à savoir la gestion des utilisateurs, des catégories, des droits d’accès, des documents et espaces, etc. Et contrairement à ce qu’on pourrait croire, cette architecture a permis d’améliorer les performances de l’ensemble en forçant les développeurs à limiter le nombre de requêtes effectuées, et donc le nombre d’accès à la base de données et au file-system (et pour ceux qui testeraient l’application Share dans une Labs 3B, sachez que la version 3.0 Entreprise est quasi-identique en fonctionnalités mais avec de bien meilleures performances).

Les échanges avec les fournisseurs de contenus et/ou de services (endpoints) s’effectue au travers de connecteurs qui gèrent les interactions (HTTP, JDBC, SOAP, etc.) ainsi que le mode d’authentification (délégué à des authentifieurs). Des credential vaults s’occupent de gérer les différentes identités de l’utilisateur selon l’endpoint contacté, faisant office de Single-Sign On. Ainsi, même si ce n’est pas tout à fait opérationnel au moment où j’écris, Alfresco Network sert de point d’entrée unique, à authentification unique, pour les différentes applications d’Alfresco : forums, JIRA, support technique, wiki, etc.

# Fonctionnement

Basiquement, dans Surf, une URL identifie une page, un type de page ou un contenu. Un type de page se résoud en une page selon le theme courant (par exemple, une page d’édition du profil utilisateur pourra être différente selon que l’utilisateur est un employé, un fournisseur ou un client). De même, un contenu se résoud en une page selon son type et les content associations (pour un contenu Alfresco, son type Alfresco : cm:content, cm:folder, etc. ce qui fait tout de suite penser au mécanisme de dispatch déjà présent dans le client JSF).

Nous avons donc une page. Celle-ci indique un niveau d’authentification requis (même principe que pour les Web Scripts) et référence un template instance. Ce template instance se contente la plupart du temps de donner le nom d’un template FreeMarker, dans lequel des directives particulières pourront être utilisées pour définir des régions dans lesquels viendront se loger les composants. Le rôle d’un template instance et de son template est de définir une présentation globale de la page (layout) et d’assembler des composants.

Chaque région est nommée et a une portée (globale, template instance ou page). C’est grâce à ces deux propriétés, complétées le cas échéant du nom du template instance ou de la page, que sont définis les component bindings, à savoir la configuration déterminant quel composant viendra se loger dans chaque région.

Le composant est la pièce maîtresse d’une application Surf, et correspond la plupart du temps simplement à un Web Script. L’API disponible pour ces Web Scripts est bien évidemment différente de celle des Web Scripts côté entrepôt Alfresco, et pour une fois est unifiée entre JavaScript et FreeMarker (et même Java d’ailleurs ; on parlera donc plutôt d’API Surf).

Enfin, il faut ajouter à cela les associations de pages qui permettent de définir de façon centralisée les liens entre les différentes pages de l’application (on construira donc les menus de navigation et autres « plan du site » de façon dynamique à partir de ces informations), les composants de chrome qui peuvent s’intercaler entre le template et le composant pour générer du code HTML complémentaire, à des fins de mise en forme principalement (dans un esprit de « thème graphique » donc), et les éléments de configuration, définissables à différents niveaux (global, composant, Web Script) et accessible par l’API Surf.

Tout ceci sans oublier les fonctionnalités nouvelles ou améliorées de dispatch sur URL (avec placeholders accessibles par l’API Surf, contrairement aux Web Scripts 2.1/2.2), internationalisation / régionalisation (I18N / L10N), négociation de contenu (voire de langue), le JavaScript d’un Web Script peut être différent selon le type de données envoyé par le client (pour les requêtes POST et PUT) avec en sus accès direct à ces données, éventuellement pré-parsées (cas de JSON ou XML par exemple), etc. et la possibilité de remplacer chaque composante du système : créateur de liens, page mapper, fabrique d’utilisateurs, etc.

Ah, j’oubliais encore : une application Surf étant un ensemble de fichiers XML, ils peuvent également être stockés dans un Alfresco, et plus particulièrement dans les AVM de WCM. Et Alfresco nous prépare un « studio » d’édition de sites WCM « à la volée » pour la version 3.1, ça promet !

# Le mot de la fin

Et pour résumer tout ça, disons tout simplement que Surf est la brique qui nous manquait pour faciliter le développement d’applications métier gérant des documents : parapheur électronique, gestion de courrier, etc.