Petals planet

Extensions de Petals ESB : LifeCycleListener

Christophe — Fri, 12 Mar 2010 15:39:53 +0000

Petals ESB offre des possibilités d’extensions assez impressionnantes venant du fait que l’on utilise le Framework à composants Fractal (bon c’est pas Spring mais on peut faire des choses intéressantes avec des produits issus de la recherche). Dans cet article je vais m’intéresser à la customisation du démarrage et de l’arrêt de Petals en proposant une extension sympa et ce sans modifier énormément le code du kernel de Petals (Ca peut aussi servir de tutorial Fractal pour les débutants…).
Pourquoi? Parce-que actuellement pour moi Petals ESB est le framework SOA que j’étends pour lui ajouter des fonctionnalités qui ne sont pas fournies par défaut. La fonctionnalité du jour doit me permettre d’attendre que tous les composants par défaut soit démarrés pour démarrer les miens : Je dois installer des composants JBI (ne marchera pas si je laisse Fractal les installer trop tôt), lier des services (ne marchera pas si mes composants ne sont pas installés et si le service de management de Petals n’est pas démarré), lancer des tâches de fond, etc…

l’API du kernel de Petals propose l’interface org.ow2.petals.kernel.api.server.PetalsStateListener :

package org.ow2.petals.kernel.api.server;

/**
 * Listener notified when a Petals container finish to start or to stop.
 */
public interface PetalsStateListener {

    /**
     * Callback method on PEtALS start up
     */
    void onPetalsStarted();

    /**
     * Callback method on PEtALS stop
     *
     * @param success
     *            {@code true} if PEtALS has stopped successfully
     * @param exception
     *            the exception if the stop has failed, {@code null} otherwise
     */
    void onPetalsStopped(boolean success, Exception exception);
}

Cette interface n’est malheureusement utilisée que statiquement et une seule fois pour informer le ‘launcher’ que le kernel est bien démarré. On a pourtant org.ow2.petals.kernel.api.server.PetalsServer qui définit la méthode addPetalsStateListener(PetalsStateListener). je vais donc utiliser cette API et modifier simplement l’implémentation de org.ow2.petals.kernel.api.server.PetalsServer pour ajouter des listeners qui seront appelés lors du démarrage et de l’arrêt de Petals.
Pour ce faire deux approches sont possibles :

Rechercher tous les composants Fractal qui implémentent org.ow2.petals.kernel.api.server.PetalsStateListener
Créer un manager qui contient une liste ordonnée de tous les org.ow2.petals.kernel.api.server.PetalsStateListener

On va ici se pencher sur la solution 2 car la solution 1 ne permet d’ordonner facilement les listeners à appeler (ca peut valoir le coup de les appeler dans un sens bien définit!).
1/ Le manager de listeners
Simplement un composant Fractal qui détient la liste des listeners définis. Ces listeners sont définis par configuration dans les fichiers ADL de Petals. Son interface :
package foo.bar.petals.kernel.listener;

import java.util.Set;

import org.ow2.petals.kernel.api.server.PetalsStateListener;

/**
 * @author chamerling - eBM WebSourcing
 *
 */
public interface LifeCycleListenerManager {

    /**
     * The binding prefix of the component which is listening petals state
     */
    static final String PREFIX = "petals-state-listener-";

    /**
     * Get an ordered set of listeners
     *
     * @return
     */
    Set getListeners();

}

et son implémentation :
package foo.bar.petals.kernel.listener;

import java.util.HashSet;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;

import org.objectweb.fractal.fraclet.annotation.annotations.FractalComponent;
import org.objectweb.fractal.fraclet.annotation.annotations.Interface;
import org.objectweb.fractal.fraclet.annotation.annotations.LifeCycle;
import org.objectweb.fractal.fraclet.annotation.annotations.Monolog;
import org.objectweb.fractal.fraclet.annotation.annotations.Provides;
import org.objectweb.fractal.fraclet.annotation.annotations.Requires;
import org.objectweb.fractal.fraclet.annotation.annotations.type.Cardinality;
import org.objectweb.fractal.fraclet.annotation.annotations.type.Contingency;
import org.objectweb.fractal.fraclet.annotation.annotations.type.LifeCycleType;
import org.objectweb.util.monolog.api.Logger;
import org.ow2.petals.kernel.api.server.PetalsStateListener;
import org.ow2.petals.util.LoggingUtil;

