Pushing your Web services in the Cloud in 5 minutes…


… or less! Heroku is defined as a « Cloud application platform ». I just want to redefine it to « Awesome Cloud application Platform ». So, this awesome platform provides a way to host and scale your application in the Cloud really easily with 3 or 4 commands…

Since I am currently working on my talk at #OW2Con 2011 (coming later this week) dealing with BPM, Services and the Cloud, I wanted to host some Web services on several places. I never had time to test Heroku but I just took this precious time today. After looking some examples, I created a Maven project template (no I do not have time to create an archetype, maybe there is one somewhere) which uses Jetty and Apache CXF to expose JAXWS annotated classes as Web services. So now, using heroku to freely expose your services is easy as:

  1.  Sign up to heroku
  2. Download the heroku client for your platform
  3. Clone/Fork the repository at https://github.com/chamerling/heroku-cxf-jaxws
  4. Add your own services
  5. Login to heroku ‘heroku auth:login
  6. Create the app on heroku ‘heroku create -s cedar
  7. Push your services to heroku ‘git push heroku master‘. There is a git hook somewhere which just automatically compile and start your application after you pushed it.
  8. Open your CXF services summary page ‘heroku open’
The default application name is some random one, you can rename it by using the ‘heroku rename yournewname‘ but in the current case I had an issue on the generated Web service endpoint name. So I suggest restarting your app after renaming (have a look to the ‘heroku ps‘ command).
That’s all, that’s quick!
Publicités

Jouons avec WebServiceProvider…


Il y a des jours où exposer ses classes annotés avec @WebService n’est pas satisfaisant…
Pour moi ce jour c’est aujourd’hui: Il m’est impossible de marshaller mes beans en document DOM à cause d’un contexte JAXB tordu et d’une API qui ne prend que du DOM en entrée (OK bon ça c’est nul mais c’est pas de moi…). Qu’a cela ne tienne, il est temps d’utiliser les WebServiceProvider puisque ils vont me permettre de directement récupérer mon message SOAP sous forme de document… Un peu moins straight forward comme approche mais qui peut convenir dans certains cas. Comme les exemples ne courent pas le Web, regardons ce que l’on peut faire pour s’en sortir…

