JUG Montpellier : Retour sur la session GAE


Trois mois depuis la dernière session, hier soir était finalement la reprise des soirées du JUG Montpellier pour la saison 2011/2012. L’année commence gentiment mais surement avec une soirée complètement dédiée à Google App Engine – GAE.

Martin Delemotte, CTO chez Kazelys (et accessoirement membre fondateur du JUG Montpellier), société qui édite Vadequa, est venu parler de sa grosse expérience avec GAE devant 80 personnes (oui ça grossit petit à petit!). Présentation des principaux services, contraintes fortes de la plateforme, astuces et conseils étaient au menu de cette soirée pleine d’échange avec le public intéressé. Les questions fusent, les réponses sont claires, parfois simples (ou pas) : « Ca, ça ne va pas être possible…, mais nous allons voir comment faire autrement ».

Il est clair que la majorité des personnes ont été refroidies par les contraintes de la plateforme, mais il est évident que ces contraintes qui sont introduites par le maitre du monde – Google de sont petit nom, sont bénéfiques intellectuellement parlant pour le développeur en question. Il est aussi clair qu’il faut bien réfléchir avant de se lancer dans le développement d’une solution reposant sur GAE. Le simple test bidon que tout le monde a pu faire depuis que GAE est là n’est bien sûr pas suffisant pour se donner un avis sur la plateforme. Sortir de GAE n’est aussi pas si simple, pour peu que l’on ai pas bien désigné son application (oui il faut wrapper, ne pas être dépendant directement des APIs, ne pas utiliser de service spécifique que seul Google fournit, …). Bref, que des points techniquement et intellectuellement intéressants.

Chaque seconde, une machine meurt dans le Cloud

Martin Delemotte – 28 sept 2011

Les slides de la session seront bientôt disponibles sur le site, en attendant quelques photos pas trop floues…

Prochaine soirée dans deux mois sur HTML5, CSS3 et UX. Le mois prochain, on laisse la place à l’Agile Tour…

Retour sur la Session Android du JUG Montpellier


Hier soir avait lieu la deuxième soirée du Montpellier JUG entièrement consacrée à la plateforme Android. L’occasion pour Eric Taix, Responsable R&D chez ESII Media Accueil mais aussi principal développeur de Synodroid, de faire une présentation de la plateforme mais aussi de donner son retour d’expérience par rapport à son vécu professionnel et open source. Les Montpelliérains étaient au rendez-vous avec une cinquantaine de personnes qui avaient vivement prononcé leur intérêt via Twitter, FrAndroid et autres sites dédiés…

En attendant les slides que tout le monde attend avec impatience, quelques photos de la soirée.

Mise à jour : Les slides de la soirée sont disponibles!

On notera encore une fois une troisième mi-temps riche de retours, de contacts et d’échanges. Merci encore pour les quelques retours des participants via Twitter ou le Google Group.

 

JUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : Android
JUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : Android
JUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : Android
JUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : AndroidJUG Session #2 : Android

JUG Montpellier Session 2 : Android, un album sur Flickr.

Petals ESB over XMPP #2


Dans l’article précédent, je parlais de l’utilisation de XMPP et de Google Talk pour faire communiquer des instances de Petals ESB. L’utilisation était seulement faite au niveau de la couche de transport de Petals (cf cet article sur la couche de transport) et ne couvrait donc pas tous les canaux de communication qui entrent en jeu (et en particulier ceux du registre de services).
Dans la continuité de mes travaux sur la fédération de bus de service, je me suis donc intéressé à la possibilité de faire communiquer des domaines distincts (un domaine étant un ensemble de noeuds au sein d’une institution par exemple) en utilisant XMPP non pas seulement pour la couche de transport mais aussi pour les communications du registre de service.

En pratique, les domaines sont complètement indépendants, ils ne sont aucunement connectés via Internet ou toute autre connection alternative. Dans cette première itération sur la fédération, il n’y a pas de notion de hierarchie en domaine et sous domaine. Un noeud d’un domaine peut demander à la fédération une résolution de endpoint et aussi envoyer un message à des endpoints de la fédération pour invoquer des services. Une vue de haut niveau sur deux noeuds dans deux domaines différents est la suivante :