/**
 * @author chamerling
 *
 */
@FractalComponent
@Provides(interfaces = { @Interface(name = "service", signature = LifeCycleListenerManager.class) })
public class LifeCycleListenerManagerImpl implements LifeCycleListenerManager {

    @Monolog(name = "logger")
    private Logger logger;

    private LoggingUtil log;

    @Requires(name = PREFIX, signature = PetalsStateListener.class, cardinality = Cardinality.COLLECTION, contingency = Contingency.OPTIONAL)
    private final Map listeners = new Hashtable();

    @LifeCycle(on = LifeCycleType.START)
    protected void start() {
        this.log = new LoggingUtil(this.logger);
        this.log.debug("Starting...");
    }

    @LifeCycle(on = LifeCycleType.STOP)
    protected void stop() {
        this.log.debug("Stopping...");
    }

    /**
     * {@inheritDoc}
     */
    public Set getListeners() {
        HashSet result = new HashSet();
        if (this.listeners != null) {
            Iterator iter = this.listeners.keySet().iterator();
            while (iter.hasNext()) {
                String key = iter.next();
                Object o = this.listeners.get(key);
                if (o instanceof PetalsStateListener) {
                    result.add((PetalsStateListener) o);
                } else {
                    // warning
                    this.log.warning(o + " is not an instance of "
                            + PetalsStateListener.class.getCanonicalName());
                }
            }
        }
        return result;
    }
}

A noter que la Map ‘listeners’ est remplie par Fractal au démarrage de Petals.
2/ Modification de PetalsServerImpl
Dans org.ow2.petals.kernel.server.PetalsServerImpl je rajoute la méthode initListeners() :
   private void initListeners() {
        // get the component which owns the listeners
        Component listenerManagerComponent = FractalHelper.getRecursiveComponentByName(
                this.petalsContentController, Constants.FRACTAL_LISTENERS_MANAGER);
        if (listenerManagerComponent != null) {
            try {
                LifeCycleListenerManager manager = (LifeCycleListenerManager) listenerManagerComponent
                        .getFcInterface("service");

                if (manager != null) {
                    Set listeners = manager.getListeners();
                    for (PetalsStateListener petalsStateListener : listeners) {
                        this.addPetalsStateListener(petalsStateListener);
                    }
                } else {
                }
            } catch (Exception e) {
            }
        }

    }

Ce code permet de retrouver mon ‘listener manager’ (puisque PetalsServerImpl n’est pas ‘Fractalisé’) et de remplir la liste des listeners. Allez maintenant, on va dire que j’appelle cette méthode d’initialisation juste avant d’appeler les listeners (dans start() de PetalsServerImpl):
    public void start() throws PetalsException {
        // get listeners which have been defined by configuration (Fractal)
        this.initListeners();

        // notify the listener if there is one
        for (PetalsStateListener petalsListener : this.petalsListeners) {
            petalsListener.onPetalsStarted();
        }
    }

3/ Configuration des listeners
Dans les fichiers de définition des composants Fractal, je peux maintenant instancier mes listeners et les ajouter à la liste des listeners gérée par le manager de listeners :
	
	
	

	
	

	
	
	

Le composant foo.bar.petals.kernel.*Listener implémentent  org.ow2.petals.kernel.api.server.PetalsStateListener et sont ajoutés à la liste des listeners managés par LifeCycleListenerManagerImpl lors de la définition des liens (lignes ‘binding’). Tous les listeners ajoutés au manager doivent avoir une valeur de l’attribut client commençant obligatoirement par LifeCycleListenerManagerImpl.petals-state-listener- (remplissage de la Map par Fractal).
Facile et pratique, non?!

Mapping WSDL JBI

Christophe — Thu, 11 Mar 2010 12:52:03 +0000

Cet article fait suite à une question récurrente des utilisateurs de Petals ESB : « Pourquoi j’ai une erreur au déploiement de mon service??? ». Je vais ici tenter de donner une réponse partielle à cette question car il peut y avoir beaucoup de raisons à une erreur de déploiement. La plus courante venant souvent de la configuration. Rien que bien technique ni compliqué dans cet article, juste un mini tutoriel pour mieux comprendre la philosophie Petals – JBI.

