Vendredi 7 octobre. 12h40. On m’appelle pour me demander un tutoriel vidéo, tutoriel qui pourrait servir d’anti-sèche bientôt.

Ce n’est pas la première fois que j’ai à faire des tutoriels. Ce qui m’embête, c’est l’aspect vidéo. Avant, j’utilisais Wink pour faire des démos. Sauf que partager du flash, par mail ou sur des sites de vidéos, tels que Vimeo ou Youtube, ce n’est pas génial. A cause de cet appel, j’ai dû me replonger dans cette jungle, pour finalement (re)découvrir que VLC Media Player pouvait vous aider à enregistrer ce qui passe sur votre écran.

Voilà comment faire.
Vous lancez VLC et vous aller dans Média > Convertir / Enregistrer.
Vous allez ensuite dans Périphériques de capture.

Dans le mode de capture, vous choisissez Bureau.
Dans les options, je vous suggère de mettre 24 ips (images par seconde). Moins, votre vidéo sera lue très vite. Plus, ce sera un ralenti. Enfin, en bas, vous cliquez sur Convertir / Sauvegarder.

Il vous faut ensuite indiquer le fichier de sortie pour la vidéo (dans quoi vous enregistrez).


Appuyez donc sur Parcourir, sélectionnez le dossier de destination et le nom du fichier. N’oubliez pas de préciser l’extension du fichier. Dans mon cas, j’essaye avec du mp4. Puis cliquez sur Enregistrer.

Au retour, vous pouvez configurer les codecs utilisés.

Voilà, vous êtes prêt !
Il vous suffit de cliquer sur Démarrer pour commencer la capture.

Pour l’arrêter, allez dans Lecture > Stop.

Petit conseil…
Aujourd’hui, j’étais en mode “débordé” et j’ai par défaut utilisé du mp4 avec codec H.264. Sauf que l’encodage en H.264 est super gourmand en ressources. Et ce n’est pas un codec facile à manipuler ensuite. Aussi, je vous conseille plutôt d’enregistrer en mpg (avec codec mpeg-II), qui est un format plus facile à éditer. Vous pourrez ensuite faire du montage linéaire (ou non-linéaire), rajouter des commentaires audio, etc. Après, libre à vous de compresser le résultat final (après édition) ou de l’envoyer sur un site de partage.

Pour info, j’ai VLC 1.1.5, sous Windows 7.
Mais ça doit marcher sur toutes les plateformes…


Hi,

Here is a step-by-step tutorial to explain how to set up your workspace to work on a RCP application hosted on Git and built with Maven + Tycho. Luckily, I have such an application under the hand. It is called Petals Studio and it is available under the EPL license.

This article aims at showing to Petals Studio developers how to configure their Eclipse now we have moved on Git. Besides, it also illustrates the use of several Eclipse tools together, and this can be applied to any RCP application.

Getting the sources

First, get Eclipse (3.7) and install EGit.
Now, check out the master branch of the studio. Go into Show View > Git Repositories. In the view, click Clone a Git repository

Now, define the location of the remote Git repository and clone it.
Petals Studio is available on Git Hub but also on Petals Link’s Git repository. The creation wizard is straight forward. The checkout is done with the HTTP connection.

You can click Finish here (the next page is useless for the moment).
The code repository is cloned on your disk. When it is done, you should see this in the Git Repositories view.

You should recognize the file structure in the working directory. It is the one used to build with Maven and Tycho.

Importing and compiling the projects

It is now time to import the projects.
First, right-click the repository (the root) and select Import Projects… Use the Import Existing Projects option and click Next.

You should then see the list of sub-projects to work on: plug-ins, features and test projects. This is to work on them using the PDE (Plug-in Development Environment). Import them all by clicking Finish. We will organize them in working sets later.

The projects are all imported in your workspace, but there should be compile errors. This is because the target platform is not right. Go back in the Git Repositories view, right-click the repository, again, and select Import Projects… Use the Import as General Project option. Make sure the root directory (working directory) is selected and click Next.

On the next page, click Finish.

Your workspace should contain projects for the PDE and a general project that contains the entire Maven structure.

We can now configure the target platform.
Go into Window > Preferences and select Plug-in Development > Target Platform. The one to use is named Eclipse 3.7 – Indigo and is located under the target-platform directory of the Maven file structure.

Then, click OK.
Wait some time, until all the plug-ins are brought back on your machine. The error should then have disappeared.

