Blog Petals planet

Image via Wikipedia

Je profite de passer un peu de temps à aider les collègues de l’équipe produit sur le sujet des notifications dans Petals ESB qui est assez récent dans la suite Petals pour proposer un article sur une vision de haut niveau du support des notifications dans le bus de service distribué.

L’architecture et l’intégration

Je ne reviens pas ici sur l’architecture de Petals ESB basée sur JBI (il y a assez d’articles la dessus sur mon blog) mais je voudrais parler de l’architecture choisie pour fournir un support aux notifications dans Petals. Malgré tout le support JBI est important ici car cette intégration est basée sur l’aspect composants JBI de Petals. Pour rappel, un composant JBI est une sorte de plugin qui vient enrichir le container JBI en offrant des fonctionnalités supplémentaires en tant que connecteur protocolaire ou de moteur service (les fameux Binding Components et Service Engines).
L’intégration des notifications est donc exclusivement basée sur des composants JBI via des composants dédiés d’une part et via une intégration dans le Kit de Développement de Composants (CDK) développé au sein du projet.

Du point de vue des spécifications, il est choisit de fournir une implémentation des spécifications WS-Notification de chez Oasis. Une vision simpliste de cette spécification fait intervenir un broker (un intermédiaire intelligent) pour gérer et découpler les émetteurs de notifications et les destinataires. C’est sur ce broker que les émetteurs s’enregistrent, et c’est aussi sur lui que les destinataires informent qu’ils sont intéressés par uu/des types de notifications précises. Pour plus de détails, je vous recommande de jeter un coup d’oeil à la spec elle même ou à Googler le sujet.

Du point de vue de l’intégration, le broker est implémenté dans un composant JBI dédié, le petals-se-notification. Comme tout le travail se passe généralement dans les autres composants JBI, le CDK (qui est le support pour le développement des composants) propose une activation du support des notifications en tant que producteur. Cette activation implique un enregistrement envers le broker dès son démarrage. Malgré cette activation, si aucun producteur n’est enregistré au niveau du broker, il ne se passera rien! En effet, l’architecture actuelle force les consommateurs de notifications à informer le broker de leur interêt pour des notifications via un système de topics. Je passe vite la dessus mais en gros, lorsque le consommateur s’enregistre au niveau du broker, le broker va relayer cette demande avec un contexte associé aux producteurs de notifications. Une fois cette étape achevée, des échanges de messages standard provoqueront potentiellement des notifications envoyées au broker qui fera ensuite son travail de relai.

Les principaux points forts de cette intégration sont :

1. la possibilité d’utiliser ce médium de notifications pour tracer les échanges entre consommateurs et fournisseurs de services standards. Ces informations peuvent alors être remontées vers une console de BAM par exemple.
2. L’utilisation du canal JBI pour échanger les notifications. Pas de nouveau canal de communication à créer, tout passe par les couches de communications du bus de service. Comme Petals est un bus de service nativement distribué, cette approche est vraiment un point important.
3. Le support rapide via un CDK qui fournit toute la mécanique nécessaire pour implémenter ses producteurs et consommateurs de notifications.

Cette intégration a bien sûr des points faibles. Premièrement, il faut absolument que le composant qui fait acte de broker soit présent et robuste pour pouvoir gérer les notifications venant de N fournisseurs en tant que point central. Ensuite, ce broker doit (pour le moment) être unique dans le contexte du bus. En placer un autre sur un autre noeud du bus n’est pas possible actuellement (enfin si c’est possible mais des messages seront perdus).

La suite?

De nouveaux projets sont au programme en cette fin d’année avec pour but (un des buts plutôt) d’aller vers une architecture full EDA intégrée dans le coeur du bus. Cela va normalement supprimer les points négatifs cités précédemment avec notamment la suppression des composants JBI et le développement d’un broker distribué se basant sur l’architecture distribuée de Petals. Cela fera bien sûr de la matière pour les prochains articles de ce blog courant 2011.

