Playing in Brussels


Last week was the first annual review meeting of the Play project I work on since one year. I am involved at several levels in this project: from the architecture point of view, to the software integration and quality ones. On my side, my goal is to provide the efficient software infrastructure for events actors, or how to build an Event Driven Architecture based on Petals Distributed Service Bus. There are others points which have to be developed, especially all the platform governance stuff and Service Level Agreement for events, what we call Event Level Agreement.

We showed several things to the European Commission reviewers and we were also able to show an early prototype (this one was originally planned to be show at mid project ie in 6 months…). I made a video capture of the demo, which really needs to be explained…

  • There is the idea of a market place for events : The event marketplace. From there users are able to subscribe to things they are interested in. For now it is just a simple Web application which subscribe on behalf of the user to events through topics. This subscription is sent to the Play paltform using Web standards. Here we use OASIS Web service Notification to create this communication link.
  • Events are collected from several sources by events adapters. In the video above, we can see the user setting this FB status which is collected by the Play system and transformed into a notification which is published to the platform. There are also some Twitter adapters and Pachube ones which collects data in real time and publish them to the platform. This time again, we use Web standards for adapters communication.
  • Now, what happens in the video? The user logs in to event marketplace and subscribes to FB events. The user then publishes something to its FB wall (note that it is not mandatory to have the same user in the event marketplace and in FB. A user can subscribe to FB events and receive events from all the FB statuses collected from the FB application users). After the event propagation delay, the event marketplace display the event to the user.

So do we need such machinery to do things like that? No, if you want to do some other simple mashup portal. There are several components which are under active development: Storage and processing. Yes we store all events in the Play platform. This storage will be huge, but it is one of the project goal: Providing efficient and elastic storage in some P2P way. The need for this storage comes with the other important aspect of the project: Complex Event Processing. We will soon be able to create complex rules on top of events and be able to generate notifications based on past and real time notifications because we have efficient storage and real time stuff inside the platform. I am not an expert of this domain, so I can not give more details about that point but capabilities are huge! For example, we can express something like « Hey Play, can you send me a SMS me when there is my favorite punk rock band playing just around and I am not on a business trip and X and !Y or Z ». All of this intelligence coming from the processing of various sources I push since months in the platform coming from Twitter, FB, last.fm and other data providers.

Now let’s take some time to work on my OW2Con talk. The session name is pretty cool : Open Cloud Summit Session.

Europe-Trotteur, Play, SOA4All et co.


Les deux dernières semaines ont été bien remplies, en passant par Athènes pour une réunion de travail sur le projet Play puis par Bruxelles pour la revue finale du projet SOA4All (après un détour par Montpellier pour coder un peu), il est temps de faire un bilan de tout cela…

Athènes - Mai 2011

Athènes - Mai 2011

SOA4All

Toute personne déjà venue sur ce blog devrait connaitre un minimum ce projet qui m’a occupé ces trois dernières années. C’est bon je ne devrais plus en parler trop puisque il est maintenant officiellement terminé depuis la fin du mois dernier. La revue finale s’est déroulée aujourd’hui à Bruxelles. Pas de présentation technique pour cette fois, j’ai même pas eu besoin de dire un mot… La session du matin était assez spéciale pour un projet recherche: essayer de vendre le projet a un investisseur (avec un vrai investisseur, mais qui venait sans son chéquier). Bref un jeu de rôle que je trouve un peu grotesque et qui au final n’a rien donné a part trop de travail pour les speakers.