Techniquement, l’intégration de la fédération intervient à plusieurs niveaux :

  1. Chaque noeud implémente le service de fédération qui permet de donner un point d’entrée à la fédération. Ce service expose une opération de recherche de endpoint et une opération d’invocation de service.
  2. Chaque noeud s’enregistre dans la fédération en donnant un callback (ici c’est le point d’accès au service exposé en 1 qui est publié dans la fédération).
  3. Un module de fédération permet de faire une recherche de endpoint dans la fédération. Dans le cas de Petals, c’est un module du routeur (cf cet article sur les modules) qui permet de faire cette recherche.
  4. Une implémentation au niveau fédération de la couche de transport permet d’aller invoquer un service de la fédération.

Une première approche simple (et pas forcément efficace) est de laisser le module de routage faire une requête à la fédération à chaque invocation pour trouver une liste de endpoints qui peut répondre à la requête, une version plus évoluée permettrait d’avoir un cache à un niveau intermédiaire (pas si évident en fait dans une approche très dynamique). A voir…

En attendant, un premier prototype permets de faire communiquer des noeuds appartenant à des domaines différents sans que ceux ci est une connaissance des autres noeuds (au niveau de Petals ESB, les noeuds des domaines ne sont pas renseignés au niveau du service de topologie). La vidéo qui suit montre deux noeuds, un sur mon laptop et un autre sur un serveur OVH. Je n’ai ouvert aucun port sur ma Box, sur mon laptop ou sur le serveur pour faire passer du trafic supplémentaire : C’est un des avantages à utiliser XMPP.
Le scénario est simple, un client sur mon laptop veut invoquer un service qui fournit une interface X. Cette interface X n’est fournie par aucun service localement (d’ailleurs on voit bien qu’il n’y a pas de endpoint sur le container coté client). Et la magie, il existe un endpoint dans la fédération qui fournit cette interface et il se trouve que cet endpoint est sur le container tournant sur le serveur OVH.
Et alors? Ca a l’air bête comme çà mais on arrive quand même à récupérer la référence du endpoint distant et à invoquer le service sans avoir besoin d’ouvrir quoi que ce soit, de faire du polling ou autre. Merci XMPP.
Comment? Pour dire simple, chaque noeud se connecte sur un serveur XMPP. En pratique c’est un peu plus compliqué et je laisse ca pour un prochain article!

Communication de noeuds Petals via XMPP


Dans le cadre de mes travaux de recherche sur la fédération de Bus de Service (et en particulier de Petals ESB dans un premier temps), je suis en train d’étudier la fédération via Jabber/XMPP. L’approche la plus rapide sans avoir l’utilité de monter un serveur Jabber est d’utiliser GoogleTalk comme support et ainsi profiter aussi de l’infrastructure de Google et de sa robustesse.

Les premiers tests n’ont rien a voir avec la fédération mais valident que l’on peut utiliser une couche de transport générique que j’ai développé (et que je détaillerais dans un futur article) pour rapidement implémenter un transport utilisant le protocole désiré, ici XMPP. Le schéma suivant donne une vision de haut niveau de cette architecture et du cas d’usage :

Description du scénario ci dessus:

  • Chaque noeud est connecté à GTalk avec un compte dédié
  • Un service est lié à Petals ESB, disons que c’est un Web service bindé avec le composant SOAP (Proxy Out)
  • L’endpoint ainsi présent dans Petals ESB est exposé sous forme de Web service par le composant SOAP sur l’autre container (Proxy In)
  • Tout client envoyant une requête au service via le Proxy In voit sa requête traverser les différentes couches de Petals jusqu’à arriver à la couche de transport. La communication avec le container cible se fait grâce à la notion de Chat de Jabber. Un Chat est créé entre le container 1 et le container 2 et le message contenant la requête est alors publié au container 2 via le Chat.
  • Le container 2 reçoit le message et le fait remonter jusqu’au service final. La réponse prends le chemin inverse.

On profite aussi de l’archivage des communications Gtalk :

Evidemment, passer par GTalk pour invoquer des services d’un même domaine est pénalisant et l’intérêt est assez limitée car la communication entre les noeuds ne se fait pas uniquement via la couche de transport (la recherche de endpoints passe par un canal différent par exemple). Et c’est la que la fédération du Bus va entrer en jeu. La suite donc au prochain numéro.

Just testing the Google App Engine Java Version


Just tested the Google App Engine Java version and its Eclipse plugin, really amazing. The sample application is deployed from Eclipse and is running at http://hamerlingchristophe.appspot.com/

I think that I will try to do some things related to SOA and PEtALS on this platform, just need time…