En attendant, un prochain article portera surement sur quelque chose de plus technique avec un peu de code, je conseille de faire tourner la démo (disponible ici) qui met en oeuvre Petals ESB, Petals View et les notifications. Elle éclaircira mes dires, car le blahblah c’est bien, passer à l’action c’est mieux!

Tags: architecture, esb, notification

Oui je sais, pourquoi faire un bilan au bout de 6 mois et ne pas attendre la barre psychologique des un ans? Surement parce que je trouve que ce mode de travail est beaucoup plus productif (dans mon cas) et que finalement il me semble avoir fait beaucoup plus de choses en 6 mois chez moi qu’en 12 dans un environnement de travail ‘classique’ (enfin si de nos jours on peut appeler un openspace bruyant un environnement de travail classique).
Alors pourquoi et comment en suis-je arrivé à vouloir partager cette expérience? Quel est le pour, le contre, les mises en garde, les choses à faire et à ne pas faire? Je vais essayer de donner des réponses par rapport à ma petite expérience sur le sujet de façon totalement transparente.

C’est peut être le fait de travailler en tant que développeur (entre autres) dans une startup cool et dans l’Open Source qui m’a emmené à pouvoir passer en mode télétravail, à vrai dire il semble que c’est un fonctionnement qui est de plus en plus fréquent (réduction des coûts, du stress, …) mais là n’est pas le sujet de l’article.

Evidemment, une des premières choses qui vient à l’esprit, c’est le gain de temps. C’est vrai j’économise à peu près 59 minutes de trajet par jour (en estimant que monter à l’étage le matin et en descendre le soir me prend 1 minute, ce qui est large!). Ce stress là est épargné: plus de voiture, de métro et de marche dans un environnement pollué pour rejoindre les bureaux du centre Toulousain.
Par la suite, ce gain de temps augmente au cours de la journée : Plus besoin de faire le tour des bureaux pour dire bonjour à tout le monde (non je ne suis pas sauvage), connecter son client de messagerie est suffisant; plus de perturbation par les discussions du bureau d’à coté sur le match de la veille, plus besoin de repasser les habits, etc… Au final j’estime que le cumul doit tourner autour des 1h30 à 2h par jour… Donc au final, sur une journée, le choix est possible entre travailler moins de temps effectif pour un rendement équivalent ou vraiment travailler les 8 heures syndicales… Je dirais que ça dépend des jours dans mon cas…

Ensuite effectivement, l’environnement de travail à la maison est plus calme que celui du bureau. Bon il faut dire que j’habite dans un lotissement très calme, pas de bruit, pas de passage de voiture, les enfants jouent de temps en temps dans la rue mais ce n’est pas ça qui peut me déranger. On est généralement tous d’accord, que travailler dans un environnement calme permet d’être productif. Aujourd’hui je ne suis plus obligé de mettre mon casque et écouter de la musique en continue pour masquer les autres bruits… Un point positif de plus… Ah oui, je pense qu’il est important d’avoir  son bureau dédié, dans une pièce séparée et ne pas avoir à travailler dans le salon ou dans la chambre… Finalement, la seule chose qui me manque vraiment, c’est la clim! L’été dans le sud c’est un peu rude… Bon, pour palier à ça, j’ai un frigo plein de glaces, je travaille en short et le soir je peux aller piquer une tête à la mer.

Il est aussi important d’établir des règles avant de quitter les bureaux de la société. Que ce soit pour le matériel, les frais et compagnie. La chose la plus importante est le contact avec les collaborateurs et la hiérarchie. La messagerie instantanée est efficace pour poser les questions et être questionné par la même occasion. Elle ne remplace pas les discussions de bureau mais je fais souvent des breaks en parlant avec quelques collègues, je vais à la chasse aux potins car dans mon bureau, il ne se passe rien… La règle la plus importante reste la périodicité de ‘visite’ dans les locaux de la société. Il est pour moi très important de pouvoir discuter de visu, échanger, faire des réunions, voir les gens, … Tout ça car les discussions par mail ne sont pas aussi faciles qu’elles en ont l’air. Un courrier électronique c’est bien, par contre ce qu’il manque c’est l’intonation… Des choses qui ne devraient pas être mal prises le sont souvent, au bout de la 3eme réponse on s’aperçoit que le contenu n’a plus rien à voir avec le sujet initial… Bref, la communication électronique à aussi ses inconvénients. Le téléphone reste le meilleur outil pour ça!

