Installation
Comme dans l’article précédent, je vous ai préparé un projet maven avec le code et l’ensemble compilé si vous voulez tester rapidement. Télécharger le fichier portlet_article03.zip et décompressez-le dans un répertoire différent. Vous pouvez ensuite soit lancer le projet IDEA IntelliJ, soit le project Eclipse (mvn eclipse:eclipse).

Le fichier war doit être recopié dans le répertoire webapps de votre installation de GateIn. Vous devez avoir lu le premier article pour savoir comment ajouter une Portlet à GateIn la première fois. Pour le reste, c’est assez simple.

Les Préférences des Portlets
Voici ce que nous allons faire: nous allons déclarer une propriété de configuration afin que le nom du compte Twitter soit configurable. Lorsque la Portlet sera en mode EDIT, vous pourrez configurer le nom du compte Twitter à afficher. Enfin le mode configuration de GateIn vous montrera aussi votre propriété.

La spécification des Portlets vous donne un objet PortletPreferences afin de stocker les paramètres de configuration de la Portlet. Par exemple l’adresse d’un serveur REST distant pour récupérer une liste de médicament (au hasard). Les propriétés d’une Portlet sont spécifiques à chaque utilisateur. Par ailleurs, elles sont sauvegardées lorsque vous arrêtez le serveur. Nous verrons cela tout à l’heure.

Comment utiliser une propriété d’une Portlet
Nous allons tout d’abord regarder ce que j’ai déclaré dans le fichier portlet.xml. La balise portlet-preferences permet de déclarer des couples clés/valeurs, comme un fichier de propriétés. J’ajoute ici une nouvelle propriété « defaultScreenName »

<portlet>
       <description>Twitter Portlet sample 02, this portlet demonstrates how to set and display
           a public portlet render parameter.
       </description>
       <portlet-name>TwitterPortlet02</portlet-name>
       <portlet-class>org.letouilleur.portlet.TwitterPortlet02</portlet-class>
       <supports>
           <mime-type>text/html</mime-type>
           <portlet-mode>view</portlet-mode>
           <portlet-mode>edit</portlet-mode>
       </supports>
       <portlet-info>
           <title>Twitter Portlet 02</title>
           <keywords>demo</keywords>
       </portlet-info>
       <portlet-preferences>
           <preference>
               <name>defaultScreenName</name>
               <value>Letouilleur</value>
           </preference>
       </portlet-preferences>

   </portlet>

Cette propriété sera configurée à « Letouilleur » pour les utilisateurs n’ayant pas encore personnalisé la valeur.

Regardez maintenant le fichier viewPortlet02.jsp. Cette page est la page du mode VIEW de la portlet TwitterPortlet02. Elle affichera le nom du compte. Voici comment je récupère les préférences afin d’afficher le nom du compte Twitter:

<%
       String tweeterAccount=renderRequest.getPreferences().getValue("defaultScreenName", "Anonymous");
%>

   <h4>Latest Twitter statuses from <font color="blue"><%=tweeterAccount%></font></h4>

Comment modifier la propriété ?
La portlet TwitterPortlet02 est déclarée avec 2 états dans le fichier portlet.xml : EDIT et VIEW. Lorsqu’elle bascule en mode EDIT, il est possible de changer le nom du compte Twitter.

Voici la vue de la Portlet en mode VIEW :

Voici la Portlet en mode EDIT :

Que se passe-t-il lorsque l’on clique sur le bouton « Soumettre » ? Comme vu dans l’article précédent, cela déclenche la phase Action de la Portlet. Dans la class TwitterPortlet02, regardez le code de la méthode processAction:

@Override
public void processAction(ActionRequest request, ActionResponse response)
						throws PortletException, IOException {

   if (request.getPortletMode().equals(PortletMode.EDIT)) {
            sendActionEvent(request, response);
   }

   // ....

}

//....

private void sendActionEvent(ActionRequest request, ActionResponse response)
							throws PortletModeException, ReadOnlyException,
								   IOException, ValidatorException {
	// Recupere le parametre envoye par le formulaire HTML
	String screenName = request.getParameter("screenName");

	// Change la valeur de la preference
	PortletPreferences prefs=request.getPreferences();
	prefs.setValue("defaultScreenName",screenName);
	prefs.store();

    // ...

	// back to view mode
	response.setPortletMode(PortletMode.VIEW);
 }

Il est important de bien penser à appeler la méthode store() afin que la nouvelle valeur de la propriété soit stockée par le Portail. Est-ce que vous vous rendez compte que c’est le Portail qui va stocker cette nouvelle valeur ? Si vous n’êtes pas convaincu, arrêter et relancez GateIn, reconnectez-vous avec le même utilisateur, vous verrez que la valeur a été persisté par GateIn.

Il y a quelques détails à connaître : tout d’abord le contenu du PortletPreferences ne peut être modifié que dans la méthode processAction(). Il y a aussi une méthode reset() que vous pouvez appeler pour remettre les préférences à un état stable avant vos changements. Pratique lorsqu’une exception survient.

Il est temps maintenant d’informer les autres Portlets que vous venez de changer le nom du compte Twitter.

