Compte rendu de la soirée Applications Composites

Serge Huber et Tarek Elachkar de la société Jahia nous ont présenté hier le concept d’applications composites.

Après quelques rappels sur les concepts de Portlets et de Mashup, ils nous ont expliqué en quoi ces modèles ne répondent pas à tous les besoins des applications de gestion de contenu modernes et en quoi les applications composites peuvent changer la donne.

Tarek a commencé par nous montrer un cas d’école d’utilisation des Portlets, avec transformation d’une application Struts classique à l’aide de Struts bridge. Il est néanmoins plûtot rare de tomber sur un cas aussi idéal, et on se retrouve généralement rapidement confrontés aux limitations des portlets, comme :

  • Difficultés pour faire intéragir plusieurs portlets proprement
  • Difficultés pour faire de l’Ajax
  • Difficultés pour gérer les rôles et les groupes

Les applications composites sont baties autour des concepts suivants :

  • Orienté contenu (stockage et hiérarchisation des données fournis par des repositories de contenu comme JCR)
  • Approche REST
  • Développement modulaire

Elles se différencient des Mashup par l’agrégation de services internes possédant de la logique métier afin d’augmenter la valeur de ces services, les mahsup étant plutôt un regroupement de services externes (twitter, facebook…), comme ce que l’on peut voir sur iGoogle ou Netvibes par exemple. Les frameworks d’applications composites fournissent des mécanismes de base réutilisables comme la gestion de la session et des rôles, des fonctions de recherche et de sécurité. Il est possible de développer des applications composites avec Apache Sling ou en utilisant le framework inclue dans Jahia. CMIS est quant à lui un standard pour les applications composites qui commence à monter.

Serge nous a expliqué comment créer des objets de contenu et comment leur associer des comportements via des scripts (jsp, php, groovy…) à partir des API REST de Sling ou de Jahia.
Lors des démos on a pu voir l’efficacité de la solution et la grande puissance du concept.
On obtient avec cette approche un niveau de ré-utilisabilité plus bas que celui des portlets (« application splitting »).
Au lieu de réintégrer une application complète, on intègre des composants réutilisables, par exemple un composant de rating ou de commentaires, qui seront réutilisables et insérables partout dans un CMS: news, forums, évènements….
Ces composants se “branchent” directement sur les objets enregistrés dans JCR pour leur ajouter un comportement.

Pour terminer cette soirée riche en découvertes, nous avons vu une très belle démo d’application iPad composite, basée sur REST/JSON, avec des fonctions offline et capable de pousser du contenu vers le repository JCR (par exemple une photo contenue sur l’appareil).

Et en fin de soirée, à l’heure des pizzas, deux heureux gagnants ont pu remporter des licences JRebel et IntelliJ IDEA!

Vous aimerez aussi...

3 réponses

  1. Meryll Moreau dit :

    Nous avons mis les slides à disposition sur Slideshares
    http://www.slideshare.net/sergehuber/portets-to-composite-applications

    A très bientôt sur Grenoble
    Merci à l’équipe pour l’excellente organisation

  2. brunovernay dit :

    Belle presentation.
    La démo avec les Commentaires et les Ratings qui penvent être « rattachés » aux News ou aux Evenements est impressionnante. Bel exemple de ré-utilisabilité de composants.
    Le fait est que dans le monde Portlet, tout les éditeurs ont leur propre portlet de sondage, de wiki et de calendrier … ce n’est pas qu’il soit difficile de faire des portlets portables, c’est que l’intérêt économique est nul et la tentation d’utiliser des extensions propriétaires bien trop grande. Les portlets standardisent trop ou pas assez.

    La relation entre « Application Composite » et les Portlets n’est toujours pas claire pour moi, mais c’est peut être le fait d’une question ouverte. Remplacement ? Evolution ? chemins parallèles et indépendant ? La démo montrait plutôt un abandon des portlets au profit des « composite application » qui ne prennent des portlets qu’une vague ressemblance graphique. Visiblement les Composite applications sont bâties sur REST, JCR, le décloisonnement des WAR et pas du tout sur le standard Portlet.

    Dans tout les cas, un processus de standardisation permettrait de clarifier la situation et de dire ce que sont et ne sont pas les « Applications Composites ». Ca permettrait aussi à tout le monde d’en profiter !! La JSR Portlet n’a pas évolué depuis trop longtemps.
    Je suis curieux de voir ce qui va arriver dans ce domaine.

  3. Serge Huber dit :

    Bonjour Bruno,

    Merci pour votre retour sur la présentation, je suis content qu’elle vous ait plue.

    Pour répondre à vos questions, il est clair que nous voyons beaucoup d’intérêts aux composites, mais il est certain que les portlets resteront une technologie importante, à la fois pour notre produit et en général, pour l’intégration d’applications existantes ainsi que pour le développement d’applications à l’aide d’outils (mashup generator, portlet generator).

    Du point de vue du développeur, les composites sont réellement intéressants car ils offrent tout « out of the box », et personnellement je dois avouer n’avoir jamais été aussi productif qu’avec ce type de technologies pour réaliser des projets web.

    Je pense qu’une évolution de la specification portlet pourrait aider, mais une standardisation des composites serait véritablement un pas en avant.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.