Et la rigueur alors? Je pense que ce mode de travail ne peut être compatible qu’avec une certaine rigueur? Dès le début, l’important est de s’imposer des heures de bureau et de s’y tenir sinon il me semble que l’on peut très vite dévier sur des horaires décalées non compatibles avec une vie de famille digne de ce nom. Non je ne travaille généralement pas le soir car j’ai aussi une famille et une vie extra professionnelle. D’ailleurs celle ci s’est étoffée et s’étoffe encore… J’ai du temps en plus, donc je me suis vraiment remis au sport (pour compenser la sédentarité), j’ai repris les activités que j’avais délaissé comme la photo… Je me suis même mis au jardinage (la première récolte de tomates est prometteuse).

Dernier point : il faut être proactif! Toujours être à l’affût, ne pas se faire oublier, faire des propositions, réagir aux mails… De ma faible expérience, il me semble que des fois les gens pensent que je ne fais plus partie de la société. Non, j’ai toujours le même statut, je fournis toujours un travail conséquent, je pars toujours en déplacements (et ça fait du bien de sortir de ma maison), je rapporte toujours de l’argent à la société et donc je suis toujours un employé comme les autres. Je ne veux pas que l’on me laisse dans mon coin être un emploi fictif! Je ne veux pas aussi me reposer sur mes lauriers, dans notre monde de développeur il faut toujours être actif, de remettre en question, apprendre de nouvelles choses que ce soit par le biais des projets sur lesquels on travaille, ou de façon personnelle avec de l’auto-formation.

Voilà un tour d’horizon rapide de ses premiers gros six mois de télétravail, pour moi le bilan est plutôt positif et je pense continuer sur cette lancée. La suite de mes aventures de télétravailleur  geek sûrement bientôt!

Tags: bilan, expérience, télétravail

Un article pas bien avancé techniquement, juste une astuce/une utilisation de l’API du JDK…
En parcourant le code de java.util.concurrent.ScheduledThreadPoolExecutor je suis tombé sur une utilisation de java.util.concurrent.TimeUnit que je ne connaissais pas et qui est fort utile pour faire des conversions de durée : la méthode #convert(long, TimeUnit).

Plus besoin de s’embêter, ni même de réfléchir, convertir n’importe quelle unité de temps vers n’importe quelle unité de temps est simple :

long days = TimeUnit.DAYS.convert(22545455566L, TimeUnit.MILLISECONDS);

ie 22545455566 ms sont équivalentes à 260 jours.

Tags: astuce

Cela semble être une chose plus compliquée que d’apprendre un nouveau langage de programmation (pour certains en tout cas)…
Les commentaires font parti du code source (oui ma petite dame), sans lui et malgré toutes les spécifications du monde, un code source peut vraiment être obscur: Mauvais noms de variables, classes ou encore design patterns exotiques faits maison… Mais là où cela devient vraiment obscur, c’est quand on tombe sur un commentaire qui enfonce le clou encore plus, du style « //TODO : Refactor… ». OK… euh bon là j’avais bien compris que moi je n’aurais pas codé le bouzin comme çà, et même le gars qui l’a codé le savait lui aussi. Merci de m’avertir avec un beau TODO mais en fait il ne sert à rien car ton code là, et bien je vais le refactorer mais en plus je vais imaginer et espérer qu’il faisait ce que je vais en faire avec mes 10 doigts et mon reste de cerveau (car non ami développeur, je n’en ai surement pas plus que toi).

C’était la pensée du jour : « Coder c’est bien, avec les commentaires intelligents c’est mieux »

Tags: code, coupdegueule

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…

Tags: module

If you can walk into any library or Internet cafe and sit down at any computer without preference for operating system or browser and access a service, that service is cloud-based.