Testing a commit

OK. Let’s now test a commit.
Since we cloned in HTTP, we will not be able to push my modifications. We will have to configure it in SSH, since it is the only approach available for Petals Studio’s repository. This part mainly serves as an example for other RCP applications.

Make some tiny modifications in a project, save the files, right-click the project and select Team > Commit… Enter a short message and click Commit.

The modifications have been committed in your local repository. It is now time to propagate local commits on the remote (master) branch. In the Git repository, right-click the master branch and select Push to upstream  A dialog shows up and indicates an error.

Click Configure…
A dialog appears about the push preferences.

Add a new push URI. A second dialog shows up. Type in the SSH configuration and click Finish (committers on Petals Studio, be careful, the right push URI is in fact slightly different).

You should then see your new push URI.


Click Save and push to propagate your work on the remote branch.
Notice that we directly pushed my modifications on the master branch. This is not always what has to be done. It was more about illustrating the use of a push URI which is different from the original repository address. Otherwise, work with branches…

Organizing the projects

For the moment, we have 4 kinds of projects:

  • Plug-in projects, used with the PDE.
  • Features projects, used with the PDE.
  • Tests projects, wich rely on SWT Bot.
  • A general project with the entire Maven structure for the build.

To ease the work, it is better to define 3 working sets: one for plug-ins, one for features and one for the tests. The general project can be part of all of them or from none.

Go into a view, like the projects explorer or the package explorer.
In the menu, click Select Working Set… Click New and populate the first working set (I generally use the Java type). Repeat this operation twice until you have the 3 working sets. It may even be a good idea to have a fourth one just for the Tycho / build project.

Use the working sets to filter the projects to display in your project view.
It is then more readable and easier to focus.

And that’s it.
A RCP application can be quite large in terms of projects. Using Tycho simplifies a lot of things but requires a good file hierarchy. And EGit is quite new, which means there is a (little) adaptation period. Making all of these working together is not trivial the first time. So, hopefully, this article will help some people to gain some time on setting up their RCP development environement.


I explained in the last articles how I tested the Play Framework, Web sockets and how I integrated all this nice stuff with a real example based on a Service Bus, Web services Notifications, etc…

This time, let’s go one step further. We have a Service Bus which is Web service notification enabled like last time. We can bind services to the bus, expose service endpoints as Web services, blahblahblah… But, this time, I am interested on having some real time monitoring of service invocations. It means that each time a message goes through the service bus (a service invocation in fact), I want to know (almmost) immediatly the service response time.
Hopefuly, the PetalsLink Distributed Service Bus I develop and use provides many extension points. One is the capability to add modules to the routing engine ie the software module each message must be able to go through on service request and response. So adding some router module which catch all the messages, timestamp them and then send this monitoring data to someone is quite easy. At the implementation level, this monitoring router module publishes monitoring reports to the service bus notification engine topic dedicated to monitoring stuff.

So, a client interested in monitoring data just has to register itself as subscriber to the monitoring notification topic. Every time a message is published in the topic, it will be delivered to all the subscribers. Up to the subscriber to display data as soon as it can. This is where Play, Web sockets and some cool javascript library came in. Since I never developed javascript stuff, I tried to find an easy to integrate solution to create some moving plots, asking twitter. I finally found the Smoothie Chart library which is really easy to use and updates graph in real time.

The high level architecture of the system can be defined as

The following video shows the result of the complete stack: Each time a message a service is invoked with SOAPUI, a Web service notification is sent to a Play application which subscribed to the monitoring topic, the Play application then pushes the data to the client by using a Web socket. Finally, the javascript code on the client side feeds the Smoothie chart which updates automatically. At the end, it is quite simple and efficient.

Oh, I forgot to say something: This took me 2 or 3 hours to create all this stuff… The code has been published on github in the dsbmanager-webapp project.


Classé dans:Java, SOA Tagged: bus, dsb, eda, esb, event, Message, monitoring, PEtALS, petalslink, petlas, Play Framework, servicebus, SOA, SOAPUI, Web service, WebSocket

Petals Studio is now on Git!

In: Uncategorized

28 Sep 2011

Petals Studio, the Eclipse-based application for Petals ESB, is now on Git.
You can get the source code on Petals Link’s Git repository or at GitHub.

And many thanks to Mickaël for the migration.