Regardons ce que ce projet a pu m’apporter, apporter à PetalsLink et aux produits associés, les points forts, les points faibles, etc, (en essayant de faire court):

  • + Mon premier projet de recherche européen. Je suis entré dedans dès le début après avoir passé 2 ans a bosser sur Petals ESB à temps plein en tant que développeur, product leader et compagnie. J’avais par le passé travaillé sur un projet ANR pendant presque 3 ans aussi sur le thème du grid computing (cf http://grid-tlse.org).
  • + Petals ESB n’avait jamais été trituré de la sorte (ndlr: faut que je trouve un autre mot que trituré, je l’ai déjà utilisé hier plusieurs fois). La version utilisée dans SOA4All diffère énormément de la version communautaire OW2. En plus de l’ajout de nombreux services, il a été aussi customisé dans tout les sens pour qu’il soit non plus ‘Enterprise Service Bus’ mais ‘Internet Service Bus’. Les protocoles et contraintes de la version entreprise n’étant pas forcément les mêmes que ceux d’Internet.
  • + Le Distributed Service Bus qui en découle est maintenant une base pour de nombreux projets de recherche chez PetalsLink, donc on en entendra encore parler sur ce blog.
  • Les partenaires du projet avaient une toute autre vision de ce qu’est un middleware, dès la première réunion on a entendu plusieurs fois ‘The middleware is the Internet’. Donc là forcément çà commence pas trop bien.
  • + Heureusement, l’INRIA était là. J’avais déjà eu le plaisir de travailler avec l’INRIA Lyon sur Grid-TLSE, et généralement ces personnes là savent de quoi elles parlent et savent ce qu’est un middleware. On travaille d’ailleurs ensemble sur de nouveaux projets dont Play.
  • SOA pour tous‘ mais pas pour le projet lui même… Le but du DSB était aussi de fournir cette brique SOA de base. On se retrouve avec des développeurs qui font tous leurs Webapps dans leur coin et qui s’intégrent ‘à la mano’. Dommage il faut recompiler tout si le service est déployé ailleurs…J’ai presque honte de dire la taille de l’installer graphique que j’ai été chargé de faire pour installer les différents modules; allez 800Mo et encore tout les modules ne sont pas présents.
  • + C’est fini, maintenant on va pouvoir faire des vrais projets midleware, SOA et compagnie.

Play

Le projet Play a commencé depuis un peu plus de six mois (je ne parle toujours pas de Play! Framework mais vous devriez vous intéresser à ce Framework Web, le premier tuto est assez bluffant quand on a l’habitude de faire du Spring, du Struts, du GWT ou tout autre Framework Web, Play! est en train de percer et de botter le cul aux autres). Bien que le projet soit encore au début (durée 36 mois), l’activité est assez intense et promet de bonnes choses dans un futur proche. Pour faire rapide, il est question de développer une plateforme événementielle qui utilisera des technos issues/basées sur le Distributed Service Bus, de Complex Event Processing, de P2P, d’adaptation contextuelle, le Cloud, etc, etc, etc… Bref, beaucoup de choses à faire et un Bus de Service, qui va évoluer encore et encore. Ah et on parle aussi de gouvernance au niveau service et évènements, ce qui est un peu plus nouveau pour la partie évènementielle.
Donc la réunion de la semaine dernière à Athènes (ça change de Bruxelles…) a encore une fois tenue ses promesses: du contenu en masse, des cas d’usage qui évoluent pour utiliser au mieux la plateforme et le concept d’Event Marketplace qui se précise. Je pense que je parlerais mieux de tout ça d’ici peu de temps mais les bases sont posées.

Codons!

Ces voyages au sud et au nord de l’Europe m’ont laissé le temps de coder (surtout quand le TGV tombe en panne entre Montpellier et Bruxelles), un article sur une nouvelle feature du DSB a vu le jour hier soir, j’en ferais un autre plus précis dans les jours qui viennent.

Play Project Kick Off


C’est l’époque à laquelle les feuilles tombent, mais c’est aussi celle où les nouveaux projets commencent… La semaine se tenait la réunion de démarrage du projet de recherche Play à Karlsruhe – Allemagne. Suite naturelle pour moi du projet SOA4All qui se termine dans les prochains mois, le projet Play (qui n’a aucun lien avec le Framework Web Play, très bon soit dit en passant) va permettre de mettre continuer mes travaux sur la fédération des architectures SOA, du Cloud et de plancher sérieusement sur les architectures événementielles.

Un scénario de présentation de la plate forme du projet est le suivant :

Paul is a businessman who has been flying from Paris to New York. He used the entertainment service on board, but hasn’t finished watching the movie before the landing. Two hours later he is entering his room in the downtown hotel he booked earlier and wow: the room entertainment service is ready to PLAY the movie Paul was watching in the plane – of course only the unfinished part.

Vu comme ça, rien (ou presque) de révolutionnaire en soit. Quoi que, en y réfléchissant bien et en pensant à la plate forme qui pourrait supporter de telles choses, on peut se demander comment on peut effectivement savoir que Paul va pouvoir regarder son film depuis sa chambre d’hôtel alors qu’il était en train de le regarder dans l’avion 2 heures plus tôt? Est ce que l’on peut alors parler de SOA, de cloud, de fédération, de gouvernance, d’adaptation, d’EDA, de CEP, …? Oui! Bref, l’architecture àvenir sera probablement certainement détaillée ici dans quelques temps, le temps de mettre tout dans le bon ordre… Il sera tout de même déjà question de mettre en place et d’étendre les produits que nous développons, que ce soit Petals ESB ou Petals Master pour ne citer qu’eux.

The PLAY project will develop and validate an elastic and reliable architecture for dynamic and complex, event-driven interaction in large highly distributed and heterogeneous service systems. Such an architecture will enable ubiquitous exchange of information between heterogeneous services, providing the possibilities to adapt and personalize their execution, resulting in the so-called situational-driven process adaptivity.

Bref, un beau projet qui commence pour moi, avec des partenaires experts dans leur domaine et beaucoup de choses à apprendre… Pour le moment je me demande si la prochaine réunion se tiendra encore dans un pays Bierophone (après la Belgique et l’Allemagne ces deux dernières semaines, question légitime) et par contre je ne doute pas que les discussions seront toujours aussi intéressantes, que ce soit chacun derrière son ordinateur ou autour d’une bonne table.