Tip : Conversion de durée en Java


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.

Librairie cliente pour Petals ESB


Avoir un Bus de services basé sur la spécification JBI c’est bien. Pouvoir le manager avec l’API JMX qui est définie dans le spécification c’est aussi pas mal, mais pouvoir le manager un utilisant des protocoles un peu plus ‘Internet-friendly’ et avec une librairie Java c’est encore mieux. Dans cet article, je vais présenter rapidement comment utiliser la librairie cliente qui est disponible depuis que Petals ESB fournit une API Web service ie depuis la version 3.0.

Le cas d’usage

Petals ESB est pleinement basé sur JBI est ne fournit pas forcément une API permettant d’exposer des services simplement. On pourrait imaginer avoir une API de management du style ‘bind(wsdlURI)’ où wsdlURI est l’URI du WSDL du service à lier au bus. La distribution de base ne fournissant pas ce genre d’API, il faut contourner cette lacune par l’utilisation de JBI et des APIs de management à distance.

La pratique et le code

Je passe sur la génération de Service Units et de Service Assemblies (des articles sont disponibles sur mon blog pur le faire avec des librairies Java ou avec le Petals Studio). Imaginons que nous ayons généré tout les artifacts JBI nécessaires coté client et que tous les composants JBI sont déjà installés sur le Bus. Comment soumettre ma SA au bus, et comment gérer son cycle de vie à distance?


package net.chamerling.blog.petalsclient;

import java.io.File;

import javax.activation.DataHandler;
import javax.activation.FileDataSource;

import org.ow2.petals.kernel.ws.api.DeploymentService;
import org.ow2.petals.kernel.ws.api.PEtALSWebServiceException;
import org.ow2.petals.kernel.ws.api.to.AttachmentDescriptor;
import org.ow2.petals.kernel.ws.client.PetalsClient;
import org.ow2.petals.kernel.ws.client.PetalsClientFactory;

/**
 * Sample which is using the petals-kernel-wsclient library
 *
 * @author chamerling
 *
 */
public class App {

	public static void main(String[] args) {

		try {
			// get a client
			PetalsClient client = PetalsClientFactory.getInstance().getClient(
					"http://localhost:7600/petals/ws", 20000);

			// 'upload' the SA in the artifact repository
			File saFile = new File("sa.zip");
			AttachmentDescriptor ds = new AttachmentDescriptor();
			ds.setAttachment(new DataHandler(new FileDataSource(saFile)));
			client.getArtifactRepositoryService().addArtifact(ds);

			// Deploy the SA and start it
			String saId = "my-sa-id";
			DeploymentService dClient = client.getDeploymentService();
			dClient.deploy(saId);
			dClient.start(saId);

		} catch (PEtALSWebServiceException e) {
			e.printStackTrace();
		}
	}
}

Tout est dans le code :

  1. La SA est déposée dans le répertoire géré par le service d’artifact (par défaut, sous PETALS_HOME/artifacts/)
  2. La SA est déployée depuis le répertoire cité en 1
  3. La SA est démarrée.

Le code de l’exemple est disponible dans mon projet googlecode sous http://code.google.com/p/chamerling/source/browse/trunk/blog/petals-ws-client

Les classloaders des modules dans Axis2: Les ressources


J’ai expliqué le genre de choses intéressantes que l’on peut faire avec les modules dans la pile Apache Axis2 dans l’article sur le reroutage d’appels de services. J’ai eu besoin aujourd’hui d’aller un peu plus loin dans l’utilisation de ces modules et comme d’habitude, en utilisant ce genre de choses, je partage mes aventures… On va voir rapidement ici comment se comportent les ClassLoaders dans le cas d’Axis2 et des modules.

Et alors?

Je suis en train de développer un module qui reroute les appels de service. L’adresse du service à appeler est donc mis à jour lors de la traversée du module en question. Pour faire bête, je me suis dit que j’aller spécifier un jeu d’adresses dans un bon vieux fichier de propriétés et que j’allais mettre ce fichier dans le module. OK, c’est bien, ça marche (heureusement…), je peux charger mon fichier dans le Handler du module et utiliser les adresses qui y sont définies.

Ce qui m’embête, c’est que ce fichier est packagé dans l’archive du module et donc non modifiable à souhait… C’est là que le Classloader d’Axis2 entre en piste. Si je mets un fichier avec le même nom dans les ressources de mon code client, celui ci est pris en compte en priorité lors de l’appel par le module de MonModule.class.getResource(« /foo.properties »); Je peux donc cette fois ci livrer un module générique qui inclus des valeurs par défaut et les clients qui utilisent ce module peuvent ‘overrider’ les valeurs par défaut dans leur propre fichier de configuration.