A la base, cet article devrait expliquer l’utilisation de Petals ESB avec un load balancer en frontal du bus.
Le load balancer en question étant un serveur Apache avec le module « mod proxy balancer ». Mais finalement, il m’a semblé préférable de faire un billet intermédiaire pour expliquer ce qui n’est pas toujours évident à priori : Petals n’est pas un load balancer.

Petals ESB est composé de 3 principaux niveaux.

  • D’abord, il y  a le conteneur, que l’on appelle parfois abusivement le kernel. C’est le socle de l’infrastructure, qui assure le transport des messages, contient l’annuaire de services, gère le routage, conserve l’état des services, etc.
  • Ensuite, il y a les composants. Les composants se déploient sur le conteneur (cette relation conteneur – composants est définie dans la spécification JBI et est équivalente à ce qu’on peut trouver avec les EJB, OSGi ou SCA). Les composants fournissent une base de code réutilisable et configurable. Ils permettent d’implémenter la logique fonctionnelle.
  • Enfin, dernier niveau, ce sont les (fournisseurs de) services et les consommateurs de services. Ceux-ci sont créés sous la forme de configurations des composants. Cela permet d’implémenter des unités logiques et de les assembler pour répondre à des besoins fonctionnels.

Un service dans Petals est identifié par 3 composantes.

  • En premier lieu, il y a ce qu’on appelle le nom d’interface. Cela correspond à un contrat technique : à minima, on y trouve une liste d’opérations et les paramètres associés. Actuellement, un tel contrat se présente sous la forme d’un WSDL. Mais au-delà des aspects techniques, un contrat correspond aussi et surtout à une fonctionnalité, que l’on va pouvoir utiliser et invoquer dans son système d’information.
  • Vient ensuite le nom de service. Un service implémente une interface donnée. Dans la pratique, cette partie permet de distinguer des implémentations différentes. Par exemple, on pourrait avoir un contrat implémenté avec du Java (serviceJava) et avoir une autre implémentation en BPEL (serviceBpel). La fonctionnalité rendue serait la même, mais les propriétés seraient différentes (ici, il y en a un qui s’exécutera plus vite que l’autre). On pourrait aussi imaginer un cas plus métier. On peut imaginer avoir un contrat de réservation de voiture, et avoir une implémentation par société de location de voitures. Ce qui différencie alors les services, ce n’est pas la technologie d’implémentation mais le fournisseur.
  • Enfin, il y a le nom d’end-point. Cela correspond à un point de déploiement.

Un service déployé dans Petals possède toujours ces 3 parties.
La relation de cardinalité est la suivante :

interface 1 – * service(s) 1 – * end-point(s)

Autrement dit, à partir de l’annuaire de services du bus, on peut construire une hiérarchie.

Si on part de ce schéma, on aurait 6 services dans l’annuaire, identifiés par 6 triplets.

  1. Reservation Contrat / Res Service 1 / edpt 1
  2. Reservation Contrat / Res Service 1 / edpt 2
  3. Reservation Contrat / Res Service 2 / edpt 1
  4. Reservation Contrat / Res Service 3 / edpt 5
  5. Reservation Contrat / Res Service 3 / edpt 3
  6. Reservation Contrat / Res Service 3 / edpt 4

Dans Petals, du point de vue d’un consommateur, on peut utiliser cet arbre pour se donner de la flexibilité lors de l’invocation.

  • Cas explicite : le consommateur donne le triplet complet. On appellera donc ce service, qui implémente ce contrat, et qui est déployé au niveau de ce end-point.
  • Cas implicite : on invoque par nom d’interface et nom de service ou juste par nom d’interface. Dans ce cas, on va naviguer dans notre arbre et nous arrêter à un niveau intermédiaire plutôt qu’à une feuille. Le chemin restant (pour sélectionner un service concret) sera choisi par le bus. Par exemple, si l’on invoque juste par nom d’interface sur notre exemple, n’importe lequel des 6 services peut être choisi par le bus.

Pour une même interface, lorsque je trouve plusieurs services correspondants, j’ai une équivalence de services. Ils rendent la même fonctionnalité. Mais il peut y avoir des propriétés différentes : soit sur les performances, soit sur le domaine métier impliqué.

Pour un même service, lorsque je trouve plusieurs end-points correspondants, j’ai une réplication de services. C’est la même implémentation, le même service, la même interface, mais ce sont des points de déploiement différents, que l’on peut utiliser pour de la haute disponibilité.

