Testing Play! and WebSockets


I spent one hour playing with the [Play Framework](http://playframework.org) and WebSockets in order to push some (SOAP) messages received on some Web services hosted by the Play application to the clients browser.

The result is really amazing: We can simply push these SOAP messages to clients in less than 100 lines of code. There are some problems with some messages lost due to some conception problems but which are not Play ones. In fact, the current prototype just send the messages to all the clients but what should be done is creating streams per client with some ID to identify them…

The source code is available on GitHub at [https://github.com/chamerling/play-soap-websockets](https://github.com/chamerling/play-soap-websockets)

A quick screen capture with SOAPUI sending messages to the Play! SOAP service. The Play application pushes the SOAP message to the clients (Two browsers).

Publicités

SOA4All White Paper : Web Services Are Dead, Long Live Internet Services…


Les Web Services sont ils morts? Une vision dans le white paper qui vient d’être publié par des partenaires du projet SOA4All.

SOA4All white paper is available: « Web Services Are Dead. Long Live Internet Services« .

This white paper presents the project vision about the evolution the Internet ecosystem: Web 2.0, Semantic Web, Web of Data, Cloud technologies and other facets enabling and supporting the Future Internet of Services.

SOA4All Review M30 – Bruxelles


Bon, comme d’habitude, beaucoup de choses autour de la sémantique, sémantique de services, linked data, RDF et compagnie mais surtout l’occasion de montrer les avancées et faire un point sur le Distributed Service Bus ie le bus servant de base de l’infrastructure de service du projet.

Pour faire court, le scope à beaucoup varié et divergé de ce que nous pensions faire initialement. A la base, nous pensions nous engager vers le développement d’un bus de service massivement distribué à l’échelle d’Internet ie une extension de Petals ESB qui lui est tout juste distribué. Au final, cet aspect massivement distribué est forcément complexe et demande encore de la réflexion (surtout sur son utilité). Le scope s’est recadré vers quelque chose qui est plus dans l’air du temps en se rapprochant d’une solution SOA pour le Cloud.
Bref, on parle aujourd’hui de Federated Distributed Service Bus (fDSB) ou des réseaux/îlots de noeuds (les DSBs) sont interconnectés de façon intelligente pour créer des infrastructures fédérées. Pour ceux qui connaissent un peu Petals ESB, cela veut à peu près dire (et pout faire simple) que ces îlots ont une connaissance locale de leurs services. La connaissance des autres services n’est possible qu’a travers la couche de fédération et via des politiques de propagation des informations bien définies (un outils de gouvernance tel que Petals Master peut jouer ce role de définition des visibilités).
La couche de fédération est aujourd’hui le medium qui permet de faire communiquer ces ilots de DSBs via des protocoles hétérogènes, traverser les firewalls etc etc. On arrive alors vers les prémices du so-called « Hybrid Cloud » ie créer un Cloud SOA au sens large en utilisant du Cloud public (Amazon EC2 par exemple), du Cloud privé (via OpenNebula et compagnie), etc.
Et c’est bien le cas d’usage que l’on à dans les cartons : des DSBs sur Amazon EC2, des DSBs sur Grid5000, des DSBs sur les laptops et des invocations de services possibles (dans tous les sens et sans connaissance préalable des services disponibles).
Pour le moment on ne parle pas d’élasticité et compagnie qui font la force (à mon avis) du Cloud. Ca c’est autre chose que je suis en train de préparer en parallèle, qui devrait voir le jour dans les prochains mois et dont je parlerais sûrement à la prochaine « OW2 Annual Conference » dans un mois à La Cantine – Paris.

Créer sa couche de transport pour Petals ESB en 4 classes


Je profite d’avoir les doigts bien chauds (je viens de passer quelques jours à faire du M$ Word à plein temps, dure reprise après des vacances au grand air…) pour écrire un article que j’ai dans la tête depuis un petit moment : Comment développer sa propre couche de transport pour OW2-Petals ESB. Pour savoir ce qu’est la couche de transport dans Petals, allez jeter un coup d’oeil les précédents articles .

Note : Ce travail se base sur Petals ESB 3.0.2 mais est normalement compatible avec la v3.x. Tout le code est disponible sur le SVN du projet Petals ESB chez OW2 (le lien plus bas) et je ne l’ai pas inséré dans l’article car l’intérêt n’est pas de montrer que je sais coder en Java…

Le contexte

Petals ESB v3.x est livré avec une couche de transport permettant de faire communiquer les instances du bus de service basée sur une implémentation Java NIO. Le but de l’article est de présenter un framework de couche de transport et de montrer que développer une nouvelle couche en se basant sur le framework est simple et rapide.

Le framework

Le but n’est pas de détailler complètement le framework, mais juste les points d’extension qu’il offre. Le framework gère la logique d’envoi synchrone et asynchrone des messages, ce qu’il reste à implémenter est finalement juste la partie permettant de recevoir des messages (ie le serveur) et d’envoyer les messages sur le noeud distant (indépendamment de la logique Petals).

  • Le serveur: Il doit être capable de recevoir un message de la forme de son choix (tout dépend du protocole utilisé) et d’informer le framework qu’un nouveau message est recu après l’avoir converti en message Petals (ici JBI), rien de plus…
  • Le client: Doit pouvoir retrouver le serveur à appeler et lui envoyer le message après avoir transformé le message Petals (JBI) en message serveur-dépendant.

Le  framework est basé sur une abstraction de la couche de transport Java NIO de Petals ESB v3 et son code source est disponible dans ma sandbox dans les projets petals-transport-api et petals-transport.

Une implémentation Web service?

Oui parce que c’est la plus rapide et qu’elle est bien utile! Allez pour faire encore plus simple (et pour ne pas changer une équipe qui gagne), on va utiliser JAXWS & Apache CXF.

1. Le coté serveur

Il est en charge de démarrer le service de réception de messages, ici on va utiliser JAXWS pour exposer une instance de org.ow2.petals.transport.cxf.TransportServiceImpl qui implémente org.ow2.petals.esb.api.TransportService.

L’implémentation cré un message JBI depuis le message reçu par la pile Web service (via la méthode/opération #receive), et passe ce message au Receiver en appelant l’unique méthode #onMessage(MessageExchange). Le receiver n’est ici rien d’autre que le composant de transport du Framework (org.ow2.petals.transport.TransporterImpl dans le module petals-transport) qui implémente le service de transport de Petals ESB (org.ow2.petals.transport.Transporter) et qui possède l’intelligence pour faire remonter le message dans les couches de Petals ESB.

2. Le coté client

Ici aussi, rien de bien méchant. Il suffit de savoir créer un client Web service pour parler au serveur que l’on vient de présenter au point 1. Une fois encore, JAXWS et CXF font ca bien. Une factory est à implémenter (org.ow2.petals.transport.api.ClientFactory) et permet de créer des instance du client pour chaque container Petals ESB à invoquer.

3. What else?

Un peu de configuration via Fractal et le tour est joué. Une nouvelle couche de transport permet de faire communiquer les instances de Petals ESB via Web service au lieu de passer par NIO, tout cela avec quelques classes…

Et alors?

Avec quelques classes (même pas une dizaine, dans le meilleur des cas implémenter 4 interfaces doit être suffisant), on peut créer un nouveau type de transporter pour Petals ESB sans se soucier de :

  1. JBI. Ou presque la seule chose à faire est créer un message JAXWS depuis un message JBI et inversement (ca va il y a plus dur…)
  2. La logique de message synchrone et asynchrone. Tout cela est géré par le framework.
  3. La remontée du message vers le bon fournisseur de service.

On focalise ici vraiment sur la partie communication pure entre client et serveur. Pour valider le principe d’implémentation facile et rapide, j’ai créé un transporteur XMPP en à peu près un jour… Le code de ce transporteur XMPP n’est pas encore public mais ca ne devrait pas tarder. Il me faut juste un peu de temps…

Tout cela pour montrer qu’utiliser Petals ESB n’est pas limitant. L’architecture permet quand même des points d’extension intéressants, il faut juste s’y connaitre un peu (beaucoup). C’est juste notre métier…