La spécification JBI est basée sur l’état de l’art des Web services et donc utilise WSDL pour la description des services ‘hostés’ ou liés à l’implémentation JBI. Petals ESB implémente (et étend – mais ça sera peut être l’objet d’un autre article sur le pourquoi du comment…) la spécification JBI depuis sa première version. Petals ESB est même certifié compatible JBI par SUN (RIP) après le passage du TCK JBI (Outil de test de compatibilité fournit par SUN). Bref, là n’est pas la question… Les descripteurs JBI servent à beaucoup de choses dans une implémentation JBI mais nous allons particulièrement regarder comment nous nous en servons dans l’exposition de services.

Un service exposé dans le bus fournit donc sa description via un WSDL associé. Ce service est activé dans le bus après le déploiement de ce que l’on appelle communément une ‘SA’ (Service Assembly) qui contient des ‘SU’ (Service Unit). Pour exposer un service dans le bus afin qu’il soit accessible à tout les consommateurs, la SU doit être en mode ‘provide’ ie fournisseur. Elle doit aussi définir le Endpoint, le Service et l’Interface qu’elle veut exposer. Prenons l’exemple du bon vieux service HelloWorld définit par le WSDL suivant :

Son descripteur JBI associé sera donc (lié a Petals via le composant Web service dans cet exemple) :




	
		

			
			60000
			Service.wsdl

			
			http://localhost:9999/sample/HelloService
			11
			false
			false
			true
			SOAP

Où on respecte bien que :

JBI ‘endpoint-name‘ = Valeur de l’attribut ‘name’ du Port dans le WSDL
JBI ‘service-name‘ = Valeur de l’attribut ‘name’ du Service dans le WSDL (avec JBI Service NameSpace = targetNamespace du WSDL)
JBI ‘interface-name‘ = Valeur de l’attribut ‘name’ du PortType dans le WSDL (avec JBI Interface NameSpace = targetNamespace du WSDL)

Petals ESB v3.x ne vous insultera plus lors du déploiement de vos services. Une solution simple pour ne pas se faire insulter, est d’utiliser le Studio Petals qui facilite grandement la vie des développeurs!

Permgen Space with Eclipse

Vincent Zurczak — Wed, 10 Mar 2010 13:35:23 +0000

Hi,

If you develop Eclipse plug-ins, you are always brought to run an Eclipse application.
It means that to test your plug-ins, you have to launch a second Eclipse from the one where you develop.

One common problem in this case is the PermGen Space issue.
This is in particular true if you test GMF plug-ins or if there is a lot of class generation.

To solve this, you can modify the permgen space allocated when you run the other Eclipse.
Go into Run > Debug Configurations. Select your Eclipse configration and go into the Arguments tab.
The field to upate is the VM Arguments.

As an example, when running Talend Open Studio in debug, I have to use the following settings.

-Xms256m -Xmx1024m -XX:MaxPermSize=512m

Axis2 : Rerouter vos appels de services sans modifier vote code client

Christophe — Tue, 09 Mar 2010 16:08:14 +0000

Imaginons que vous ayez à votre disposition un client de Web service et que pour une raison (qui doit être bonne je l’accorde), vous avez besoin de rerouter vos appels de service vers un nouveau point d’accès. Le problème est que vous n’avez pas le droit de modifier le code client (ou que vous ne l’avez pas), que vous ne voulez pas regénérer ce code client à partir du WSDL du nouveau service a appeler (qui est exactement le même hormis l’adresse du endpoint)… Heureusement, votre client utilise la pile Web service Apache Axis2, et les développeurs d’Axis2 ont gentiment pensé à introduire des modules dans leur architecture. Une bonne intorduction aux modules est disponible dans le guide d’architecture d’Axis2.

Nous allons donc développer un module qui change dynamiquement l’URL de l’endpoint à appeler (on utilisera bien sûr Maven2 pour nous aider à créer et packager le projet…).

1. Créer le projet

Utilisons Maven2 pour créer un projet :

mvn archetype:generate