Envoyer un événement JSR-286 avec une Portlet
Voici ce que je veux faire : lorsque l’utilisateur change le nom du compte Twitter, j’aimerai que ma Portlet envoie aux autres Portlets la valeur de ce compte. Imaginons une autre Portlet qui par exemple recherche sur des flux RSS en se basant sur le nom d’un compte Twitter, ou d’un tag (comme #devoxx).

Pour envoyer un événement, il faut tout d’abord le déclarer dans le fichier portlet.xml

(fichier portlet.xml)

<event-definition>
    <name>myEvent</name>
    <value-type>java.lang.String</value-type>
</event-definition>

Pour que le Portail surveille notre Portlet TwitterPortlet02, il convient maintenant de dire que cette Portlet peut émettre cet événement. Dans la balise portlet, j’ajoute à la fin un tag « supported-publishing-event »

<portlet>
    <description>Twitter Portlet sample 02, this portlet demonstrates how to set and display
        a public portlet render parameter.
    </description>
    <portlet-name>TwitterPortlet02</portlet-name>
    <portlet-class>org.letouilleur.portlet.TwitterPortlet02</portlet-class>
    <supports>
        <mime-type>text/html</mime-type>
        <portlet-mode>view</portlet-mode>
        <portlet-mode>edit</portlet-mode>
    </supports>
    <portlet-info>
        <title>Twitter Portlet 02</title>
        <keywords>demo</keywords>
    </portlet-info>
    <portlet-preferences>
        <preference>
            <name>defaultScreenName</name>
            <value>Letouilleur</value>
        </preference>
    </portlet-preferences>

    <supported-publishing-event>
        <name>myEvent</name>
    </supported-publishing-event>

</portlet>

Enfin, nous voulons que la portlet TwitterPortlet01 écoute cet événement. Pour cela, voici la définition de la portlet TwitterPortlet01. Nous ajoutons un tag « supported-processing-event » avec le nom du tag.

<portlet>
    <description>Twitter Portlet sample 01, this portlet demonstrates the processAction method.</description>
    <portlet-name>TwitterPortlet01</portlet-name>
    <portlet-class>org.letouilleur.portlet.TwitterPortlet01</portlet-class>
    <expiration-cache>0</expiration-cache>
    <supports>
        <mime-type>text/html</mime-type>
        <portlet-mode>view</portlet-mode>
    </supports>
    <supported-locale>fr</supported-locale>
    <supported-locale>en</supported-locale>

    <portlet-info>
        <title>Twitter Portlet 01</title>
        <keywords>demo</keywords>
    </portlet-info>

    <supported-processing-event>
        <name>myEvent</name>
    </supported-processing-event>

</portlet>

A savoir : si les 2 portlets sont distribuées dans 2 WAR différents, il faut déclarer un element QName afin de qualifier le domaine de l’élément. Par ailleurs l’ordre des tags dans le fichier portlet.xml est déterminant pour GateIn. Si vous souhaitez déclarer qu’une portlet est capable d’émettre comme de recevoir un événement, attention à l’ordre de déclaration dans le fichier portal.xml.

     <supported-publishing-event>
         <name>myEvent</name>
     </supported-publishing-event>

     <supported-processing-event>
         <name>anotherEvent</name>
     </supported-processing-event>

     <supported-processing-event>
         <name>andYetAnotherEvent</name>
     </supported-processing-event>

Envoyer un événement
L’envoi est très simple. Dans la phase d’Action d’une Portlet, il suffit d’appeler la méthode setEvent sur l’object ActionResponse. Regardez le code de la méthode sendActionEvent de TwitterPortlet02, voici comment la valeur du nouveau compte Twitter est envoyé au Portail

        // Send an event
        response.setEvent("myEvent", screenName);

Recevoir un événement
La réception de l’événement par la Portlet TwitterPortlet01 est effectué dans la méthode processEvent, héritée de GenericPortlet. La nouvelle valeur du compte Twitter est lue puis stockée comme nouvelle valeur de myPublicScreenName.

 /**
     * This callback method is triggered when a "myEvent" JSR-286 event
     * is sent to the Portal.
     */
    @Override
    public void processEvent(EventRequest request, EventResponse response) {
        Event event = request.getEvent();
        if (event.getName().equals("myEvent")) {
            String payload = (String) event.getValue();
            //process payload here
            System.out.println("------------------------------------------------------");
            System.out.println(getClass().getName() + " received an event: " + payload);
            System.out.println("------------------------------------------------------");

            // Update the property, the Portal will then call the doView
            // to redisplay the page
            myPublicScreenName=payload;

        }
    }

Après l’appel de la phase Action de cette Portlet, le portail appelle ensuite automatiquement une phase Render, ce qui pour a effet d’appeler la méthode doView de TwitterPortlet01. Je stocke alors la nouvelle valeur dans la session de la Portlet, c’est tout.

    public void doView(RenderRequest request, RenderResponse response)
            throws PortletException, IOException {

        if (WindowState.MINIMIZED.equals(request.getWindowState())) {
            return;
        }

        // Set the last value of myPublicScreenName
        request.getPortletSession().setAttribute("myPublicScreenName",myPublicScreenName);

        if (WindowState.NORMAL.equals(request.getWindowState())) {
            normalView.include(request, response);
        } else {
            maximizedView.include(request, response);
        }

    }

Enfin pour terminer, l’affichage de la nouvelle valeur s’effectue dans la page « normal.jsp » à la fin de la page:

    <% String publicParam =(String)portletSession.getAttribute("myPublicScreenName");%>
  <% if (publicParam != null && !publicParam.equals("")) { %>
      The other Portlet is configured to display <strong><%=publicParam%></strong>
  <% } %>

Le résultat final
Voici une suite de captures d’écran, afin de vous montrer le résultat :

Etape 1:

Etape 2:

Etape 3:

Conclusion
Dans ce troisième article nous avons vu comment lire et éditer les préférences d’une Portlet. Nous avons ensuite vu comment créer un message, l’envoyer et enfin le consommer dans une autre Portlet. Les prochains articles seront moins bas niveaux que celui-ci mais j’ai pensé qu’il serait intéressant de vous montrer les bases des Portlets 2.0

Voir aussi les 2 anciens articles:
- Premiers pas avec GateIn, comment installer une Portlet
- GateIn, découverte d’une Portlet simple

Une Portlet comme vous allez vous en rendre compte, n’a rien de très visuel. Lorsque l’on pense Portlet au départ, on imagine une petite fenêtre dans une page web, avec des boutons maximiser/réduire/configurer. Or c’est le portail qui donne cet habillage, pas la spécification des Portlets en elle-même.

Nous allons utiliser encore ici ce qu’il y a de plus simple, à savoir des pages JSP sans outils supplémentaires. Nous verrons dans quelques articles comment écrire une Portlet avec JSF 1.2 et comment utiliser le bridge JSF 2.0 de GateIn.

Une portlet c’est avant tout une application web java avec un fichier web.xml. Liferay 5.2 part d’un fichier web.xml, et le décore lors du déploiement dans le conteneur d’application. Cela peut sembler séduisant au premier abord : un fichier web.xml vide complètement anonyme par rapport au portail. Mais il n’y a pas de magie, Liferay se contente de réécrire sa version du fichier web.xml dans le répertoire webapps du conteneur Tomcat.

Concernant GateIn, notre fichier web.xml déclare un PortletApplicationListener et un ServletWrapper. Le fichier web.xml d’une portlet sera différent pour chaque portail : Apache Pluto, Jahia, Liferay et donc GateIn. C’est une des limites de la portabilité des portlets. Peut-être que la solution du fichier web.xml vide pour Liferay est la voie à suivre, je ne sais pas.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
                         "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
	<display-name>texpress-portlet</display-name>

	<listener>
		<listener-class>org.exoplatform.services.portletcontainer.impl.servlet.PortletApplicationListener</listener-class>
	</listener>

	<servlet>
		<servlet-name>PortletWrapper</servlet-name>
		<servlet-class>org.exoplatform.services.portletcontainer.impl.servlet.ServletWrapper</servlet-class>
	</servlet>
	<servlet-mapping>
		<servlet-name>PortletWrapper</servlet-name>
		<url-pattern>/PortletWrapper</url-pattern>
	</servlet-mapping>
	<servlet-mapping>
		<servlet-name>PortletWrapper</servlet-name>
		<url-pattern>/PortletWrapper/*</url-pattern>
	</servlet-mapping>
</web-app>

Voyons maintenant ce qui est vraiment du domaine des Portlets, le fichier portlet.xml. Placé dans le répertoire WEB-INF, ce fichier permet de déclarer la liste des Portlets contenues dans l’archive. Pour notre exemple nous allons pour l’instant déclarer qu’une seule portlet Java :

<?xml version="1.0" encoding="UTF-8"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="1.0">

	<portlet>
		<description xml:lang="EN">Twitter Portlet sample 01, this portlet demonstrates the processAction method</description>
		<portlet-name>TwitterPortlet01</portlet-name>
		<portlet-class>org.letouilleur.portlet.TwitterPortlet01</portlet-class>
		<supports>
			<mime-type>text/html</mime-type>
			<portlet-mode>view</portlet-mode>
		</supports>
		<portlet-info>
			<title>Twitter Portlet 01</title>
			<keywords>demo</keywords>
		</portlet-info>
	</portlet>

</portlet-app>

La portlet TwitterPortlet01
J’aimerai écrire une Portlet capable d’afficher les 10 derniers tweets de mon compte Twitter. A terme je veux pouvoir configurer le nom de la personne que je regarde, et je veux aussi pouvoir informer d’autres Portlets lorsque je change le nom du compte Twitter. Dans un premier temps nous allons simplement compiler et déployer notre Portlet sur GateIn. Si vous ne l’avez pas encore lu, lisez mon article précédent sur GateIn afin d’apprendre à déployer une Portlet sur GateIn.

Je vous ai préparé un petit projet maven avec une portlet toute simple pour cet article. Téléchargez le fichier zip ici et décompressez-le dans un répertoire.

Compilez le projet avec Maven 2.2.1, et Java 6. Et enfin recopiez le fichier WAR vers le répertoire webapps de GateIn. Après avoir ajouté la Portlet dans une nouvelle page, voici ce que vous devez obtenir à l’écran :

Pour ajouter la portlet, relisez l’article de la semaine dernière

Notre portlet a un bouton Submit qui va récupérer mes derniers messages sur Twitter. Pour l’instant, nous allons simuler cette étape, et simplement afficher une liste envoyée par la Portlet. Ouvrez le code Java de la class TwitterPortlet01 et regardons ensemble la fin du fichier.

  @Override
    public void processAction(ActionRequest request, ActionResponse response) throws PortletException, IOException {
        java.util.List<String> tweets = new ArrayList<String>();
        tweets.add("Premier Tweet");
        tweets.add("Deuxième Tweet");
        tweets.add("Troisième Tweet");

        request.getPortletSession().setAttribute("tweets", tweets);

    }

Là où une Servlet dispose d’une méthode doGet ou doPost, une Portlet s’abstrait du protocole et déclare 2 phases. Une phase de rendu et une phase d’action. La phase de rendu correspond simplement à un affichage de la portlet. La phase d’action est activée lorsque vous envoyez un formulaire par exemple à partir de la partie Web de l’application. Enfine une phase de rendu est toujours lancé après une phase d’action. Dans notre cas, la méthode doView est appelé lors de la phase « Render ». Ensuite lorsque vous cliquez sur « Get tweets », la phase « Action » est déclenchée et nous passerons dans la méthode processAction. Celle-ci place dans la session de la portlet une liste de String, et la phase de « Render » est appelée, ce qui provoque l’affichage de la liste dans le fichier normal.jsp. Nous verrons plus loin comment déclarer des attributs de rendus publics, et comment aussi envoyer des événements entre Portlet. Pour l’instant, tout ce que nous faisons est relativement simple.

Il est possible d’utiliser aussi des annotations avec les Portlets 2.0. Il est donc possible d’ajouter une annotation @ProcessAction(name=’theActionName’) afin de dispatcher automatiquement un appel entrant vers une méthode. Dans le cas où une méthode est annotée avec ProcessAction, il faut par contre retirer la méthode générique processAction de GenericPortlet, faute de quoi aucun appel ne sera effectué vers votre méthode annotée.

Du côté de la JSP
Ouvrez maintenant la page « normal.jsp » situé dans le répertoire web-apps. Tout d’abord on notera la présence d’une nouvelle taglib pour les Portlets 2.0, qui permet de déclarer automatiquement un certain nombre d’objets pratiques.

<%@ page import="java.util.List" %>
<%@ page pageEncoding="UTF-8" %>
<%@taglib uri="http://java.sun.com/portlet_2_0" prefix="portlet" %>

<portlet:defineObjects/>
<div id="content">
 <img src="<%=renderResponse.encodeURL(renderRequest.getContextPath())%>/logo.jpg" alt="Logo" align="top"/>
    <h2>GateIn Twitter Portlet</h2>
    <h4>Latest Twitter statuses from Letouilleur</h4>
    <%
        List<String> tweets = (List<String>) portletSession.getAttribute("tweets");
        if (tweets != null) {
            out.println("<ul>");
            for (String tweet : tweets) {
                out.print("<li>");
                out.print(tweet);
                out.println("</li>");
            }

            out.println("</ul>");
        }
    %>

    <portlet:actionURL var="myAction" portletMode="view"/>

    <form action="<%=myAction%>" method="post">
        <input type="submit" value="Get Tweets from Letouilleur"/>
    </form>
</div>

Le tag <portlet:defineObject> permet de déclarer automatiquement un certain nombre d’objets pour notre page JSP. Dans notre exemple cela permet de construire l’URL de l’image du logo du blog le Touilleur Express :

<img src="<%=renderResponse.encodeURL(renderRequest.getContextPath())%>/logo.jpg"
            alt="Logo"
            align="top"/>
 

Nous pouvons aussi récupérer la session de la portlet afin de retrouver notre liste de messages

List<String> tweets = (List<String>) portletSession.getAttribute("tweets");
...

Pour construire l’URL de la FORM il suffit d’utiliser le tag actionURL comme dans cet exemple:

   <portlet:actionURL var="myAction" portletMode="view"/>

   <form action="<%=myAction%>" method="post">

Enfin voici le résultat lorsque l’on clique sur le bouton Submit :

Conclusion
J’ai présenté un exemple simple dans cet article en vous expliquant le principe des 2 phases des Portlets, ainsi que l’utilisation de la taglib des Portlets. Nous verrons dans un prochain article comment gérer encore plus de fonctionnalités des Portlets avec GateIn. Le prochain article sera disponible la semaine prochaine, voici une capture d’écran pour vous faire patienter:

]
Le prochain article sera publié le 27 novembre.

A bientôt

Le code source de l’article est disponible à cette adresse.

Un portail offre un grand nombre de services à une application web
Si vous avez déjà développé des applications webs en Java, vous serez d’accord sur le fait que les besoins fonctionnels et techniques des applications webs sont récurrents. Justement, les Portails d’intégration offrent un ensemble de fonctions standards. Voyons d’abord ce qu’il est possible de faire.

Les services offerts par un Portail sont :
– la gestion de l’authentification des utilisateurs
– l’autorisation afin de déterminer les droits d’accès aux différentes parties de l’application
– la personnalisation afin que l’application web s’adapte au profil du visiteur (P13N)
– la possibilité de personnaliser son interface web facilement
– la gestion de la navigation et sa définition (catégories, pages, sections)
– création des pages de contenu (pages statiques, intégration de pages d’un autre serveur)
– gestion de l’internationalisation (I18N)
– la possibilité d’intégrer du contenu web d’une application distante
– le support sans restriction des frameworks Web
– la possibilité de mettre en ligne des services dans des Portlets rapidement
– la capacité à offrir une version adaptée aux téléphones portables
– l‘offre de composants standards Web 2.0 comme Wiki, Blog, Aggregateur, Mash-ups, etc
– le support des Gadgets à la Google
– la possibilité d’offrir des services de recherche, de gestion de contenu, de gestion électronique de document

Un moteur de Portail open-source du monde Java comme GateIn (JBoss Portal + eXoPortal) ou Liferay est donc un moyen de gagner du temps en évitant de développer ou de devoir gérer des fonctions standards d’une application Web. L’installation est simple : un WAR déployé sur un serveur J2EE léger, et c’est tout.

Si vous disposez d’une application Web Java, le déploiement s’effectue en quelques clics dans le portail. Pour aller plus loin, la création de quelques portlets permet en fait d’exposer les fonctions clés de son application web, afin que le Portail puisse gérer le cycle de vie et l’affichage de votre portlet.
Une chose intéressante à noter : vous êtes libre d’utiliser n’importe quel framework Web : GWT, Wicket, JSF ou autre. De ce fait, la migration d’une application J2EE est donc relativement simple.

Qu’est-ce qu’une Portlet ?
Les Portlets 2.0 ont été normalisées en juin 2008. C’est une spécification assez bas niveau, proche des Servlets. Une Portlet est une enveloppe pour votre application web. Elle dispose de différents états : minimisée, normal, maximisée. Il est aussi possible de basculer d’un mode vue à un mode édition pour la configuration. Du côté du code, en attendant que je vous propose d’autres articles, il y a une distinction entre la phase de rendu et la phase d’action. Le rendu est simplement l’action d’afficher la Portlet. La phase d’action permet de gérer les interactions entre l’utilisateur et l’application web. Enfin il est possible d’émettre des événements afin que d’autres Portlets soient notifiées et puissent interagir avec votre Portlet. C’est relativement simple, l’API Portlet 2.0 propose des annotations qui permettent de marquer vos méthodes. Il y a une petite gymnastique à apprendre afin d’adapter vos pages de rendus par rapport à la navigation. Du côté de la gestion des ressources (js,css,images) il est nécessaire que la Portlet gère le chargement de ces ressources, en raison de la gestion de la sécurité et du cache.
Le contenu d’une Portlet enfin peut être caché par le Portail afin d’éviter le rechargement systématique du contenu.

Les portlets offrent en fait un moyen standard et normaliser de déployer son application et d’interagir avec d’autres Portlets. Et il est tout à fait envisageable d’écrire des Portlets standards, sans tomber dans le piège d’utiliser une API propriétaire.

Le modèle de programmation des Portlets (avec l’aide de Julien Viet d’eXo Platform)
Le modèle de programmation natif d’une Portlet est similaire à celui des Servlets. Il se fait via le package javax.portlet. Le modèle de programmation est légèrement différent, comme expliqué au paragraphe précédent. La plupart des équipes de développement n’utiliseront pas directement l’API, pour la même raison que l’API Servlet en général n’est pas utilisée directement mais via un framework.

En effet, la plupart des frameworks modernes proposent un adaptateur pour Portlet (Portlet Bridge). Avec un modèle de programmation bien pensé, l’exécution en mode Portlet ou directement dans une application web ne présente pas de différences pour le framework. Si vous débutez un projet basé sur des Portlets, il sera important de s’assurer de ce support dans votre framework Web avec un adaptateur pour Portlets. Les plus connus possèdent tous un bridge comme Java Server Faces (via la JSR 301 Portlet Bridge Specification), Wicket, Struts2 et Tapestry.

D’autres framework web tel que Spring MVC ne proposent pas une telle portabilité mais néanmoins fournissent un support pour les Portlets en adaptant le framework à l’API Portlet. J’ai codé une Portlet avec Spring MVC sans soucis, grâce à SpringFuse l’outil de Celerio.

Finalement pour de vieilles technologies telles que Struts 1, il existe des bridges mais qui sont gérés à un niveau en dessous avec une émulation de la couche Servlet via une Portlet. En général ce type de bridge a des limitations.

Les Portlets permettent de travailler à plusieurs équipes sur une même application web
Je prends le temps de vous parler de déploiement car le principe des Portlets permet de travailler par modules. Imaginez plusieurs équipes de développement qui travaillent sur un portail web d’entreprise. En se donnant rendez-vous techniquement sur un Portail, vous pouvez donc offrir un moyen pour chaque équipe de travailler de son côté, avec une installation locale de Liferay ou de GateIn, puis de livrer simplement leurs Portlets vers le serveur de production. Un administrateur se chargera alors d’ajouter et de mettre en place les Portlets du premier projet. J’y vois donc un moyen de faciliter le travail de plusieurs équipes. En effet, c’est bien plus souple que d’imaginer livrer un gros WAR constitué de plusieurs projets développés par plusieurs équipes. Imaginez la difficulté pour l’intégration et la mise en production. Un Portail d’intégration est donc un serveur mutualisé sur lequel plusieurs équipes déposent des Portlets, qui constituent au final une application Web complète.
Le portail permet de découpler le cycle de vie du portail et des applications qui le composent. En effet vous pourrez facilement intégrer de nouvelles applications dans le portail à tout moment. Un autre intérêt de ce type d’architecture est l’intégration d’applications basées des technologies hétérogènes. Vous pourriez vouloir intégrer dans votre portail une application développée 2 ans auparavant par une filliale de l’entreprise par exemple.

Chez le client chez lequel je travaille en ce moment, ce sera le moyen pour trois équipes à Paris, une à Londres et une à New-York de construire une plateforme de Prime Brokerage avec la même charte graphique, une seule authentification, la gestion de plusieurs langues, et surtout vous l’aurez compris, la possibilité pour chacune de ces équipes de travailler sur leurs Portlets et de les tester en local avec un Portail open-source avant le passage en production.
Les Portlets ne sont pas révolutionnaires. Par contre, c’est l’utilisation dans votre architecture qui le sera. En effet, si vous avez aujourd’hui plusieurs équipes ayant réalisées chacune une application web, il est possible de repenser le système non pas avec une architecture SOA, mais une architecture Web Portal. Au lieu d’agréger des services différents dans un seul endroit pour construire une seule application web, vous offrez la possibilité à chaque équipe de livrer une tranche verticale qui va de la donnée à la couche web en passant par la couche service. Et quelque part, est-ce qu’une application Web dont l’architecture serait définie par l’interface graphique n’a pas plus de sens qu’une application web construite comme un puzzle de services ?

L’exemple d’Amazon.com
La page d’Amazon.com est construite par 34 équipes différentes. Chacune des parties de la page est une Portlet. C’est assez génial car la mise en production d’une nouvelle version n’est plus un problème : il n’y en a plus !
Terminé la mise en ligne d’une application Web complète.

Alors comment font-ils ?
Lorsqu’une équipe est confiante sur une nouvelle fonction, une nouvelle version de sa Portlet est activée sur le Portail. En cas de problèmes, l’administrateur peut aussi rapidement désactiver une Portlet, voire même recharger une version antérieur. Quand on pense à Scrum, à de l’incrémental, il paraît évident que ce Portail va vraiment devenir votre ami non ?

Une porte ouverte vers une architecture WoPA (Web Oriented Portal Architecture)
Je pense que les applications d’entreprises sont amenées à s’ouvrir de plus en plus. Nous avons pensé un moment qu’une architecture orientée service serait la solution. Ces 5 dernières années en effet, nous sommes passés d’architectures client-serveur (J2EE 1.4 avec les EJB2.1, Corba, RPC) à des architectures où la Donnée a reprit de l’importance avec les architectures REST. Personne ne semble vraiment savoir ce que représente l’architecture orientée service, à part les éditeurs de logiciels très friand d’acronyme dans leurs plaquettes publicitaires.
Une architecture WoPA (copyright N.Martignole) avec un Portail d’intégration, est une application capable de combiner le travail de plusieurs équipes, de plusieurs projets, dans un seul endroit : le Portail Web. Cela remet en avant l’importance des données plutôt que de leur logiciel. Je pense surtout au monde de la Banque, où l’IT est important. Vous n’imaginez pas le nombre d’équipes et de projets chez le client où je travaille en ce moment.

L’idée novatrice est aussi que l’interface Web n’est peut-être pas la partie la plus importante de votre application. A l’extrême, il est dommage de proposer un GUI Web et de ne rien proposer à vos clients afin qu’ils viennent chercher les Données directement. Bref ne pas faire de REST devrait être refusé par la DSI dans un schéma d’architecture.

Pour expliquer cela, pensez à Twitter.com. Il s’avère que l’API de Twitter est utilisée 10 fois plus que le site web de Twitter. Pourquoi finalement votre application ne serait-elle pas utilisée non pas avec votre GUI Web que vous avez développé, mais via un Portail capable de venir chercher de la Donnée ? Est-ce que votre valeur ajoutée est de faire une application Web ou d’exposer de la Donnée de manière intelligente ?

Conclusion
C’est donc via une solution standard comme un Portail d’intégration et les Portlets qu’il semble plus logique de s’orienter, dès lors que plusieurs équipes exposent des données et des services aux utilisateurs.
Je crois à une solution où l’intégration du travail de plusieurs équipes est fait dans un Portail dès lors qu’auparavant, chacune d’elles proposaient une interface Web différente.

Merci à Julien Viet de la société eXo Platform pour sa relecture et ses corrections.

Ressources
Liferay est un portail open-source lancé en 2000 qui est compatible avec les standards Javas comme la JSR-168 (Portlet 1), JSR-286 (Portlet 2), JSR-170 (JCR)

GateIn est un portail open-source constitué par la fusion de JBoss Portal et d’eXo Portal. Avec une interface très puissante, le support des standards (JSR-168,286,170), la possibilité d’ajouter des Gadgets facilement, c’est l’un des portails les plus en vogue en ce moment.
http://www.jboss.org/gatein et http://www.exoplatform.com

Oracle Weblogic Portal 10g est la version actuelle du portail d’Oracle. La version 11 devrait sortir à la fin de cette année avec le support de la JSR-286.

Présentation de Dion HINCHCLIFFE sur Web Oriented Architecture

ProgrammableWeb est un annuaire d’API et de Mashup

Démonstration de la fonction Mashup d’Oracle Weblogic Portal

La JSR-301 est la Portlet Bridge Specifications for JSF, en cours de finalisation.

La JSR-286 est la spécification des Portlets 2.0 à laquelle eXo Platform, Liferay et Oracle ont participé

La JSR-170 est la spécification Java Content Repository, implémentée par le moteur d’eXo Portal et de Liferay.

(Liens ci-dessous ajoutés suite à la remarque d’Alexis)

IBM propose IBM Web Portal http://www-01.ibm.com/software/fr/info1/websphere/

SUN Microsystems propose GlassFish Web Space Server basé sur Liferay http://www.sun.com/software/products/webspace/index.xml. Il y a une bonne présentation de 20 minutes très intéressante ici

Vignette propose Vignette Portal 8 http://www.vignette.com

J’ai oublié de citer l’implémentation de référence de la JSR-168 et de la JSR-286 : Apache Pluto

La spécification des Portlets 2.0 est sortie en juin 2008. Thomas nous donne un retour un an après de la conférence. Lui-même contributeur depuis 2004 sur JBoss Portal, une année sur JBoss Seam, il est aujourd’hui le responsable du projet JBoss Portal chez RedHat.

L’agenda de sa présentation sera :
- Quelles sont les nouvelles fonctionnalités de la version Portlet 2.0
- Adoption par les vendeurs
- La portabilité
- Portlets versus Gadgets

Dans un premier temps, retour sur la JSR-286 Portlet 2.0 sortie l’an passé. Tout d’abord l’une des innovations les plus importantes est ce qu’il appelle « Resource Serving ». L’objectif est de permettre l’envoi de données vers le navigateur qui ne font pas partie du portail, comme un fichier PDF ou Excel par exemple, tout en conservant les fonctionnalités d’une portlet. Cette spécification vise donc à offrir un accès au contexte afin d’assurer le support de la sécurité et de l’accès aux données par exemple.

Il montre ensuite l’interaction entre les portlets avec une RemoteCommandPortlet sur une démonstration fonctionnant avec JBoss Portal. Une fenêtre HTML détachée permet d’envoyer des commandes à une autre portlet, la gestion de l’asynchrone est très simple.
A ce propos, il explique que les améliorations du support d’Ajax dans la spécification Portlet 2.0 permettent à des frameworks comme ICEFaces ou RichFaces de fonctionner correctement dans des portlets.

Les Portlets 2.0 peuvent maintenant partager leurs paramètres avec d’autres produits ce qui permet de faire communiquer les portlets entre elles. Thomas Heute montre l’exemple d’une portlet Google Map et d’une portlet Weather qui recoivent toutes les deux en paramètre le code postal d’une ville américaine.

Une portlet peut aussi déclencher une événement, les autres portlets peuvent être notifiées et se mettre à jour. Il conseille de ne s’en servir que pour de la mise à jour de l’interface.

Sur le slide suivant il dresse un état de l’implémentation de la spécification par les différents acteurs du marché :

La JSR-286 Portlet 2.0 est en version finale depuis le 12 juin 2008.
- JBoss Portlet Container 2.0 est sorti le 13 juin 2008 puis inclus dans JBoss Portal 2.7.0 en octobre
- eXo Portlet Container 2.0 est sorti le 18 juin 2008, mis dans eXo Portal le 1er juillet 2008
- Liferay portal a sorti sa version le 17 juillet 2008
- Apache Jetspeed assez tardivement le 27 mai 2009 dernier
- IBM Websphere portal 6.1 a été disponible sept 2008
- Oracle Portal (BEA () + Oracle (2) + Sun(1)) ?

Concernant le support des frameworks WEB il existe 2 spécifications
JSF Support:
– JSR-301 specification addresses JSR-166
– JSR-329 addressing JSR-286 (JBoss Portlet bridge on the way)

De ce qu’il a pu voir sur les forums, les pages :
Wicket support -> mostly there with support for events
Sruts 2 plugin for JSR-286
Spring MVC also support JSR-286
WebWork

A propos de la portabilité : attention la spec ne dit pas comment on fait un portail mais une portlet.
La notion de page n’est pas définie.
La communication entre portlet:
– UI Level
– Le mécanisme événementiel n’est pas un remplacement par JMS, ne pas abuser de ce mécanisme.
– Doit-on se coordonner à travers les pages ?
– Portlets aren’t a template mechanism per se

Rester à une gestion des événements entre portlet qui sont sur la même page si vous ne voulez pas avoir de soucis.

Slide suivant qui m’a fait sourire : Portlet vs Widget vs Gadget (vs Toilet ?)
Thomas Heute explique tout d’abord en quoi consiste un Gadget, tel que l’on peut le voir sur Facebook. C’est un affichage déporté dans un autre site web d’une fonctionnalité hébergée sur un serveur primaire. Une portlet est plutôt la représentation locale d’un service distant, c’est une composition gérée par un portail, afin d’assurer des services communs (authentification, autorisation, communication, etc) dans un seul endroit.

Il cite différentes initiatives autour des Gadgets :
Google OpenSocial, OpenAjax Alliance (OBM, Google, Sun, Red Hat, Oracle, Microsoft) -> Widget proposal

L’avantage des Portlets par rapport à un Gadget/Widget:
-> Fait pour des applications plutôt complexes.
-> Vous pouvez utiliser votre framework en général,
-> L’état des portlets est gardé lorsque la page se rafraichie.
-> propagation de l’identité, de la sécurité, interaction avec un portail, visuel.

Les gadgets ont l’avantage d’être développable rapidement, comme pour consommer par exemple un flux RSS. Facile pour l’intégration du côté client, facile pour partager de l’information. On pense au Gadget Twitter que j’ai sur mon blog par exemple.

Il termine par un slide sur ses idées pour l’avenir
> We could use more annotations a la Servlet 3.0 or JSF 2.0 @Portlet (no portlet,xml)
> We could all benefit from a PORTAL specification
– more aware of the environment, communication with the portal itself
– Portal object management
– Federated search/index

Enfin il revient sur l’annonce du parternariat entre JBoss Portal et eXo Portal. Il résume cela par
« JBoss builds the platform, eXo Platform builds the solution, We are hiring ! »

Réflexions et conclusion
Présentation intéressante, je crois que les Portlets 1.0 ne doivent plus être utilisées. Je travaillerai cet été à l’étude de différents portails pour le client avec lequel je travaille, le sujet est donc d’actualité. Mon souci du moment : comment proposer l’étude d’alternative à la politique d’achat qui voudrait que l’on prenne Oracle Portal, sans savoir si celui-ci correspond à nos besoins ? Mais c’est une autre histoire…

Pour commencer, l »actualité d’eXo Platform a été riche en cette fin d’années. Beaucoup d’actualités, de voyages comme lu sur ton feed twitter (@benjmestrallet). En quelques mots peux-tu me parler de l’entreprise et de tes équipes ?
En effet, 2008 a été une année riche. L’année 2009 sera l’année de la stabilisation. 2008 a été l’année du lancement de beaucoup de produits et nous n’annonçons pas pour l’instant de nouveaux produits pour 2009.
Concernant l’entreprise, en effet nous avons aussi recruté beaucoup de personnes. La société se compose de plusieurs centres de développement : le Viet-nam, l’Ukraine, la Tunisie et la France. eXo Platform représente environ 95 personnes aujourd’hui.
Si tout va bien nous devrions démarrer aussi aux USA avec un bureau là-bas.

A propos du nom « eXo Platform », j’ai entendu plusieurs histoires, mais donc il semble que cela vienne du nom de ton projet de fin d’étude, tout simplement appelé « exo » comme exercice, et que finalement tu aurais gardé. Vrai ou pas vrai ? Légende urbaine ou pas ?
C’est vrai.

Comment l’aventure a commencé ?
Nous avons publié un article sur The Server Side à propos des portails. Cet article a été repéré par un membre du Department of Defense en 2003, l’équivalent de la DGA en France, au moment de la guerre en Irak. De fil en aiguille, en effet notre premier client a été le DoD. J’avoue que la première fois qu’un email avec « @jfcom.mil » arrive dans ta boîte aux lettres, tu n’y crois pas…
Le code source a été placé sur SourceForge, c’était l’implémentation de la JSR 168, basée sur Pico Container, un des premiers frameworks d’inversion de contrôle. Nous avons été contacté afin d’écrire plusieurs articles sur les portails collaboratifs, et c’est de cette façon que notre premier client a démarré l’aventure eXo Platform, courant 2004.

La société a été créé à Vannes ?
En fait j’ai commencé à Paris, en banlieue parisienne.

… dans un garage ? Important le garage !
*rires*, oui le garage en effet.
Nous avons commencé ensuite à Vannes, cela nous a donné la possibilité de démarrer rapidement, entre autre grâce à François Moron, qui est le directeur des opérations aujourd’hui chez eXo.

Comment se passe la répartition des équipes entre les différents centres de R&D ?
Nous sommes répartis par couche technique. L’implémentation de spécification se fait plutôt en Ukraine, le Viet-Nâm se concentrant sur l’intégration et la réalisation des produits. La Tunisie démarre afin d’offrir un support francophone et surtout, le support des écritures right-to-left comme l’arabe, l’hébreu et le persan. Nous souhaitons démarrer très rapidement de nouveaux projets en Afrique du Nord et au Moyen-Orient. Le support des utilisateurs francophones en Tunisie nous permet aussi de renforcer nos équipes et d’offrir un service de qualité à nos clients en Europe.
A propos nous recrutons en Tunisie, et nous cherchons des personnes motivées afin de renforcer nos équipes à Tunis (voir le site http://www.exoplatform.com). Si des personnes sont intéressées, elles peuvent postuler via le site Web d’eXo.

eXo Platform fait partie du JCP (Java Community Process) et vous intervenez sur la JSR 286, Portlet 2.0. Qui est en charge chez eXo de la JSR ?
Au départ c’était moi. A cette occasion j’ai fait la connaissance de Julien Viet. Il était à l’époque chef de projet chez RedHat de JBoss Portal. De fil en aiguille, Julien nous a rejoint et il est en charge aujourd’hui du produit eXo Portal 2.5.

Par exemple, où travaillait Tugdual Grall avant de rejoindre eXo ?
Chez Oracle à San Francisco, pendant une dizaine d’années. Il est aujourd’hui VP of Business and Product Strategy chez nous.

Il y a pas mal de personnes connues de la communauté Java dans les membres d’eXo Platform non ?
Dimitri Baeli, OSSGTP, anciennement chez Prima Solutions nous a rejoint récemment. Il a mis en place Scrum et il travaille sur l’industrialisation de nos produits. Ensuite Brice Revenant dirige eXo Platform SEA (South East Asia). Il est basé au Viet-Nam, il travaillait anciennement chez Bull.
Patrice Lamarque est Product Manager, il est en charge d’eXo Collaboration Suite, notre suite collaborative avec email, agenda, carnet d’adresse.
Il y aura d’autres personnes prochainement…

eXo Platform fait partie du consortium OW2, peux-tu expliquer ce que cela représente et comment vous avez rejoins ce groupe ?
OW2 est au départ une initiative de France Telecom, de Bull et de l’INRIA, visant à promouvoir les projets open-sources. Cependant aujourd’hui c’est un consortium bien plus important, l’Asie et le reste de l’Europe sont fortement représentés. Au départ, l’objectif est de fédérer des projets autour du middleware, plutôt en licence LGPL. Lorsque nous avons commencé à travailler avec OW2, nous avons proposé eXo qui est en double licence : GPL et commerciale. D’autre part nous sommes un socle applicatif. Aujourd’hui les projets regroupés autour d’OW2 sont plus vastes. On retrouve par exemple d’autres projets comme xWiki, initié par Ludovic Dubost ou elastic Grid initié par Jérôme Bernard.

A propos des évolutions à venir d’eXo Platform, j’ai lu que tu parles d’un mode hébergé (Saas) et d’un mode déconnecté. Qu’en est-il aujourd’hui ?
Oui à propos du mode hébergé, nous sommes utilisateurs d’Amazon S3 et EC2. Pour l’instant nous n’avons pas encore finalisé de produits. Notre idée est de proposer ce que l’on appelle « Paas » : Platform as a Service. Nous travaillons aujourd’hui avec des intégrateurs qui réalisent des projets chez des grands comptes. Notre souhait est d’offrir directement aux PME une solution locative et donc d’héberger leurs applications sur notre plate-forme. Ainsi, chacun se concentre sur son coeur de métier et ne prend pas en charge la gestion d’un data center par exemple.

Sur ce modèle, SalesForce.com propose ce service, nous souhaitons aussi travailler dans ce sens. C’est un mouvement fort pour les années à venir.

A la base notre offre vise à simplifier chez les grands comptes l’usage des familles de produits sur lesquels nous nous sommes positionnés. Là où il y a un IBM Websphere Portal, notre offre est plus compétitive. Nous avons fait un gros travail pour supprimer la segmentation du marché (Websphere Portal, FileNet, Lotus…) et d’offrir un socle commun plus puissant.

Amazon SimpleDB, S3, EC2, le Cloud computing sont des sujets sur lesquels nous travaillons. Faire fonctionne une application J2EE en cluster demande un travail très intéressant. Il n’y a pas de multi-cast dans le cloud computing. Ce sont vraiment des sujets intéressants.

Je me souviens que lors de la précédente crise dans les années 2000, Linux a littéralement explosé. Face aux réductions de budgets, les DSI ont propulsé Linux. Surtout sur les marchés publics. Que penses-tu par rapport à cette crise ?
On sent un mouvement global, la crise va-t-elle privilégier l’open-source ? et d’autre part, est-ce que les choix techniques que nous avons fait sont les meilleurs ?
Sur la première question, ce qui est intéressant c’est que les gens se posent plus rapidement la question de « est-ce que c’est moins cher ? ». C’est la première question. Ce n’est pas gratuit car c’est open-source, ce que les décideurs ont intégré. Alors quel est le prix ?
On a vu que les couches basses ont percé dans le monde de l’open-source ces dernières années. Tout le monde est d’accord pour s’en servir. Je pense que l’on va remonter de ces couches basses vers les plate-formes d’hébergement comme la nôtre, qui proposent des services à valeur ajoutée, comme Alfresco ou Liferay. Le pipe en ce moment est plus important, nous voyons que la crise provoque en ce moment un mouvement.
Finalement en situation de danger, les décisions sont plus radicales, et nous sommes mieux positionné.

Entre la France et l’export, comment est réparti l’activité ? le chiffre d’affaire ? as-tu des repères à nous donner ?
35% du CA génère en 2008 s’est fait à l’export. En 2007 c’était 50/50. Notre chiffre d’affaire en 2008 a presque quadruplé en un an.

Quelles sont vos sources de revenu ?
C’est de la souscription, et un pourcentage sur le support. Nous avons aussi des experts et des prestations de service. Finalement surtout de la formation, et des développements noyaux. Nos clients sont sponsors.

Quel est votre concurrent numéro 1 ? si nous étions dans la rue, est-ce que ce serait une petite épicerie ? un supermarché ? quel est sa taille par rapport à eXo ?
Cela dépend du marché, de la partie dans le monde dont nous parlons. Sur les appels pour marché public nous voyons souvent en concurrence des solutions proposées autour de Liferay, Alfresco, parfois du Jahia. Sinon aussi IBM Websphere Portal et Oracle Portal.
Nous voyons beaucoup de projets proposés sur Microsoft Office Sharepoint Server, surtout en Afrique du Nord.

J’ai vu dans la Finance aux USA que les solutions basées sur Microsoft avaient le vent en poupe, car ce sont des solutions qui partent d’une interface agréable, là où les solutions Java remontent des serveurs d’application vers l’interface utilisateur. JavaFX vient juste de sortir… On parlait RIA, GWT, Flex l’an passé comme d’une révolution… Pour revenir à eXo Platform. WebOS montre peut-être une piste pour le futur.
Finalement, tu ne penses pas que Google sera ton plus gros compétiteur demain ?
Non nous ne sommes pas sur la même segmentation. Google est un partenaire avec lequel nous travaillons. Ils ont lancé le modèle « Gadget » et « OpenSocial » qui fédère beaucoup de sites (LinkedIn, MySpaces.com…). On a aussi un engouement justifié sur le développeur chez Google. Ils sont aussi fort en proposant des solutions qui ne sont pas uniquement basées sur Java mais sur Python, javascript, Groovy ou autre…
Google Gadget est une solution agnostique de la partie serveur. Du côté du client, du html, du javascript. Et tu peux alors mettre ce que tu veux du côté du serveur, ce qui est vraiment intéressant car les perspectives sont plus larges.
eXo Platform supporte l’intégration des Googles Gadgets, ce qui nous ouvre aujourd’hui plus de 1000 composants que chacun peut placer sur son portail.
On retrouve un mode client-serveur, le client communique avec le serveur avec du JSON.

J’ai fait le tour de l’Asie avec Google en novembre dernier. Lors des conférences, une page pas très belle présentée par Google : résultat,, 500 personnes dans la salle. Tu passes derrière et tu proposes une présentation très sympa ? 100 personnes ! C’est l’effet Google ! Le traiteur le Nôtre pour eXo : 100 personnes. Des bières et des chips chez Google : 500 personnes… C’est Google *rires*

Pourtant tout ne marche pas si bien. Google Chrome est utilisé autant que Safari d’après des chiffres vus sur le site du NewYork Times je crois
Les gens qui utilisent un Mac utilisent Safari, il marche bien. Les iPhones, cela fait aussi un grand nombre de navigateur « Safari ». Sur Google Android je crois que c’est Web Toolkit. Apple a vendu 17 millions d’iPhone… C’est énorme.

A propos donc de téléphone mobile, avez-vous des projets ou des prototypes ?
Il y a 3 usages différents : deux qui sont classiques, naviguer sur internet pour le premier, et faire de la synchronisation pour le deuxième. On étudie SyncML pour voir comment nous pourrions proposer la synchro entre notre suite collaborative et ton PDA. Le 3ème usage auquel nous pensons, c’est de proposer un « Application Store » pour proposer des gadgets et des outils.
Le WebOS de Palm est très puissant et pourrait afficher le contenu de notre plate-forme.
Goojet (http://www.goojet.com/index.html) est une société Toulousaine qui propose par exemple un système de gadgets et d’application mais pour téléphone portable.

Présenter le portail ou le WebOS sur un petit écran, je ne sais pas. Par contre je pense que présenter une partie des gadgets de nos portails, cela serait possible…

Sur un autre sujet, tu as annoncé l’ouverture d’une filiale en Tunisie. Où en sommes-nous ?
Le marché de l’Afrique du Nord se développe à vitesse grand V. Nous avons la chance de parler français, nous sommes proches géographiqmenent. J’ai contacté un ami rencontré pendant mes études, Oualid Chaker. Ensemble nous avons monté ce projet et débuté fin juillet une activité de commercialisation et de support basée à Tunis, en charge des contacts avec les pays d’Afrique et du Moyen-Orient.

Peux-tu présenter les produits et le socle technique d’eXo Platform ?
Le plus simple pour présenter cette partie est de faire un petit schéma.

Au niveau du socle technique :
1) eXo Portlet Container est une implémentation des JSR 168 et JSR 286 (Portlet 2.0). Ce module gère le cycle de vie et les instances des composants de portlet. L’implémentation a été optimisée et fournit également des capacités de monitoring qui sont indispensables dans un environnement de production.
2) les WebServices sont supportés avec une implémentation de la spécification JSR 311(JAX-RS) l’API pour les webservices de type REST. JSR 181 est une JSR pour les WebServices Metadata, qui te permet d’exposer via des annotations des web services type WSDL
3) eXo Java Content Repository. Il s’agit d’une implémentation de la JSR 170 et JSR 283 qui vise à rendre abstrait et à normaliser le stockage des données. Les dépôts de données sont composés d’espaces de travail qui peuvent contenir du contenu dans une structure hiérarchique. Notre implémentation fournit des services pour gérer les versions, le verrouillage, la sécurité (LDAP), et les recherches. L’implémentation eXo permet également des connections optimisées avec toutes les bases de données telles que Oracle, DB2, MySQL…

On a donc 3 points à retenir. Exo Platform offre :
- la portabilite des applications avec portlet
- la portabilité des données avec le JCR
- la portabilité de la logique métier avec JAX-RS et WS Metadata.

Wow…..
Le point essentiel est ensuite qu’on ajoute ensuite la notion de « Gadget serveur » à la Google. On peut soit les exposer pour nous, soit vers l’extérieur. On a là le socle portail d’eXo Platform. Nous stockons les préférences et les pages dans le JCR. Et on pense maintenant proposer un IDE pour que tu puisses développer en Groovy des applications hébergées dans la plate-forme…

… wow… wow….. et ensuite ?
On a ensuite travaillé sur la représentation et l’interface utilisateur. Tu as d’une part la vue classique, orienté Web avec le portail. Mais nous avons aussi la vue type « WebOS » qui t’offre un bureau avec ses applications, le tout déployé sur le même serveur.

… ah… wow…
Nos produits phares sont donc développés avec notre socle.
– eXo ECM 2.2 (Enterprise Content Managment) est notre offre de gestion de document avancée. (voir sur le site pour plus de détails)
- eXo WCM 1.0 (Web Content Managment) est un produit très intéressant de gestion de sites Internet. Il permet aux collaborateurs d’une entreprise d’avoir une vue synthétique pour gérer le contenu et les mises en ligne de sites Internet.
- eXo CS 1.0 (Collaboration Suite) est un portail d’entreprise : agenda, courrier électronique, carnet d’adresse… nous proposons de regrouper dans un navigateur les informations de l’entreprise afin d’offrir un socle de collaboration et de partage très puissant

Il manque enfin le module transverse : une implémentation d’open-social, qui nous permet d’offrir une intégration avec les applications Web 2.0. Il sera possible d’exposer par exemple ton réseau d’ami…

Selon les personnes avec lesquels on discute, nous présentons eXo Platform d’une manière ou d’une autre.
En tant que technicien, tu as vu le socle technique, mais aussi notre chemin d’intégration, ce qui nous permet de travailler ensuite avec les clients et de réaliser des produits finis.

En tant que développeur, comment puis-je ensuite travailler avec vous afin de développer une solution sur votre socle ?
La notion de plate-forme te permet de rajouter tes propres composants. Tu as aussi un éditeur de gadget en ligne, ce qui ouvre le système et permet à chacun de contribuer à la plate-forme.

Mais est-ce suffisant pour développer une application ?
La partie serveur sera exposée avec REST, tu retrouves ton modèle classique, avec une application Java et celle-ci discutera via JSON par exemple, avec le gadget.

Les visiteurs sont aujourd’hui souvent sur des sites comme Facebook, MySpaces.com. Comment les faire venir ?
Justement, tu utiliseras la plate-forme d’hébergement eXo, tu pourras aussi gérer finement le cycle de vie de ton gadget, nous offrirons un service qui n’existe pas encore… Tes visiteurs seront sur leur page iGoogle avec une application exposée via OpenSocial par eXo Platform. Tu pourras donc par exemple accéder au gadget hébergé sur la plate-forme eXo….
Nous offrons une version un peu plus entreprise pour gérer ce cycle de vie. C’est adapté aux entreprises qui cherchent à ouvrir leurs services.
600 millions de personnes sur OpenSocial, 180 millions chez Facebook…

Pour revenir à l’offre hébergée, je te présente du code normalisé pour qu’il fonctionne sur la plate-forme. Est-ce que je peux venir louer une partie de ta plate-forme ?
Pour tout ce qui est gadget, je pense que nous offrirons un point d’entrée et que tu pourras proposer tes gadgets. Les portlets par contre, sont du côté de ce que nos clients hébergent avec nos produits, et les utilisateurs de nos clients pourraient ajouter des gadgets afin d’ajouter de nouveaux services sur leur application.

Qu’en est-il du Java content repository ?
Du côté du JCR nous avons aussi des chemins encore à explorer. Aujourd’hui nous stockons les données soit dans une base relationnelle, soit sur le disque lorsque celles-ci sont trop grandes. Nous travaillons afin de remplacer cette base relationnelle par la solution type Amazon SimpleDB. Cependant faire travailler ce type d’application dans un Cloud demande un travail assez important. Passionnant mais cela demande du travail.
La version 1.11 du JCR devrait proposer en beta ces fonctionnalités.

Donc à terme, Amazon EC2 pour la partie JVM, et Amazon DB à la place de clusters de MySQL. Nous serons alors prêt à segmenter pour que chaque société puisse alors utiliser une partie de nos produits.

Cela à l’objectif des deux années à venir.

Il faut avoir aussi les investissements et les moyens. Par les temps qui courent, ne crains-tu pas que cela soit plus difficile ?
eXo Platform s’autofinance par son revenu, ce qui nous donne une liberté et donc une réactivité. Nos produits sont matures et sont sur les rails. Nos axes de dépense seront plutôt les efforts commerciaux, le travail que nous réalisons en ce moment pour aller à la rencontre de nos clients.
Nous travaillons pour offrir une plate-forme de services et donc proposer à chaque client la même offre de support. Notre offre “Enterprise” répond à la gestion de versions, au cycle de vie de nos produits.

Dimitri m’a parlé aussi des méthodes de développement et de vos outils. Sans trop en dévoiler, vous êtes vraiment bien outillé et industrialisé. J’ai eu le sentiment en effet que les projets sont sur les rails, que les équipes produisent et travaillent avec une synergie dont on rêve parfois. Il manque encore des produits ?
Nous sommes open-source. Dès le départ nous avons eu besoin d’outils comme des wikis, les outils d’Atlassian, la gestion des bugs. Nous travaillons sur les outils de tests d’intégration, comme Selenium par exemple. Cependant, comme nous étions dès le départ open-source, les efforts sont logiques.

Cela me fait aussi penser qu’il y a vraiment un potentiel pour, par exemple, proposer une plate-forme d’hébergement à des développeurs. J’imagine en effet que nous pourrions proposer d’héberger des projets, de les compiler, de les versionner…

Collabnet le fait déjà. Chez Reuters c’est la solution retenue pour les 3200 développeurs dans le monde. Il faudrait offrir un service SVN non ?

En fait nous avons travaillé avec le repository maven2 “Archiva”. SVN fonctionne par dessus le protocole http, et notre JCR peut s’exposer avec des modules WebDAV. Il sera donc possible de le faire je pense.

J’imagine mettre dans le JCR le code source d’une part, et les artifacts compilés d’autre part. A la fois un repo SVN et un repo Maven2 par exemple. On peut alors utiliser qu’un seul serveur au lieu de deux !

…et je vais abonder dans ton sens, car aujourd’hui il est difficile de demander à des équipes MiddleWare d’héberger et de maintenir le repository SVN et le proxy Maven2. Cela pose des soucis de budget !

Ce n’est pas pour l’instant notre but, mais je pense que ce serait un produit que j’utiliserai.
A réfléchir. Pour que cela soit intéressant il faut que l’automatisation soit poussée.

Pour boucler avec les questions du début, quels sont les clients en France qui utilisent eXo Platform ?
Je ne vais pas les citer tous, mais par exemple nous travaillons avec M6. Le dernier résultat dont je suis très fier c’est le support du texte “right-to-left” pour l’arabe, l’hébreu et le persan. C’est l’un des travaux de Julien Viet depuis qu’il nous a rejoint.

Pour terminer sur une note plus légère, quel usage de Twitter fais-tu ?
Deux choses : où je suis, car je voyage pas mal. Et ce que je bois
Julien Viet est un spécialiste des sushis par exemple. Twitter c’est un moyen déconnecté de rester informé de ce que chacun fait.
J’utilisais plus twitter lorsqu’il y avait la notification par SMS. Je dois passer par le web.
Cependant en Asie je me souviens que lorsque nous twittions sur #devfest en Asie, nous
avons eu des journées énormes avec beaucoup de messages échangés. Twitter est déroutant.

Le mot de la fin ?
J’invite tout le monde à venir tester eXo, des articles sur internet vous donne un guide complet pour commencer rapidement à créer vos applications. eXo Platform peut très bien faire fonctionner par exemple une application en Flex, hébergée sous la forme d’une Portlet 2.0. A part un premier souci de z-index, nous n’avons pas eu de soucis. Il est possible de faire fonctionner des technologies comme GWT ou Flex avec eXo.

Merci Benjamin !
Merci Nicolas !