Dans le cas d’une invocation implicite, c’est donc le bus qui sélectionne les informations manquantes (nom de service, nom d’end-point). Ce choix est actuellement basé sur des critères de proximité. Petals étant distribué, on va pouvoir privilégier des services proches du consommateur ou au contraire situés sur d’autres noeuds. Si après l’application de ce premier critère, il reste de multiples candidats, alors le bus choisira de manière aléatoire le service à invoquer. On pourrait bien sûr imaginer d’autres stratégies finales, par exemple basées sur la consommation des ressources, pour choisir le service susceptible de répondre le plus vite. Mais cela n’est pas implémenté pour le moment et il n’est pas prévu que ce soit fait à court terme.

Au final, cet article visait à souligner une chose.
Petals ESB sait faire du routage fonctionnel. Mais, ce n’est pas un load balancer. La nuance est très importante lorsque l’on conçoit une architecture avec Petals. Et autant, on pourrait enrichir le module de routage d’une stratégie avec équilibrage de charges (pour ce qui transite à l’intérieur du bus), autant cela ne suffirait pas pour les interactions avec des applications externes.


Petals Studio 1.2 has been released

In: Uncategorized

27 Sep 2011

Hi,

After 3 release candidates, the third release of Petals Studio, Petals Studio 1.2, is now available for download.
It contains several enhancements related to the creation of Petals services and the configuration of Petals components. One of the most significant addition is certainly the graphical editor for EIP (Enterprise Integration Patterns). Such a tool was clearly required to ease the use of the Petals EIP component.

Here are some useful links to know more:

We are now focused on the next version, which should be a 1.3.
The schedule is not yet fixed, but we expect it to be released in the beginning of 2012, with the version 4 of Petals ESB.


Il se trouve qu’au début de l’été, j’ai eu à expérimenter certaines choses avec Petals.
Rien de révolutionnaire, mais il s’agissait de choses que je n’avais jamais tentées.

L’une d’elles concernaient l’utilisation de Petals avec des machines virtuelles. Je savais que cela était possible, plusieurs personnes l’ayant déjà fait par le passé. Cela ne m’a d’ailleurs pas pris très longtemps, mais je préfère me laisser des notes au cas où j’aurais à le refaire plus tard. Ce blog fera très bien l’affaire pour cette tâche. Et si jamais vous voulez valider le fonctionnement de Petals sur des VM, ce post pourra vous aider.

 

Installation des VM

D’abord, j’ai testé le tout sur Ubuntu (10.04 LTS).
J’ai installé VirtualBox pour émuler un deuxième hôte sur ma machine (ce deuxième hôte était une autre version d’Ubuntu dont j’avais récupérée l’image sur le net). Pour ces étapes, le mieux est de s’inspirer de la documentation assez riche sur le sujet.

http://doc.ubuntu-fr.org/virtualbox
http://www.siteduzero.com/tutoriel-3-36484-virtualisez-un-systeme-d-exploitation-avec-virtualbox.html#ss_part_2
http://videonoob.fr/tutoriel/virtualbox-installer-ubuntu
http://www.virtualbox.org/manual/ch06.html

En gros, cette étape consiste à installer dans une machine virtuelle un système d’exploitation donné.
Le principe du test, celui qui permet de vérifier le fonctionnement de Petals sur des VM, est d’avoir une topologie distribuée sur 2 noeuds : un noeud sur l’hôte courant et l’autre sur une VM (on peut aussi s’amuser à créer plusieurs VM). Dans la mesure où l’on fait du distribué, il faut que chaque VM puisse communiquer avec l’hôte courant et les autres VM. Pour cela, il faut penser à activer la bonne configuration réseau dans VirtualBox. J’avais pour ma part utilisé le mode Host-only networking de VirtualBox.

 

Installation de Petals en distribué

Une fois qu’on a nos VM, il faut maintenant installer Petals et le paramétrer pour fonctionner en distribué.
L’installation consiste à dézipper l’archive de Petals sur chaque VM. Puis on met à jour le fichier topology.xml.