et je réponds bêtement a Maven quand il me pose des questions sur le groupId, l’artifactId, etc… Une fois créé, je génère le projet Eclipse associé et je l’importe (Eclipse fait aussi parti de mes grand amis) :

mvn eclipse:eclipse

Ill faut modifier le POM pour dire a Maven que l’on est en train de créer un projet qui n’est pas une librarie Java mais un module Axis2. Ceci est possible en spécifiant le type de projet dans le POM et en déclarant que l’on veut utiliser le plugin MAR fournit par Axis2 :




...

foo.bar
reroute
1.0-SNAPSHOT
mar

...



org.apache.axis2
axis2-kernel
1.5.1



...




org.apache.axis2
axis2-mar-maven-plugin
1.5.1
true

src/main/META-INF/module.xml
false




...

2. Business code

Créons maintenant notre handler (le module est en fait un handler Axis2 packagé dans une archive avec un descripteur de module). Pour faire simple, je vais étendre la classe AbstractHandler pour créer mon Handler de reroutage et remplacer le ‘target EPR’ par le nouveau (bien sûr on peut faire quelque chose de beaucoup plus évolué, on va dire qu’ici tout part vers un seul service) :

package net.chamerling.blog.axis2module.reroute;

import org.apache.axis2.AxisFault;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.context.MessageContext;
import org.apache.axis2.handlers.AbstractHandler;
import org.apache.axis2.util.LoggingControl;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * @author chamerling
 *
 */
public class ReRouteHandler extends AbstractHandler {
	private static final Log log = LogFactory.getLog(AbstractHandler.class);

	private static final String FINAL_EPR_PREFIX = "http://localhost:8082/petals/proxy/";

	/**
	 * {@inheritDoc}
	 */
	public InvocationResponse invoke(MessageContext messageContext)
			throws AxisFault {
		EndpointReference toEPR = messageContext.getOptions().getTo();
		String finalEPR = FINAL_EPR_PREFIX + toEPR.getAddress();

		if (LoggingControl.debugLoggingAllowed && log.isDebugEnabled()) {
			log.debug("Reroute Handler for message : "
					+ messageContext.getMessageID());
			log.debug("Initial ToEPR is " + toEPR.getAddress()
					+ " and is changed to " + finalEPR);
		}

		toEPR.setAddress(finalEPR);
		return InvocationResponse.CONTINUE;
	}
}

Avec Axis2 c’est ‘facile’, tout est dans le message context! Je viens de remplacer le service à appeler par le mien en modifiant le champ ‘address’ du ‘EndpointReference’.
3. Packager le module
Pour créer un module avec le Handler que l’on vient de définir, il faut passer par l’écriture du fichier de description du module, le ‘module.xml’. Ici c’est simple :

	
		
			
		
	


Mon module s’appellera donc ‘reroute’ et sera appelé que lors de la phase d’émission de message ‘OutFlow’. Plus d’informations sur ce qui est possible avec ce fichier sur le site d’Axis2.
4. Configurer Axis2
Il y a plusieurs façcons de dire à Axis2 d’utiliser le module que l’on vient de développer. En se basant sur la contrainte de départ, je n’ai pas le droit de modifier mes services donc je ne peux pas modifier le descripteur de service ’service.xml’. Heureusement, j’ai accès au serveur et je peux modifier le fichier de configuration d’Axis2 ‘axis2.xml’ :
...


...

	
	
	
	
	
	
	
	
	


Je viens d’engager mon module pour tous les services et je l’ai aussi ajouté dans la collection de phases qui est appelé lors de l’émission d’un message. A chaque fois qu’un message est envoyé vers un service, on passe donc dans le module que l’on vient de développer. Je viens donc de modifier les services invoqués sans modifier le code client! Je reviendrais bientôt sur l’utilisation de ce genre de choses dans un vrai cas d’usage avec du REST, du SOAP, des PROXYs, de l’ESB distribué sur le Web (bien sûr avec Petals ESB), etc…
Resources
Le code de ce ‘tutoriel’ est bien sûr disponible sur mon Google Code sous http://code.google.com/p/chamerling/source/browse/#svn/trunk/blog/reroute-axis2.

Maven2 : Deployer ses artefacts sur un repo alternatif en FTP ‘a la mano’

