Speaking at OW2Con 2012


Me @ OW2Con 2012

Me @ OW2Con 2012

One more time this year, I will give some talks at the OW2 annual conference. I spoke about Petals and the Cloud in 2010 and 2011 and this year again, I will talk about it but not only:

  1. Playing with SOA, EDA and Event Processing in the Cloud. I will introduce the PLAY research project which will soon become an OW2 project. (Hope to do a demo which works on low resolution this year…)
  2. What’s new in Petals? Petals is not only an Enterprise Service Bus, there are also cool tools around which help to integrate your services and run your processes in a distributed way. We will also give details about what is coming in the next months, we have many things in mind. This will be a join talk with @VincentZurczak
  3. Development 2.0 @ OW2. Finally, as an active Technology Council member, I will share a talk with @sauthieg and @clementplop to introduce our vision on a distributed/collaborative development platform.

We also have some talks planned around other Linagora projects: @jplorre will introduce the OpenPaaS project and @clementoudot will LemonLDAP.

More details on the talks and sessions are available on the conference Web page. Note that this event is free as well as the beer at the social event…

Publicités

Petals DSB is not Petals ESB


Almost true… In fact Petals DSB uses and extends Petals ESB in several ways. When I started to think about extending the Enterprise Service Bus, it was just to avoid all the JBI stuff at the management level i.e. use a real, simple and efficient API. So I added many management stuff exposed as Web services : Bind external services, expose internal services (oh yes bind + expose = proxy), get endpoints, activate things, etc…
One other goal was to avoid to use closed protocols for inter node communication: The ESB uses at least three ports to create inter node communications for JMX, NIO and SOAP. So why not, just using an open protocol like SOAP and just one port? This is what I did, I changed some implementations to use the same port and the same protocol for all services.

All this stuff has been developed focusing on extensibility and easier development. This is mainly because the ESB can be hard to extend for newbies, there are so many things inside… Today the DSB is not only a Distributed Service Bus, it is also a framework so that developers can easily extend the DSB without the need to know how it works inside. Some examples? Want to expose a kernel service : Add the JAXWS @WebService annotation. Want to subscribe to Web service notifications : Annotate you Java method with @Notify. Want to be notified about new endpoints : Add the @RegistryListener annotation. That’s all, you do not have to search for the Web service server to expose your service, nor read all the WSN documentation to receive notifications, … Simple, efficient.

There are other things you can do, mostly all is detailed in the DSB page.

Invoke business services from service bus kernel


Let’s introduce what it means…

While Petals ESB does not provide any solution to invoke services directly from the kernel/component Java code, the DSB now provides a solution for that… By using this DSB feature, we can really use the power of service oriented architecture directly in our code. No more direct calls to services, you just need to call the client and say which service you want to invoke. The service bus will resolve the endpoint and route the message to the right place by using the right way/path. By using this way, you do not have to care if you need to speak with a SOAP service, a JMS queue or a REST service: Just call the service, the DSB will do the rest.

Now some code…

So, let’s have a look on the client code and first, let’s imagine that you have a web service which is bound to the service bus. Once bound, a DSB endpoint is available inside the DSB, and all messages which are sent to this endpoint will be forwarded to the final web service. One basic approach is to create a web service hosted by the service bus which ‘consumes’ the DSB service. As a result, a SOAP message sent to the DSB web service will be forwarded to the DSB endpoint which will forward it again to the final web service. Allright, but this is just for external SOAP clients and it is impossible to invoke anything firectly from the service bus kernel.
Now, let’s call the DSB endpoint from Java code… To put ourselves in a **real** case, let say that you are DSB kernel developer and that you want to say hello to the world (oh s*** really?) by using the *HelloWorldService* which is bound to the bus. Let’s code this client:

https://gist.github.com/1186183

So, just get a *org.petalslink.dsb.service.client.Client* from the *org.petalslink.dsb.service.client.ClientFactory* factory, create your *org.petalslink.dsb.service.client.Message* and send it by using the *sendReceive* method. That’s all… Let’s try to clarify what it means with a simple schema:

Hacker inside!

It looks so simple… I just deeply hacked the petals service bus kernel to provide such a thing. Why? Because the service bus is also deeply based on the JBI specification: Creating a client means that the client need to be able to receive responses and acts itself as a service on the service bus point of view. It is also built using all the component context stuff. No component context means no way to send/receive messages (component contexts are just created when JBI components are installed).
So it is really important to release the client when you do not use it anymore: There are tons of listeners and threads in the different layers which are just used to receive messages. If you do not release the client, there will be unused resources for a long time.

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.

Jouons avec le Petals Kernel et Apache CXF


Oui, à chacun sa façon de s’amuser… Je viens d’ajouter une feature dans le Petals Distributed Service Bus qui me trottait dans la tête depuis un petit moment: Pouvoir invoquer des services techniques (distants ou pas) du coeur du DSB en utilisant la couche de transport naturellement utilisée pour invoquer des services métiers (les services hostés par le bus ou liés à celui ci). Autrement dit, imaginons que j’ai un service technique qui tourne sur un noeud et que depuis un autre noeud, je dispose d’un client pour l’invoquer de façon simple mais aussi totalement transparente.

Ce que l’on pouvait faire jusqu’à présent, c’est utiliser l’API Web service exposée par le DSB pour invoquer le service pour peux que le service soit annoté comme il faut (pour rappel, cette API Web service utilise Apache CXF pour exposer automatiquement les composants Fractal qui sont annotés avec JAXWS). Bien, mais par défaut on utilise deux ports pour les communications inter noeuds: Le port utilisé par Apache CXF, et l’autre par la couche de transport du DSB (en fait c’est le cas dans Petals ESB, mais dans le DSB, la couche de transport étant par défaut une implémentation en Web service, on utilise le même port pour les deux). En allant un peu plus dans les détails, même si on utilise le même port pour les deux modules dans le DSB, ceci n’est plus vrai si une nouvelle implémentation de la couche de transport utilise autre chose que CXF (pour info, dans le DSB, une implémentation de la couche de transport en XMPP existe aussi). C’est donc la qu’on arrive a la solution d’utiliser le canal de communication du DSB pour toute invocation entre noeuds, comme on sait déjà échanger des messages avec le DSB, pourquoi s’en priver?

C’est bien beau de vouloir exposer des services, des composants Fractal, ou quoi que ce soit, si on veut rester en Java et ne pas avoir besoin de se triturer le peu de cerveau qu’il nous reste, autant penser à utiliser tout ou partie d’une solution qui existe deja. En allant dans ce sens, comme on doit au final avoir une sorte de serialization des messages, autant utiliser quelque chose qui sait deja le faire, j’ai nommé le couple inséparable JAXB+JAXWS. Ceci impliquera seulement d’annoter ses interfaces et de créer des types propres et JAXB-aware mais au final, je ne pense pas que cela soit une contrainte forte… C’est bien beau tout cela mais JAXB + JAXWS tout seul ca ne fait pas grand chose. C’est la qu’entre en jeu Apache CXF. Puisque l’utilisation de JAXWS est simple avec CXF, autant s’intéresser un peu à la bete. Pour le coup cà tombe bien, dans CXF il y a deja une notion de transport multiple: HTTP, XMPP, JMS et si on regarde bien on a même JBI (les potes de chez JonAS ont d’ailleurs implémenté un transport CXF utilisant les EJB ou un truc J2EE dans le style si ma mémoire est bonne). Tiens donc, il y a un transport JBI? Ca tombe (presque) bien, le DSB est basé sur Petals ESB qui est JBI compliant. Oui mais en fait non. J’aurais presque pu l’utiliser mais le but est d’implémenter quelque chose d’assez ‘JBI independant’. Le tout est maintenant d’implémenter un nouveau transport pour le DSB et grace au code source de CXF et à cette page http://cxf.apache.org/custom-cxf-transport.html on comprend assez bien comment faire. Dans la terminologie CXF, le client est le ‘conduit’ et le serveur est la ‘destination’. Il suffit donc d’implémenter nos propres conduit et destination pour pouvoir échanger des messages avec CXF.