<?xml version="1.0" encoding="UTF-8"?>
<tns:topology xmlns:tns="http://petals.ow2.org/topology"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://petals.ow2.org/topology petalsTopology.xsd">
	<tns:domain mode="static" name="PEtALS">
		<tns:description>The static domain configuration</tns:description>

		<!--
			defaut configuration to use MySql as centralize petals registry
			<tns:jndi>
			<tns:factory>org.ow2.petals.registry.database.RegistryInitialContextFactory</tns:factory>
			<tns:provider-url>jdbc:mysql://localhost:3306/mysql</tns:provider-url>
			<tns:security-principal>root</tns:security-principal>
			<tns:security-credentials>mysql</tns:security-credentials>
			<tns:pool-size>5</tns:pool-size> <tns:batch-size>10</tns:batch-size>
			</tns:jndi>
		-->

		<tns:sub-domain name="subdomain1" mode="master-slave">
			<tns:description>description of the subdomain</tns:description>
			<tns:container name="0" type="master">
				<tns:description>description of the container 0</tns:description>
				<tns:host>192.168.38.100</tns:host>
				<tns:user>petals</tns:user>
				<tns:password>petals</tns:password>
				<tns:webservice-service>
					<tns:port>7600</tns:port>
					<tns:prefix>petals/ws</tns:prefix>
				</tns:webservice-service>
				<tns:jmx-service>
					<tns:rmi-port>7700</tns:rmi-port>
				</tns:jmx-service>
				<tns:transport-service>
					<tns:tcp-port>7800</tns:tcp-port>
				</tns:transport-service>
				<tns:registry-service>
					<tns:port>7900</tns:port>
				</tns:registry-service>
			</tns:container>

			<tns:container name="1" type="slave">
				<tns:description>description of the container 1</tns:description>
				<tns:host>192.168.38.106</tns:host>
				<tns:user>petals</tns:user>
				<tns:password>petals</tns:password>
				<tns:webservice-service>
					<tns:port>7601</tns:port>
					<tns:prefix>petals/ws</tns:prefix>
				</tns:webservice-service>
				<tns:jmx-service>
					<tns:rmi-port>7701</tns:rmi-port>
				</tns:jmx-service>
				<tns:transport-service>
					<tns:tcp-port>7801</tns:tcp-port>
				</tns:transport-service>
				<tns:registry-service>
					<tns:port>7901</tns:port>
				</tns:registry-service>
			</tns:container>

			<!--
			<tns:container name="2" type="slave">
				<tns:description>description of the container 2</tns:description>
				<tns:host>localhost</tns:host>
				<tns:user>petals</tns:user>
				<tns:password>petals</tns:password>
				<tns:webservice-service>
					<tns:port>7602</tns:port>
					<tns:prefix>petals/ws</tns:prefix>
				</tns:webservice-service>
				<tns:jmx-service>
					<tns:rmi-port>7702</tns:rmi-port>
				</tns:jmx-service>
				<tns:transport-service>
					<tns:tcp-port>7802</tns:tcp-port>
				</tns:transport-service>
				<tns:registry-service>
					<tns:port>7902</tns:port>
				</tns:registry-service>
			</tns:container>
			-->
		</tns:sub-domain>
	</tns:domain>
</tns:topology>

Ici, j’ai une topologie de 2 noeuds, avec une relation maitre / esclave. On peut évidemment rajouter d’autres noeuds, qui seront configurés en esclave. Il n’y a qu’un maître par topologie, et celui-ci sert de référent aux autres noeuds pour synchroniser leur annuaire de services. Cela permet à chaque noeud d’être indépendant tout en étant capable de communiquer avec les autres. Un des inconvénients toutefois, c’est que le noeud maître revêt une importance plus grande que les autres. On peut cependant s’assurer de sa haute disponibilité avec un outil tel que Heartbeat. Et cela dépend aussi de la fréquence des déploiements sur la topologie. La synchronisation entre les noeuds n’est nécessaire que lors de l’installation ou la désinstallation de services sur le bus.

Une fois que l’on a défini sa topologie, on peut soit la copier dans chaque installation de Petals (dossier conf), soit la mettre sur un serveur web et faire pointer chaque noeud sur l’adresse du fichier. Cette deuxième méthode est la plus pratique en mode distribué. L’adresse est définie dans le fichier conf/server.properties de chaque noeud.

# Alternate topology configuration file URL. This value must be a valid URL like :
#  - http://localhost:8080/petals/topology.xml
#  - file:///home/petals/config/topology.xml
#  - or any valid URL (java.net.URL validation)
# If not specified, the local topology.xml file is used
petals.topology.url=http://192.168.38.106:8080/petals/topology.xml

 

Déploiement de services

Résumons…
Nous avons installé nos serveurs virtuels.
Nous avons installé Petals et l’avons configuré en distribué.

