Le Montpellier JUG: C’est parti!


J’en ai parlé quelques fois sur ce blog (ici ou ), le Java User Group Montpelliérain est maintenant prêt pour sa première soirée planifiée pour le 13 avril 2011. Au programme, on commence l’aventure avec les sujets GWT et Maven 3 présentés par des experts locaux.

Pour plus d’informations et pour les inscriptions à cette première soirée, ca se passe sur le site tout beau tout neuf développé pour l’occasion (je reviendrais sur ce qui à été utilisé plus tard) : http://www.jug-montpellier.org/. N’hésitez pas à venir jeter un coup d’oeil, dire bonjour, vous instruire et boire un coup!

Vidéos : Monitoring et Management de Petals ESB


Ou plutôt de distributions customisées et étendues de Petals ESB. Ces deux vidéos illustrent une petite partie de ce que je fais depuis quelque temps sur le projet SOA4All où j’utilise Petals ESB en tant que base pour une infrastructure de service largement distribuée.

Monitoring

Management

La suite au prochain épisode…

Sur l’utilité d’utiliser des standards « Internet-Friendly »…


… et aussi sur l’utilité de développer ses applications de facon générique. La preuve par l’exemple : L’administration du bus de service Petals ESB.

JMX c’est bien pour manager une application Java mais il faut savoir parler JMX et généralement, parler à une application JMX via Internet c’est pas forcément le pied et encore moins quand l’administrateur réseau ne veut pas qu’il y ait autre chose qui rentre chez lui que du bon vieux HTTP et être ce que j’appelle ici ‘Firewall-Friendly’.

Tentative de passage de Firewall

Pas Firewall-Friendly?

Bref, je milite ici sur l’utilité d’avoir une administration d’application générique qui peut être exposée dans la technologie et le protocole qui colle le mieux au contexte. Et la je parle principalement de ce que je connais le mieux : Petals ESB. Ce bus de service est fortement basé sur la spécification JBI. Il est tellement lié que l’administration du bus ne passe que par JMX, même pour effectuer des opérations internes au bus… L’administration ne doit donc pour moi être fournie que sous forme d’API et d’implémentation indépendante de toute technologie d’exposition. A charge du développeur de l’application de fournir les mécaniques adéquates pour exposer cette API en JMX, en Web Services, en REST, etc… Cela fera surement l’objet d’un article sur une mise en pratique de ce genre d’approche dans Petals.

Le but principal et original de cet article était de parler un peu de ce que l’on peut faire en terme d’administration et de monitoring du Bus Petals. Je travaille depuis quelques temps déjà sur un projet visant à créer une infrastructure de service largement distribuée sur Internet dans le cadre du projet de recherche SOA4All. Je viens de finir un prototype d’application Web qui permet de manager ces noeuds exposés sur Internet et d’effectuer quelques opérations qui ne sont pas disponibles dans une distribution standard de Petals (tout du moins l’API de base ne les fournies pas). Comment? Et bien forcément sans utiliser JMX (j’en suis assez allergique ce qui rajoute un allergène à ma liste déjà longue, en plus c’est le printemps…), mais plutôt en utilisant et en étendant l’API Web service que j’ai développé pour Petals 3.0. Cette application permet alors de se connecter à n’importe quelle instance de Petals (et à son réseau) exposée sur Internet via une API WS et ainsi de lier des services externes au bus, d’exposer des services internes, de voir ce qui se passe dans le bus et bien plus encore… Tout cela en utilisant GWT pour créer une application sympa avec des choses qui bougent car Petals à une activité qu’il faut pouvoir montrer en direct!

DSB Manager Portal

DSB Manager Portal

PEtALS ESB Live Monitoring with WSDM and GWT


In one of my previous posts (Adding Registry Listener in PEtALS), I spoke about adding a registry listener in PEtALS ESB. In the current article, I want to introduce how I used this feature to implement a live monitoring Web application.

Here are the different modules which are used in this Live Monitoring Tool :

  1. PEtALS ESB. The standard behaviour has been customized by adding a registry listener and a routing module (to be detailled below).
  2. Monitoring layer. This layer is an independant process which embeds a WS-Notification engine.
  3. A WS-notification subscriber. This is the module which will receive the notifications from the monitoring layer.
  4. GWT based Web application used to display monitoring data.

PEtALS ESB Extensions

Registry Listener
The role of the registry listener is to register a new monitoring endpoint into the monitoring layer when a new endpoint is available within PEtALS.

Routing Module
Since modules can be added dynamically inside the PEtALS message router, we have created a module which timestamp the messages. Once the message exchange is complete, a message exchange report is sent to the monitoring layer.

Monitoring Layer

The monitoring is in charge of creating monitoring endpoints through a management API. Once a monitoring endpoint is created, it is also exposed as a Web service. This newly created Web service exposes a WS-notification subscribe operation.
Another role of the monitoring layer is to receive raw reports from the PEtALS ESB, to process the report in order to generate a WSDM payload which will be send to subscribers.

WS-Notification subscriber

The subscriber subscribes, receives and stores notifications from the Monitoring layer. That’s all for that module ;o)

GWT Based Web application

The GWT Web application uses comet in order to display live service response time. The data used to display response time is the one received and stored into the database and of course the server part of the Web application have access to this database.

As a result, we have a really nice live Web application (live means that the chart gives real time result and is updated automatically when messages are exchanged within PEtALS Service Bus). Here are some screenshots :

Live Response Time

Live Response Time

SLA

SLA Violation

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…