Une fois CXF configuré avec nos conduit et destination, ou plutôt une fois la bonne transport factory implémentée, on devrait pouvoir faire quelque chose du style:

// 1. Initialize CXF Bus with factory
Bus bus = BusFactory.getDefaultBus();
DestinationFactoryManager dfm = bus.getExtension(DestinationFactoryManager.class);
DSBTransportFactory petalsTransportFactory = new DSBTransportFactory();
petalsTransportFactory.setBus(bus);
petalsTransportFactory.registerWithBindingManager();

// 2. Start service
System.out.println("Starting CXF server...");
JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setAddress("dsb://host/serviceA");
sf.setServiceClass(HelloService.class);
sf.setServiceBean(new HelloService() {
    public String sayHello(String input) throws PEtALSWebServiceException {
        System.out.println("SAY HELLO INVOKED!");
        return pre+input;
    }
});
sf.create();

// 3. Create the client and invoke
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setAddress("dsb://host/serviceA");
factory.setServiceClass(HelloService.class);
HelloService hello = (HelloService) factory.create();
String out = null;
try {
    out = hello.sayHello(in);
} catch (PEtALSWebServiceException e) {
}

Je passe les détails d’implémentation (que j’ai eu le plaisir de faire dans un bon vieux TGV en panne entre Montpellier et Bruxelles) pour le moment, mais ce qui se passe se résume à:

  1. On configure CXF en lui ajoutant notre Transport Factory. Au niveau de l’implémentation, il y a ce qu’il faut pour que lorsque une client ou une server factory est configurée avec une adresse qui commence par ‘dsb://’, ce soit notre DSBFactory qui soit automatiquement appelée par CXF.
  2. La création du service se fait comme si on créait un Web service sur http sauf que là c’est un ‘Web service sur DSB’.
  3. Idem que pour 2 mais on génère un client qui nous permettra d’appeler le service créé auparavant.

En résultat, pour peu que le client (en 3) et le serveur (en 2) soient exécutés sur des noeuds séparés, le DSB se chargera d’acheminer la requête et la réponse comme il faut entre les acteurs et ceci de façon complètement transparente. Au niveau de l’implémentation coté kernel du DSB (ceci vaut aussi pour Petals ESB), il suffit de connaître quand même un peu le coeur pour créer des fakes de composants JBI en farfouillant dans les APIs disponibles, de savoir jouer avec le DeliveryChannel, le ComponentContext, le NormalizedMessageRouter, ajouter quelques modules de routage, savoir recevoir des messages et y répondre, et surtout implémenter le Conduit et la Destination CXF en s’inspirant de ce qui existe déjà et en mettant les doigts dans le cambouis. Pour les curieux, je vous conseille de jeter un oeil au code de CXF assez compréhensible et pas mal fait du tout.

Enfin pour étendre cela aux services techniques du coeur du DSB, il suffit, au runtime, de scanner les services disponibles offerts par les composants du kernel et automatiquement créer les services comme décrit dans l’étape 2. Chose que l’on sait déjà faire dans le DSB via le scan pour exposer les services en Web service sur HTTP avec CXF (oui toujours lui, avant je m’en prenais a Axis2…).

Et voila donc une belle et simple façon de simplifier la vie du développeur du DSB (c’est à dire moi). Il va être maintenant possible d’invoquer n’importe quoi de n’importe où avec une API Java. Pour peu que l’on plugge quelques modules au bon endroit, on peut imaginer faire des choses assez sympa: Le Cloud en fait partie.

Note: Le code sera disponible d’ici la fin de la semaine sur le SVN du DSB. Surement sous https://svn.petalslink.com/svnroot/trunk/research/commons/dsb/modules/dsb-kernel, je mettrais a jour l’article en fonction…