… de Cloud Applications Architecture chez O’reilly

Ca ne rentre pas sur mon Twitter et je pense que c’est une bonne définition à partager!

Tags: citation, Cloud

Welcome to Christophe Deneux, the new Petals Link CTO !

Christophe was chosen for his experience of SOA project, his skills for industrial developments, and his great motivation as a community contributor. He was architect and main developer of a huge SOA project at ACOSS, the first big open source SOA project in France. At Capgemini, he participated to a global and transversal project, to make code development more industrial. His background in system integrators companies will help work more closely to these essential partners. He was also the first contributor in Petals project, both in time and in contributions, which give him great knowledge on the software.

So what’s his mission? Manage product technical evolutions, improve development industrialization, and help customer design their architecture.
You might work with him one day ;-)

So welcome Christophe!

To avoid any jealous, let’s welcome also two new developers for Petals ESB, who arrived those last three month : Nicolas Oddoux a young and motivated engineer, and Marc Jambert, an experienced developer and also technical support guy.
You can react commenting this article below.

Permalink | Leave a comment  »

Un article pas technique du tout (ou presque, enfin il n’y a pas de code), ca change un peu… Je suis de retour de Milan où j’ai passé quelque jours pour une réunion de travail (et à manger pâtes et pizzas…) sur le projet  SOA4All que je leade chez PetalsLink (pour ceux qui n’auraient pas encore compris..).

C’est la dernière ligne droite puisque le projet est dans sa dernière année (bien entamée), et il reste encore des choses intéressantes à faire. La plus ambitieuse est surement l’intégration finale de OW2 Petals ESB et de OW2 Proactive pour créer un Bus de Service Distribué et Fédéré via un Framework de fédération maison.
Un article sur les concepts de la fédération est disponible au téléchargement. Les premiers tests de déploiement sur le Cloud pour créer une fédération sur Internet entre différents providers (Amazon EC2, Grid5000, …) et de performance nous permettent d’être assez satisfait du prototype actuel.

Mais comme on est jamais assez satisfaits, la suite réserve encore et surement beaucoup de bonnes choses que ce soit pour SOA4All ou pour les projets de recherche a venir.

Petit tour sur le toit de la cathédrale - Duomo

Tags: esb, proactive

Now you can post Support ticket (If you have support) or Bugs on the Petals issues tracker.

For information, we're using JIRA with the free license for open source projects, generously offered by Atlassian.
Second time using an Atlassian product and it's still a pleasure. First time that was switching the Petals documentation on the wiki Confluence.

Permalink | Leave a comment  »

Dans un précédent article sur l’exposition de composants Fractal en Web service dans Petals ESB, je décrivais la démarche technique à suivre qui comprenait un certain nombre d’étapes (contraignantes), telles que :

1. Avoir l’obligation de créer un composant spécifique par service à exposer
2. Avoir l’obligation d’implémenter une interface spécifique (KernelWebService)
3. Avoir l’obligation de décrire et de binder le service dans les fichiers de description ADL

Disons que cette approche est finalement assez simple mais devient vite lourde lors que l’ajout de services. La solution du jour va supprimer les 3 points cités ci dessus. Comment?

1. Un composant implémentant une interface annoté en JAXWS doit être la condition suffisante pour être exposé en Web service
2. Un composant spécifique est en charge d’exposer les composants Fractal qui satisfont la condition 1.

Le composant introduit dans le point 2 ci dessus, que l’on appellera le WSM (‘Web service Manager’) est le composant qui introspecte le composite Fractal dans lequel il est instancié. Il a ainsi la visibilité des composants qui implémentent une interface annotée en JAXWS et peut l’exposer, ici en utilisant Apache CXF.
En allant plus loin, on peut facilement imaginer avoir un WSM de haut niveau qui peut se balader dans l’arbre complet du modèle Fractal et exposer tout les services du bus (ou une partie que l’on juge intéressante par filtrage).

Note pour l’équipe : Ce code est disponible sur la forge de mon projet recherche, disponible sur demande

Tags: esb