On va maintenant faire un petit test mettant en oeuvre le routage interne de Petals. Pour cela, on va déployer le composant Clock de Petals. Ce composant, véritable concentré de technologie, fournit un service qui donne l’heure. On le déploie donc sur chaque instance de Petals (chaque noeud).

Du point de vue de l’annuaire de services, on a la hiérarchie suivante :

  • Interface : Clock
  • Service : ClockService
  • End-points : edpt-1, edpt-2, …, edpt-n, où chaque edpt pointe vers un noeud Petals.

A chaque fois que l’on déploie notre composant, le même service est enregistré dans Petals. Ce service est identifié par un nom d’interface (un contrat technique, cad une liste d’opérations, chaque opération ayant des paramètres d’entrée et/ou de sortie), un nom de service (qui identifie une implémentation) et un nom d’end-point (qui identifie un point de déploiement). Comme c’est le même service qui est déployé à chaque fois, le nom d’interface et de service est le même pour chaque enregistrement. Seul change le nom d’end-point, qui est généré au déploiement (c’est un comportement par défaut de ce composant Clock).

On a donc un service à invoquer, service qui est répliqué sur chaque noeud du bus.
Il reste à l’invoquer. Pour cela, on utilise le sample client, un autre composant de Petals, qui est à la fois rustique et pratique. On le déploie une seule fois, sur l’hôte courant. Une fenêtre Swing s’ouvre (c’est le comportement du composant, lorsqu’il est démarré, il montre une petite console graphique).

Dans l’onglet Query, cliquer sur Get all the endpoints.
Tous les services du bus sont alors listés. On peut alors en sélectionner un. En mettant à jour les propriétés d’invocation, et plus exactement en n’invoquant que par nom d’interface et nom de service, on peut alors demander au bus de choisir un service qui vérifie ces critères parmi ceux disponibles. Le service finalement choisi par le bus (selon les critères fournis par le consommateur) peut être situé sur le même noeud que le consommateur ou bien être sur un autre noeud de la topologie. En fait, tout cela est transparent pour le consommateur de service (ici, le sample client).

En réitérant l’appel, on peut ainsi vérifier les capacités en distribué de Petals.
Exemple : en invoquant un service ClockService qui implémente le contrat Clock

  • Appel 1 : on tombe sur edpt-2
  • Appel 2 : on tombe sur edpt-1
  • Appel 3 : on tombe sur edpt-1 (encore).
  • etc…

A noter !

Suite à un commentaire, je me dois de préciser que le fichier server.properties du noeud sur lequel a été déployé le sample client a été modifié pour pouvoir appeler de manière aléatoire n’importe quel service de toute la topologie. Il suffit pour cela de mettre

petals.router.strategy=random,2,2,1

La configuration du routeur de Petals sera bientôt documentée sur le wiki de Petals…

Donc ici, comme il y a plusieurs services « ClockService implémentant le contrat Clock », et que l’invocation ne spécifie pas le end-point à appeler, alors c’est le bus qui le choisit pour nous. En cas d’équivalence de service, le choix est effectué de manière aléatoire. D’autres stratégies pourraient être utilisées, comme un round-robin, la qualité de service ou basé sur la consommation des ressources. Cependant, ces autres stratégies ne sont pour le moment pas implémentées.

On peut aussi suivre et visualiser les appels avec la web console de Petals.
Je ne l’ai pas fait ici, mais pour les curieux, il y a un guide de démarrage pour Petals qui contient entre autres des exercices avec la web console.

 

Au sujet de la synchronisation…

J’ai dit plus haut qu’en distribué, le noeud maître servait de référent pour synchroniser les annuaires de services. Cette synchronisation est périodique et configurée dans le fichier server.properties de chaque noeud esclave. Lorsque l’on déploie un service, il faut donc attendre que la période se soit écoulée pour que le service déployé soit visible depuis les autres noeuds.

Cependant, il est possible de forcer une synchronisation, soit avec JMX, soit en mode console (option de démarrage avec Petals 3.x, et possibilité d’utiliser une console externe, que l’on appelle Petals-CLI, et qui sera promue avec la version 4 de Petals ESB).


As I am working on trying to build SWTBot with Tycho, I find out a mistake that is quite common with SWTBot and that makes test failing with Tycho whereas they work with some more “opaque” builders.