Christophe — Mon, 08 Mar 2010 10:24:00 +0000

Le besoin du jour : « J’ai des artefacts packagés avec Maven2 et je dois les partager avec des partenaires sans passer par un déploiement standard de mon projet mais en passant par un serveur FTP ». En plus, en terme de contrainte majeure, je ne veux absolument pas modifier mes bon vieux POMs…

Bon, comme je le dis souvent « Google est ton ami », mais aujourd’hui Google ne l’est pas (comme le temps dehors, de la neige en Mars a Montpellier, mais ou va-t-on?). Bref, faisons le bêtement :


mvn deploy -DaltDeploymentRepository=chamerling.maven.snapshot::default::ftp://ftpperso.free.fr/maven/repository/snapshot

Je viens de dire a Maven2 de déployer mon artefact sur un repository dont l’ID est chamerling.maven.snapshot (pour rappel, cela veut dire que Maven2 va aller chercher dans mon settings.xml un serveur dont l’ID est chamerling.maven.snapshot pour récupérer le login et le mot de passe) en FTP sur l’URL ftp://ftpperso.free.fr/maven/repository/snapshot. Et c’est la que mon autre ami Maven2 (bon OK je n’ai que des amis virtuels…) me dit :


[INFO] Error retrieving previous build number for artifact 'foo:bar:pom': repository metadata for: 'snapshot foo:bar:1-SNAPSHOT' could not be retrieved from repository: chamerling.maven.snapshot due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp
Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagonftp.

Ok bon c’est normal… Wagon est la librairie de transport abstraite utilisée par Maven2 et par défaut FTP n’est pas supporté. D’ailleurs sur le site du plugin deploy de Maven2 on remarque bien qu’il faut normalement définir dans le POM que l’on veut utiliser l’extension FTP de Wagon :






org.apache.maven.wagon
wagon-ftp
1.0-beta-6

Oui mais moi je ne veux pas modifier mon POM! L’astuce c’est de rajouter l’extension FTP-Wagon dans le classpath de Maven2 ie ajouter la librairie Wagon FTP dans M2_HOME/lib et la ‘Oh Miracle’, ca ne marche pas…


