Kids are sick? Take coffee and code


I had some time since several nights (thanks kids to be sick…) to start watching how to implement a REST API using node.js (my new friend).

I plan to create an OW2 API this year; but before I started to wrap some existing services as proof of concept. The first feature focuses on how to get projects data from the gitorious instance we run at OW2. There is no clear API for gitorious but after some googling and source code search, it looks that there is a read-only XML API. Since I am targeting node.js, let’s translate this API into a JSON one: xml2js will do the job.

This results in a first library (gitoriou.js) which just call the gitorious instance and translates the XML data into JSON without any other data mapping. The following gist is showing how to get information from a project:

I talked about having a REST API, let’s use express.js for that and let’s run it on Heroku (this platform rules, just took 2 minutes to create, deploy and run the service and it is up at http://ow2apisample.herokuapp.com/).

To get information (as JSON) about the Jasmine project, just HTTP GET http://ow2apisample.herokuapp.com/project/ow2-jasmine

If you master any scripting language, you will be able to get all the repositories URLs from the JSON response, if not you can use the ow2git project to clone them all. Assuming node.js and npm are available on your system (you already have java, ruby and every other stuff installed, why not adding node?), you can install the binary:

npm install -g ow2git

and then clone all the repositories from any gitorious project

ow2git –clone ow2-jasmine

Will clone all the ow2-jasmine repositories into your current folder.

I am really impressed by node.js runtime, tools and community. Even if all of this is just a proof of concept, not really well designed, you can have something running quickly without many effort. Time to get something real. Soon…

Bye Bye SOAP, salut REST?!


En tout cas cela est vrai pour les API exposées sur le Web, je ne suis pas vraiment sûr que ce soit le cas en entreprise… Bref, je pense que j’avais déjà parlé de ce déclin il y a quelque temps mais je vais en reparler tout de même un petit peu.

Toujours est il que les faits sont là. Les moteurs ont beau crawler le Web à la recherche de services Web (les vrais avec un WSDL!), ils depuis un certain temps dans une phase stagnante. Pour preuve, le nombre de services trouvés par le moteur Seekda est aussi plat que la pleine Toulousaine, on devine un peu plus de 25000 Web services publics trouvés et ce chiffre est le même depuis presque 3 ans:

Source : Seekda.com

Source : Seekda.com

Il y a bien de nouveaux services découverts de temps en temps, mais bon, il me semble que c’est plus de l’ordre du prototype ou du test que d’autre chose, la preuve en image:

Oh la belle calculette...

Oh la belle calculette...

Bref, le déclin est annoncé. Pour preuve, on peut aussi regarder l’intérêt que portent les utilisateurs aux APIs SOAP et REST par le biais des tendances de recherche Google (via http://www.google.com/insights/search/#q=soap%20api%2Crest%20api&cmpt=q). Bien sûr l’internaute ne dicte pas la mort de SOAP et la percée de REST, mais il est clair que ce qui est ‘trendy’ de nos jours est bien REST :

SOAP vs REST

SOAP vs REST

Et vous dans la vrai vie, vous êtes plutôt SOAP ou REST?

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!