Encore une fois, merci Axis2.

L’acheminement de messages dans Petals ESB : #2 Le routage


Intro

Dans l’article précédent sur l’acheminement de messages dans Petals ESB, j’introduisais les notions, aujourd’hui nous allons regarder en détails la couche de routage du bus. Cette couche est largement appelée Router par les développeurs du Bus, et le sera donc dans cette article et dans la suite de la série.

L’archi simplifiée

L’architecture du Router utilise la notion très répandue et  fort utile de modules ie le Router invoque séquentiellement une liste de modules pour élire les services à appeller. A la fin de la traversée on se retrouve avec toutes les informations nécessaires pour appeler les services. On peut modifier cette liste en ajoutant ou supprimant des modules par configuration. Un schéma simplifié donne un Router avec cette tête :

Plus de détails sur l’utilisation des modules dans Petals et leur injection dans un vieil article (à non pas si vieux…).

L’implémentation

L’implémentation de base de Petals ESB est composée de 2 modules en émission :

  1. Le module qui interroge le registre de services et retourne une liste de point d’accès (endpoint dans le jargon service) en fonction des informations contenues dans le message d’entrée.
  2. Le module de résolution de la couche de transport. En fonction de la localisation des endpoints trouvés par le module précédent, un contexte est créé pour définir la couche de transport à utiliser (cette couche de transport sera détaillée dans le prochain article de la série).

On peut imaginer un grand nombre d’utilisations de ces modules. Personnellement, je les utilise à outrance par exemple pour :

  • Ajouter des informations de timestamp sur les messages
  • Notifier une couche de monitoring que des messages sont échangés entre consommateurs et fournisseurs de service
  • Logger les appels
  • Mettre à jour le choix de la couche de transport avec ma propre implémentation du transport de messages inter container

Outro

Vous en savez un peu plus sur le routage dans le bus de service Petals. il faut vraiment retenir que cette couche est vraiment extensible et customisable sans grand effort, en effet pas besoin de recompiler le coeur de Petals pour ajouter des fonctionnalités pour la résolution des endpoints. Dans le prochain article de la série, nous regarderons de plus prêt comment sont échangés les messages entre les instances de Petals.

L’acheminement de messages dans Petals ESB : #1 L’intro


L’intro

Je commence ici une petite série d’articles sur l’acheminement  de messages dans Petals ESB pour décrire d’abord simplement et par la suite plus techniquement (avec du code ) comment le message se balade dans le bus de services lors de l’invocation de services. Cette invocation passe par plusieurs étapes, qui sont ‘customisables’ et extensibles facilement pour répondre à des besoins distincts, on verra cette partie plus tard…

Le blahblah

On le dit depuis la première version de Petals ESB, Petals est Le bus de services distribué qui implémente la spécification JBI. Ici distribué signifie que des instances du bus de service sont lancées sur des hotes distincts et que du point de vue de l’utilisateur, cela est totalement transparent ie l’utilisateur n’a rien à configurer de plus qu’un fichier de description du réseau (contrairement aux concurrents où l’on doit généralement configurer des composants JBI pour exposer des services). On ne se place pas ici à un transport de messages au niveau applicatif mais vraiment à un niveau (abstrait) de transport. Pour être plus clair, l’architecture de Petals ESB est divisée en couches et pour faire simple on a :

  1. Le canal de communication. Le canal de communication est la couche d’accès utilisée au niveau des composants JBI et donc au niveau des consommateurs et fournisseurs de services. Lors de l’invocation d’un service, le composant qui invoque un service envoi un message au canal. Le canal possède aussi tout un jeu de ‘listeners’ qui permettent de recevoir des messages de la couche de niveau N-1 (ie la couche de routage) en mode fournisseur de services.
  2. La couche de routage. En mode consommateur de service, cette couche reçoit le message du canal de communication et est chargé de trouver le point d’accès (endpoint) à qui le message doit être envoyé. Cet endpoint peut être local ou distant (sur un autre instance de Petals ESB). Elle permet aussi une remontée du message vers le bon canal de communication et donc vers le bon fournisseur de service en mode fournisseur.
  3. La couche de transport. Cette couche reçoit le message et le endpoint auquel le message doit être envoyé. Elle envoi ce message au endpoint, qu’il soit local ou distant. La couche de transport gère bien sûr la réception des messages envoyés depuis les instances distantes pour l’invocation des services qui se trouvent sur l’instance locale.

La suite

Dans les prochains articles, je détaillerais les couches de routage et de transport, leurs features, leurs points d’extensions, etc, etc… Et avec peu de code, on verra que l’on peut customizer Petals ESB.