[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

[INFO] Error retrieving previous build number for artifact 'foo:bar:pom': repository metadata for: 'snapshot foo:bar:1-SNAPSHOT' could not be retrieved from repository: chamerling.maven.snapshot due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp
org.apache.commons.net.ProtocolCommandListener
[INFO] ------------------------------------------------------------------------

Normal, Wagon FTP utilise commons-net pour tout ce qui est communication, j’ajoute donc le JAR de commons-net 2.0 dans mon M2_HOME/lib et là ça marche beaucoup mieux :


[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Comment utiliser le SE-POJO (en 1 leçon)

gibello — Mon, 01 Mar 2010 15:41:10 +0000

Avez-vous entendu parler du SE-POJO ?

Son principal avantage : pouvoir assez simplement scripter en java des traitements internes à Petals, éventuellement complexes. Par exemple :

Consommer des Endpoint, les orchestrer librement en fonction de conditions.
Faire des traitements spécifiques (comme lire un fichier à un format exotique, le convertir en XML, et l’envoyer à un autre Endpoint)
Etc…

Le problème, c’est que le POJO est assez peu documenté, à ce jour : la doc est quand même utile, donc lisez-là (http://download.forge.objectweb.org/petals/petals-se-pojo-2.0.2-en.pdf).

Etape 1 : Développer un POJO compatible avec Petals et le SE-POJO

Sous PetalsStudio :

- Créer un projet java “classique”, qui contiendra le code de votre POJO. Ce projet aura besoin de librairies de Petals, notamment celles du CDK (component development kit).

Le meilleur moyen de se les procurer, c’est de dézipper un composant : par exemple, téléchargez le SE-POJO (de toutes façons, vous en aurez besoin), et dézippez-le.

Les librairies dont vous aurez besoin sont les suivantes ([version] désigne les numéros de version, qui peuvent varier… selon la version ! Prenez celles qui sont dans votre composant POJO) :

petals-jbi-[version].jar
petals-cdk-jbidescriptor-[version].jar
petals-cdk-api-[version].jar
petals-cdk-core-[version].jar

Copiez ces librairies dans un répertoire de votre projet java (par exemple, un répertoire “lib/”), et faites pointer le “Build path” d’Eclipse dessus.

- Créez un package et une classe dans les sources : ce sera l’implémentation de votre POJO.

Voici un exemple (cet exemple consomme un autre EndPoint : dans mon cas, un “FileTransfer” pour enregistrer le message, soit une SU déployée sur le BC-FILETRANSFER. Mais vous pouvez commenter tout le code qui consomme cet Endpoint, et vous contenter d’un POJO genre “Hello world” !) :


package org.ow2.petals.test;

import java.io.StringReader;

import javax.jbi.component.ComponentContext;
import javax.xml.namespace.QName;
import javax.xml.transform.stream.StreamSource;

import org.ow2.petals.component.framework.api.Message.MEPConstants;
import org.ow2.petals.component.framework.api.message.Exchange;
import org.ow2.petals.component.framework.jbidescriptor.generated.Consumes;
import org.ow2.petals.component.framework.listener.AbstractJBIListener;

public class TestPojo {
  AbstractJBIListener jbiListener;
  ComponentContext ctx;

  public void setJBIListener(AbstractJBIListener jbiListener) {
    this.jbiListener = jbiListener;
  }
  public void setComponentContext(ComponentContext ctx) {
    this.ctx = ctx;
  }

  public boolean onExchange(Exchange exchange)
  throws Exception {

    // Consume a "provides" endpoint (referenced by Interface/Service/Endpoint name,
    // as specified in the "provides" endpoint's jbi.xml)
    Consumes ep = new Consumes();
    ep.setInterfaceName(new QName("http://petals.test.com", "WriteContentInterface"));
    ep.setServiceName(new QName("http://petals.test.com", "WriteContent"));
    ep.setEndpointName("TestFileEndpoint");

    System.out.println("POJO: before consume");
    Exchange out =
       jbiListener.createConsumeExchange(ep,MEPConstants.IN_ONLY_PATTERN);
    out.setInMessageContent(
       new StreamSource(new StringReader(
         "Hello from Pojo !")));

    jbiListener.sendSync(out);
    System.out.println("POJO: consume done");

    // Answer if needed (In[Optional]Out)
    if(exchange.isInOutPattern() || exchange.isInOptionalOutPattern()) {
      System.out.println("POJO: sending response");
      exchange.setOutMessageContent(
         new StreamSource(new StringReader("Ok")));
    }

    return true;
  }

  public void init() {
    System.out.println("SamplePojo inits.");
  }
}

- Une fois votre POJO prêt, vous devrez le packager sous forme de fichier .jar (File/Export/General/Java/Jar file).
Le fichier .jar résultant pourra ensuite être intégré à votre SU POJO.

Etape 2 : Créer la SU pour y intégrer votre POJO

Sous PetalsStudio : File / New / Project / Petals / Use a Petals Technical Service / Use POJO.

Dans la fenêtre “WSDL File” (etc…)

Spécifiez des “namespace” identiques pour l’interface et le service (çà doit ressembler à des URL… exemple : http://pojo.test.org).
Nommez vos Interface / Service / Endpoint à votre convenance.
Inutile de spécifier un WSDL.

Dans la fenêtre “Jar Files” (etc…)

Donnez le chemin d’accès vers le jar créé lors de l’étape précédente (bouton “browse”, sélectionnez le fichier jar)
Faites ensuite “Browse” pour la boîte “Service Class”, vous pourrez y choisir la classe du POJO présent dans votre jar.

Terminez le processus (allez jusqu’à “Finish”, et cliquez dessus).

PetalsStudio va alors générer un projet “su-POJO--provide, avec un dossier “resources/” contenant le fichier jar du POJO, et un dossier META-INF contenant le descripteur de déploiement Petals (jbi.xml).

Attention : la version 1.0 Beta2 de PetalsStudio comporte un bug… à tout hasard, éditez META-INF/jbi.xml. Si vous y trouvez la chaîne suivante :

“http://petals.ow2.org/components/extensions/version-4.0″

remplacez “4.0″ par “5″, comme ceci :

“http://petals.ow2.org/components/extensions/version-5″

(puis sauvegardez).

Cliquez le projet avec le bouton droit, puis “Petals / Package for Petals”.

Vous aurez alors un fichier “sa-POJO--provide.zip”, prêt à être déployé dans Petals (comme SU associée au SE-POJO).

Etape 3 : Déploiement sur Petals

Démarrez Petals
Déployez le SE-POJO
Déployez votre SU générée à l’étape 2 (sa-POJO--provide.zip).

Et voilà le travail !

Outils Petals ESB : Librarie pour binder des services Web

Christophe — Mon, 01 Mar 2010 11:29:55 +0000

Dans un précédent article, je décrivais comment ‘proxifier’ un Web service dans Petals ESB avec un plugin Maven maison. Ce plugin Maven utilise une librairie Java que j’ai développé pour lier et exposer des Web services dans/avec Petals ESB.

Le ‘problème’ actuel de Petals ESB est qu’il est pleinement basé sur la spécification JBI, cela veut dire que actuellement, si on veut exposer un service JBI en tant que Web service, il faut créer un fichier de configuration (le fameux JBI.xml), le packager dans une unité de service (Service Unit – SU), et packager cette SU dans un assemblage de services (Service Assembly – SA). Bien sur des outils comme le Petals Studio sont la pour aider les développeurs à intégrer leurs services, moi je me place plus dans la peau du ‘Core Developper’ et je pour le moment je n’ai pas eu l’utilité d’outils graphiques pour configurer Petals.

Dans une de mes taches actuelles, je suis en train d’étendre Petals pour le faire communiquer sur Internet et je développe ce que j’appelle l’API de Monitoring & Management (M&M API) qui est exposée (pour le moment seulement) en Web service. La partie Management de l’API doit permettre à un administrateur de la plateforme, de ‘binder’ des services (Web, REST, …) sans se soucier de la partie JBI.
L’API fournit donc une opération du style bind(URI wsdl). Coté serveur, j’utilise :

Une librairie maison de génération de SA
Je déploie localement cette SA pour ‘binder’ un Web service au bus.
J’expose ce service de management avec la feature expliquée dans ce post

Un exemple d’utilisation de la librairie est donné dans le listing suivant (binder au bus, le Service Web Version de Axis2) :


package org.ow2.petals.tools.generator.jbi;

import java.io.File;
import java.net.URI;
import java.net.URISyntaxException;
import java.util.HashMap;
import java.util.Map;
import org.ow2.petals.tools.generator.jbi.api.JBIGenerationException;
import org.ow2.petals.tools.generator.jbi.ws2jbi.WS2Jbi;

public class BindAxis2Version {

public static void main(String[] args) throws JBIGenerationException, URISyntaxException {

String wsdl = "http://localhost:8080/axis2/services/Version?wsdl";
Map map = new HashMap();

// let's say that we want to generate SA for SOAP component 4.0
map.put(org.ow2.petals.tools.generator.commons.Constants.COMPONENT_VERSION, "4.0");

URI wsdlURI = new URI(wsdl);

File f = new WS2Jbi(wsdlURI, map).generate();

System.out.println("Service Assembly is available at " + f.getAbsolutePath());

}
}

Pour utiliser WS2Jbi, utilisez dans votre projet Maven, la dépendance :




org.ow2.petals.sandbox

petals-ws2jbi

1.0-SNAPSHOT

Celle ci est normalement disponible est mise a jour régulièrement sur le repository Maven d’OW2 http://maven.ow2.org/maven2-snapshot/. Les sources sont disponibles dans ma Sandbox Petals.

Maven est ton ami #2 : Effective POM

Christophe — Mon, 01 Mar 2010 10:34:51 +0000

Après « Maven est ton ami #1 : Dependency tree« , le court article du jour est juste une note pour les personnes qui se (et me) demandent souvent pourquoi ils n’arrivent pas a releaser (entre autres)…
Ce qui est bien avec Maven2, c’est que l’on peut ‘overrider’, utiliser des parents, définir ses mots de passe sans les publier publiquement… Mais ce qui est moins bien, quand on ne maitrise pas Maven, c’est que l’on se perd vite dans toutes ses configurations (ajoutez par dessus un proxy, de l’authentification, des repositories privés…). Est c’est la que l’on se demande comment on peut s’y retrouver…

Heureusement, les gens de chez Maven2 ne sont pas si bêtes, le plugin Help permet de lister le POM effectif du projet courant en lancant la commande

# mvn help:effective-pom

Simple et efficace. Les gens qui se demandent, par exemple, pourquoi ils ne sont pas bien authentifiés lors d’une release peuvent alors verifier dans le POM généré, que leurs login/password ne sont pas définis pour le bon ID de serveur…

One more JBI component : SOAP Proxy

Christophe — Tue, 02 Feb 2010 14:38:22 +0000

I just developped a new JBI component for Petals ESB. This component, named ‘petals-bc-soapproxy’ is based on the work I did on the standard SOAP binding component and provide an easy way to proxify SOAP based Web services with Petals ESB.

This component, based on Apache Axis2, uses a small part of WS-Addressing to provide the proxy feature. ‘Small part’ means that for now, by using Axis2, I need to bypass the mustUnderstand attribute of the WS-Addressing elements. Why? Because I need to use the WSA:To element to specify the Web service I want to finally invoke and I need to set the mustUnderstand attribute to false to bypass one implementation detail on Axis2 which is not ‘friendly’ with my own implementation. Why (again)?… By setting some mustUnderstand attribute to true in the SOAP message header, it means that the SOAP engine (ie Axis2) must understand the header during message processing. A mustUnderstand attribute set to true in the WS-Addressing header means that the SOAP engine must handle the WS-Addressing information and here I do not want to. If I set this attribute to true, I need to add the Axis2 addressing module, which will handle the WS-Addressing header, and will put all the addressing information in the Axis2 message context. I can do that and get the information from this context for for some reason it does not work like I expect… Maybe an Axis2 update will fix this…Need some time to investigate, and for now time is not my friend… So, here is how it work :

1. The SOAP client sends the SOAP message to the Petals SOAP Proxy (by default this service is exposed at http://localhost:8085/petals/services/SOAPProxyWebService). The SOAP message header contains the WS-Addressing information which will be used to reach the final Web service. A SOAP message sample is for example :




http://wsapi.petals.dsb.soa4all.eu/HelloService/sayHello
http://localhost:7600/petals/ws/HelloService




Say hello!

where http://localhost:7600/petals/ws/HelloService is the final Web service I want to invoke.

2. The SOAP message is handled by the SOAP proxy component, transformed as JBI message and sent to the right JBI endpoint.

3. The JBI endpoint gets the WS-Addressing information from the JBI message, the SOAP message from the JBI message payload and send all of this stuff to the final Web service. Invokcation response is sent back to the initial consumer through the ESB.

A simple schema of what happens with three ESB nodes is given in the figure below :

So, the main question is why using such a proxy and why not invoking the service directly? There are many answers to these questions and since I already said that the time is a missing resource, it will be probably part of a future article…

The first version of the component is available on the OW2 SVN repository under my sandbox (have a look to http://websvn.ow2.org/listing.php?repname=petals&path=%2Fsandbox%2Fchamerling%2Fproxy%2Fpetals-bc-soap%2F#path_sandbox_chamerling_proxy_petals-bc-soap_)

Note : Using SOAPUI for WS-Addressing testing works fine (even if I had some exchanges with SOAPUI guy (http://twitter.com/olensmar) on Twitter…)… Sorry to have doubts on SOAPUI!

PetalsStudio ou Eclipse Linux : problème de clic souris sur les boutons ?

gibello — Mon, 25 Jan 2010 15:48:03 +0000

Symptôme : le clic sur certains boutons (particulièrement les wizards de création de projet – boutons “next”, “cancel”, etc…) reste sans effet, alors que les raccourcis clavier fonctionnent.
Le même problème se produit sur un Eclipse “standard”.
Constaté sur un Ubuntu 9.10, ce problème a également été signalé sur d’autres Linux.

Solution : positionner la variable d’environnement GDK_NATIVE_WINDOWS à “true”.

Exemple :
$ GDK_NATIVE_WINDOWS=true PetalsStudio

Ou:
$ export GDK_NATIVE_WINDOWS=true
$ PetalsStudio