(Tout le code source de cet article est disponible sur Github : http://github.com/chamerling/chamerling.org-samples/tree/master/cxf-serviceprovider-072011)

Une première solution simple est d’implémenter javax.xml.ws.Provider, de rajouter deux/trois annotations et le tour est quasiment joué:

package org.chamerling.blog.cxf.serviceprovider;

import javax.xml.soap.SOAPMessage;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceProvider;

/**
* @author chamerling
*
*/
@WebServiceProvider
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
public class SimpleServiceProvider implements Provider {

/*
* (non-Javadoc)
*
* @see javax.xml.ws.Provider#invoke(java.lang.Object)
*/
@Override
public SOAPMessage invoke(SOAPMessage in) {
return null;
}
}

Reste à l’exposer avec CXF en utilisant org.apache.cxf.jaxws.JaxWsServerFactoryBean. Cette approche simpliste a le mérite de marcher, il ne reste plus qu’a manipuler les SOAPMessage dans l’implémentation de la méthode invoke.

Besoin de l’opération qui est appelée? Ajoutons javax.xml.ws.WebServiceContext en tant que javax.annotation.Resource. Ce contexte sera automatiquement rempli pour nous par CXF et accessible dans le corps de la méthode invoke. Par exemple, on peut travailler de la sorte:

/**
 *
 */
package org.chamerling.blog.cxf.serviceprovider;

import javax.annotation.Resource;
import javax.xml.namespace.QName;
import javax.xml.soap.SOAPMessage;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceContext;
import javax.xml.ws.WebServiceProvider;
import javax.xml.ws.handler.MessageContext;

/**
 * @author chamerling
 *
 */
@WebServiceProvider
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
public class SimpleServiceProvider implements Provider {

	@Resource
	WebServiceContext wsContext;

	/*
	 * (non-Javadoc)
	 *
	 * @see javax.xml.ws.Provider#invoke(java.lang.Object)
	 */
	@Override
	public SOAPMessage invoke(SOAPMessage in) {
		System.out.println("Operation : " + getOperation());
		System.out.println("Message In :");
		try {
			in.writeTo(System.out);
		} catch (Exception e) {
			// bad
		}
		System.out.println();
		return null;
	}

	private QName getOperation() {
		QName result = null;
		if (wsContext != null && wsContext.getMessageContext() != null) {
			Object o = wsContext.getMessageContext().get(
					MessageContext.WSDL_OPERATION);
			if (o != null && o instanceof QName) {
				result = (QName) o;
			}
		}
		return result;
	}
}

Et invoquer le service:

package org.chamerling.blog.cxf.serviceprovider;

import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;

import junit.framework.TestCase;

/**
 * @author chamerling
 *
 */
public class SimpleServiceTest extends TestCase {

	public void testExpose() throws Exception {
		String url = "http://localhost:9999/foo/bar/SimpleService";
		final JaxWsServerFactoryBean ssf = new JaxWsServerFactoryBean();
		ssf.setAddress(url);
		ssf.setServiceBean(new SimpleServiceProvider());
		ssf.create();

		HelloService client = getClient(url);
		client.sayHello("Rock N Roll!");
	}

	/**
	 * @param url
	 * @return
	 */
	private HelloService getClient(String url) {
		JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
		factory.setAddress(url);
		factory.setServiceClass(HelloService.class);
		Object client = factory.create();
		return HelloService.class.cast(client);
	}
}

Dans ce cas, on a une opération affichée qui est {http://serviceprovider.cxf.blog.chamerling.org/}invoke et le message SOAP

Rock N Roll!

Pas très convaincant pour l’opération avec cette approche… Le mieux est de pousser un peu plus loin et partir du contrat de service (WSDL) de notre Provider. CXF permet de le spécifier via ses factories lors de la construction du service. Cette utilisation plus avancée est détaillée en partant de org.chamerling.blog.cxf.serviceprovider.CXFExposer. L’approche utilisée dans CXFExposer permet aussi de cacher toute la tambouille JAXWS à l’utilisateur, au final il a besoin d’implementer seulement org.chamerling.blog.cxf.serviceprovider.Service

package org.chamerling.blog.cxf.serviceprovider;

import javax.xml.namespace.QName;

import org.w3c.dom.Document;

/**
 * @author chamerling
 *
 */
public interface Service {

    /**
     * Get the WSDL description
     *
     * @return
     */
    String getWSDLURL();

    /**
     * Get the service URL ie where to publish it...
     *
     * @return
     */
    String getURL();

    QName getEndpoint();

    QName getInterface();

    QName getService();

    /**
     * Invoke the service
     *
     * @param request
     * @param action
     */
    Document invoke(Document in, QName operation) throws ServiceException;

}

Jouons avec le Petals Kernel et Apache CXF


Oui, à chacun sa façon de s’amuser… Je viens d’ajouter une feature dans le Petals Distributed Service Bus qui me trottait dans la tête depuis un petit moment: Pouvoir invoquer des services techniques (distants ou pas) du coeur du DSB en utilisant la couche de transport naturellement utilisée pour invoquer des services métiers (les services hostés par le bus ou liés à celui ci). Autrement dit, imaginons que j’ai un service technique qui tourne sur un noeud et que depuis un autre noeud, je dispose d’un client pour l’invoquer de façon simple mais aussi totalement transparente.

Ce que l’on pouvait faire jusqu’à présent, c’est utiliser l’API Web service exposée par le DSB pour invoquer le service pour peux que le service soit annoté comme il faut (pour rappel, cette API Web service utilise Apache CXF pour exposer automatiquement les composants Fractal qui sont annotés avec JAXWS). Bien, mais par défaut on utilise deux ports pour les communications inter noeuds: Le port utilisé par Apache CXF, et l’autre par la couche de transport du DSB (en fait c’est le cas dans Petals ESB, mais dans le DSB, la couche de transport étant par défaut une implémentation en Web service, on utilise le même port pour les deux). En allant un peu plus dans les détails, même si on utilise le même port pour les deux modules dans le DSB, ceci n’est plus vrai si une nouvelle implémentation de la couche de transport utilise autre chose que CXF (pour info, dans le DSB, une implémentation de la couche de transport en XMPP existe aussi). C’est donc la qu’on arrive a la solution d’utiliser le canal de communication du DSB pour toute invocation entre noeuds, comme on sait déjà échanger des messages avec le DSB, pourquoi s’en priver?

C’est bien beau de vouloir exposer des services, des composants Fractal, ou quoi que ce soit, si on veut rester en Java et ne pas avoir besoin de se triturer le peu de cerveau qu’il nous reste, autant penser à utiliser tout ou partie d’une solution qui existe deja. En allant dans ce sens, comme on doit au final avoir une sorte de serialization des messages, autant utiliser quelque chose qui sait deja le faire, j’ai nommé le couple inséparable JAXB+JAXWS. Ceci impliquera seulement d’annoter ses interfaces et de créer des types propres et JAXB-aware mais au final, je ne pense pas que cela soit une contrainte forte… C’est bien beau tout cela mais JAXB + JAXWS tout seul ca ne fait pas grand chose. C’est la qu’entre en jeu Apache CXF. Puisque l’utilisation de JAXWS est simple avec CXF, autant s’intéresser un peu à la bete. Pour le coup cà tombe bien, dans CXF il y a deja une notion de transport multiple: HTTP, XMPP, JMS et si on regarde bien on a même JBI (les potes de chez JonAS ont d’ailleurs implémenté un transport CXF utilisant les EJB ou un truc J2EE dans le style si ma mémoire est bonne). Tiens donc, il y a un transport JBI? Ca tombe (presque) bien, le DSB est basé sur Petals ESB qui est JBI compliant. Oui mais en fait non. J’aurais presque pu l’utiliser mais le but est d’implémenter quelque chose d’assez ‘JBI independant’. Le tout est maintenant d’implémenter un nouveau transport pour le DSB et grace au code source de CXF et à cette page http://cxf.apache.org/custom-cxf-transport.html on comprend assez bien comment faire. Dans la terminologie CXF, le client est le ‘conduit’ et le serveur est la ‘destination’. Il suffit donc d’implémenter nos propres conduit et destination pour pouvoir échanger des messages avec CXF.

Une fois CXF configuré avec nos conduit et destination, ou plutôt une fois la bonne transport factory implémentée, on devrait pouvoir faire quelque chose du style:

// 1. Initialize CXF Bus with factory
Bus bus = BusFactory.getDefaultBus();
DestinationFactoryManager dfm = bus.getExtension(DestinationFactoryManager.class);
DSBTransportFactory petalsTransportFactory = new DSBTransportFactory();
petalsTransportFactory.setBus(bus);
petalsTransportFactory.registerWithBindingManager();

// 2. Start service
System.out.println("Starting CXF server...");
JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setAddress("dsb://host/serviceA");
sf.setServiceClass(HelloService.class);
sf.setServiceBean(new HelloService() {
    public String sayHello(String input) throws PEtALSWebServiceException {
        System.out.println("SAY HELLO INVOKED!");
        return pre+input;
    }
});
sf.create();

// 3. Create the client and invoke
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setAddress("dsb://host/serviceA");
factory.setServiceClass(HelloService.class);
HelloService hello = (HelloService) factory.create();
String out = null;
try {
    out = hello.sayHello(in);
} catch (PEtALSWebServiceException e) {
}

Je passe les détails d’implémentation (que j’ai eu le plaisir de faire dans un bon vieux TGV en panne entre Montpellier et Bruxelles) pour le moment, mais ce qui se passe se résume à:

  1. On configure CXF en lui ajoutant notre Transport Factory. Au niveau de l’implémentation, il y a ce qu’il faut pour que lorsque une client ou une server factory est configurée avec une adresse qui commence par ‘dsb://’, ce soit notre DSBFactory qui soit automatiquement appelée par CXF.
  2. La création du service se fait comme si on créait un Web service sur http sauf que là c’est un ‘Web service sur DSB’.
  3. Idem que pour 2 mais on génère un client qui nous permettra d’appeler le service créé auparavant.

En résultat, pour peu que le client (en 3) et le serveur (en 2) soient exécutés sur des noeuds séparés, le DSB se chargera d’acheminer la requête et la réponse comme il faut entre les acteurs et ceci de façon complètement transparente. Au niveau de l’implémentation coté kernel du DSB (ceci vaut aussi pour Petals ESB), il suffit de connaître quand même un peu le coeur pour créer des fakes de composants JBI en farfouillant dans les APIs disponibles, de savoir jouer avec le DeliveryChannel, le ComponentContext, le NormalizedMessageRouter, ajouter quelques modules de routage, savoir recevoir des messages et y répondre, et surtout implémenter le Conduit et la Destination CXF en s’inspirant de ce qui existe déjà et en mettant les doigts dans le cambouis. Pour les curieux, je vous conseille de jeter un oeil au code de CXF assez compréhensible et pas mal fait du tout.

Enfin pour étendre cela aux services techniques du coeur du DSB, il suffit, au runtime, de scanner les services disponibles offerts par les composants du kernel et automatiquement créer les services comme décrit dans l’étape 2. Chose que l’on sait déjà faire dans le DSB via le scan pour exposer les services en Web service sur HTTP avec CXF (oui toujours lui, avant je m’en prenais a Axis2…).

Et voila donc une belle et simple façon de simplifier la vie du développeur du DSB (c’est à dire moi). Il va être maintenant possible d’invoquer n’importe quoi de n’importe où avec une API Java. Pour peu que l’on plugge quelques modules au bon endroit, on peut imaginer faire des choses assez sympa: Le Cloud en fait partie.

Note: Le code sera disponible d’ici la fin de la semaine sur le SVN du DSB. Surement sous https://svn.petalslink.com/svnroot/trunk/research/commons/dsb/modules/dsb-kernel, je mettrais a jour l’article en fonction…

Créer sa couche de transport pour Petals ESB en 4 classes


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…

Exposer ses composants Fractal en Webservice dans Petals ESB #2


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 😉