When you write a UI test, your test does depend on UI components you use. This dependency is specific to your test bundle, and then must be explicitly defined in your MANIFEST.MF. For example, if your test will click on the “New > Java Project” menu, so it highly depends on org.eclipse,jdt,ui, which provides this contribution. Then do not forget to add this in your dependencies!

A bit easier than "Where is Waldo"

It can work in some cases when you are sure your test platform already contains the contribtutor of the UI elements you manipulate (here org.eclipse.jdt.ui) . Then the menu is already there – as a 3rd party contribution-, although you did not add the dependency to it in your test. But that’s more or less a lucky case, or a case that requires rigorous management of your test platform.

With Tycho, your test platform is, by default, made of your test bundle and all its dependencies (computed from MANIFEST.MF). Then if you don’t explicit your dependencies to UI contributions, your test will probably run in a target platform which does not include the UI elements you interact with, and will fail. When you have this depedency to the UI contributor (such as org.eclipse.jdt.ui) in your test MANIFEST.MF, you are sure you’ll have the menu available whenever you execute your test. Moreover, you are sure that all installation of your test bundle with p2 will contain the necessary stuff to get it working.

To sum it up: If your test depends on UI elements, then it depends on plugins that contribute these UI elements. So tell it in its MANIFEST.MF. That’s all!


I have recently been really pleased to see that I was accepted as a speaker for the SoftShake conference, that takes place in Geneva on the 3rd and 4th of October. It will be a great opportunity to meet new people, to learn about new trendy technologies and methodologies, but also to teach to the audience the basic issues of Modeling, and how the Eclipse Modeling project is there to help them. The abstract of the 50 minutes session can be found here: http://soft-shake.ch/en/conference/sessions.html?key=modelingwitheclipse . If you plan to attend this presentation and if you have any topic you’d like to hear about, then feel free to ask, I’ll try to cover this specific subject during the presentation.

The "SoftShake speaker badge"

I am very excited by this presentation since I think Modeling is something very productive and powerful, and I know how helpful are the tools provided by Eclipse. It is the first time I have the opportunity to democratize Modeling, Model-Driven Stuff and Eclipse Modeling Project in a conference! However, this requires a lot of work to prepare a good presentation, but that’s a work I love to do.

On a site note, my PetalsLink colleague Jean-Christophe Reigner was also accepted as a speaker. He will democratize the usage of ESB: what use-cases it resolves, what is its role in your SI and so on. That should be also quite interesting since ESB are very powerful and scalable middlewares and most people don’t get the actual value yet. So if you are interested in SOA, System of Informations, Middleware, ESB and so on, you should for sure come to see his talk, you’ll definitely learn interesting things.


Story, code, compare

Yet another ‘nightly project’ (thanks to current house build project and the lack of sleep it brings). This time I needed to be able to manage the so-famous Service Bus from some Web enabled tooling. I already developed such tool in a research project but the fact is that the licence of some libraries are not compatible with the petalslink open source approach. The second thing is that it is GWT based (which bores me, has almost 100 libraries dependencies and takes 10 minutes to compile). So this application is a good candidate to compare development productivity between GWT and the Play Framework. Here is a summary of the application creation:

  • I bootstraped the application yesterday during lunch between 1PM and 2PM. I was already able to invoke most of the interesting service bus actions with the help of service bus SOAP API.
  • I added some pages and actions last night, let say that since it was between 11PM and 1AM I was not very productive…
  • I fixed some bugs this morning

As a result, I think I worked around 3 hours on this application. I think I spent one hour to resolve a dependency conflict between Play and a CXF dependency but as a result I have a good result which is almost equivalent in functionality to the GWT based application. I still miss some operations but I do not need them for now… I feel ashamed to say how long it tooks me to create the GWT version…

Deploy

Let’s talk about deployment… I did not have time to play with heroku to push this application in the cloud. Tis will be a future step but since I use Play and git, I am able to push the code to github and then pull it on an OVH server I rent. I am able to provide this instance for some project partners if they want to manage the service bus. The time it took? 5 minutes (wget play, git clone and play start…).

Code

The Play enabled application is available on github at chamerling/dsbmanager-webapp.


Classé dans:Java Tagged: Application programming interface, dsb, esb, GitHub, Google Web Toolkit, Java, PEtALS, petalslink, Play Framework, Service Bus, SOA, soap

Welcome

Archives

Categories

Latest Tweets

Page 5 of 33« First...34567102030...Last »