Image may be NSFW.
Clik here to view.
Ross Mason a créé le projet Mule ESB en 2003 puis a fondé MuleSource, l’entreprise derrière ce populaire ESB Open Source. Après s’être cantonné pendant un temps au support de cet ESB, l’éditeur a récemment opéré une diversification de son portfolio et a été rebaptisé pour l’occasion MuleSoft. Ainsi les derniers mois ont vu l’apparition de Tcat Server, une offre Tomcat pour entreprise, de iBeans, et dernièrement de Mule Data Integrator.
Parmi ces nouveaux produits, iBeans est probablement le plus intriguant. Le principe même de ce framework: une solution d’intégration pour applications Web avec l’idée que les iBeans interviennent là où Mule ESB s’arrête.
Après une apparition discrète en phase beta, MuleSoft dévoile peu à peu des informations sur iBeans depuis deux mois. C’est dans ce contexte que Ross Mason a présenté iBeans à Devoxx 2009 à Anvers.
Qu’est-ce qu’un iBean ?
Un iBean est un composant similaire à ceux offerts par Spring ou EJB. Il se distingue par son rôle : il est uniquement dédié à une tâche d’intégration. Il sera ainsi responsable d’exposer une interface simple pour accéder à un service distant.
Ces tâches de développement sont habituellement effectuées à l’aide d’un ensemble d’APIs dans des composants généralistes. Le framework de MuleSoft se propose donc ici d’apporter un environnement spécifique à ce type de tâche.
Le rôle décrit ici semble au premier abord être celui d’un ESB. Les iBeans sont pourtant destinés à résider au sein d’une application Web. Ross Mason explique que lors du développement d’une telle application, il est souvent nécessaire de s’intégrer avec plusieurs services distants. Or, un ESB n’est pas toujours présent dans l’environnement de l’application pour la délester de ces tâches et lui fournir un service simple et facilement utilisable. Au-delà des services internes à l’entreprise, l’application peut aussi avoir besoin de consommer des services sur Internet tels que Twitter ou Amazon Web Services (AWS). Dans ces deux cas de figure, iBeans apporte une réponse en simplifiant l’intégration directement au niveau de l’application.
Le repository central
Un des buts principaux des iBeans est d’être réutilisable, éventuellement au-delà des frontières de l’entreprise. Par exemple, un iBean permettant d’accéder à Twitter pourrait probablement être réutilisé dans la plupart des applications ayant besoin d’utiliser ce service. C’est pour cette raison que MuleSoft a mis en place un repository central pour que les développeurs puissent partager les iBeans qu’ils créent.
Dans la pratique, il s’agit d’un repository Subversion sur lequel des iBeans peuvent être publiés. Les iBeans sont alors mis à disposition sous forme d’artefacts Maven.
Architecture
Les iBeans sont des composants ayant un cycle de vie distinct du conteneur applicatif (Spring, Guice, …) auquel ils s’intègrent. Ainsi, chaque injection d’iBean entraîne la création d’une nouvelle instance.
Ces composants sont développés à l’aide d’annotations qui permettent de s’intégrer à des channels. Chaque channel apporte le support d’un protocole particulier. Actuellement les channels disponibles sont : HTTP / REST, JMS, FTP, SMTP, POP3, JDBC et XMPP. D’autres types de channels arriveront à l’avenir, et il est bien sûr possible d’en développer soi-même.
La particularité est que le framework n’est pas destiné à être intégré dans le war de l’application Web, mais directement au sein de Tomcat. Ross Mason le justifie principalement par la mutualisation que cela permet.
Création des iBeans
Le framework iBeans propose au développeur un ensemble d’annotations pouvant être utilisées pour créer de nouveaux iBeans facilement. Un iBeans peut invoquer un service synchrone et recevoir ou envoyer un message asynchrone.
Invoquer un service
L’invocation d’un service distant est simple avec iBeans. L’exemple suivant montre comment invoquer l’API REST de Twitter :
public interface MyTwitterIBean {
@Call(uri="http://twitter.com/statuses/show/{id}.json")
String statusesShow(@UriParam("id") String id);
}
Il s’agit d’une simple interface avec une méthode. L’annotation @Call sera détectée par le framework qui trouvera le paramètre d’URL à utiliser grâce à l’annotation @UriParam.
Envoyer un message
Il est également possible d’envoyer un message asynchrone. L’exemple suivant montre comment programmer un envoi régulier de messages JMS :
public class JmsScheduleSendBean
{
private AtomicInteger count = new AtomicInteger(1);
@Schedule(interval = 1000)
@Send(config = "jms-publish")
public Object send()
{
return "New Message " + count.getAndIncrement();
}
}
L’annotation @Send indique que l’objet retourné par la méthode doit être envoyé sur la queue JMS jms-publish. L’annotation @Schedule programme une invocation de la méthode toutes les secondes.
Recevoir un message
Enfin, il est possible de recevoir un message asynchrone. Toujours dans le cas de JMS, la réception de message s’effectue grâce à l’annotation @Receive :
public class JmsReceiveAndSendBean
{
@Receive(config = "jms-receive")
@Send(config = "jms-result")
public String receive(String message)
{
return message + " Received";
}
}
Dans cet exemple, les messages reçus sur la queue jms-receive entraineront l’invocation de la méthode receive() avec le contenu du message JMS en argument. Des transformers seront utilisés pour effectuer une éventuelle adaptation de type. Enfin, la chaîne de caractère retournée par la méthode sera ici renvoyée en tant que message sur la queue jms-result.
Transformers
Afin d’effectuer des conversions de type automatiques, il est possible de définir des transformers. Là aussi, c’est grâce à une annotation que cette définition va se faire. L’exemple suivant montre un transformer simple :
public class SimpleTransformer {
@Transformer
URL toUrl(String string) throws MalformedURLException {
return new URL(string);
}
}
Il n’est pas nécessaire d’inscrire cette classe auprès du framework, celui-ci se chargera de la découvrir grâce à son annotation et déduira les entrées et sorties de la transformation à l’aide des paramètres d’entrée et de sortie de la méthode.
L’utilisation du transformer se fera également automatiquement dans les iBeans lorsque le type reçu par un service et le type renvoyé par sa méthode correspondante ne sont pas compatibles.
Intégration aux frameworks applicatifs
iBeans peut s’intégrer aux conteneurs d’injections de dépendances courants tels que Spring et Guice. De par le choix architectural qui a été fait de le destiner uniquement à Tomcat, l’intégration à EJB n’est assez logiquement pas possible.
Une fois la configuration effectuée, les composants applicatifs peuvent se faire injecter un iBean à l’aide de l’annotation @IntegrationBean.
Intégration Javacript
Cette possibilité est originale pour un framework d’intégration mais n’est pas sans rappeler DWR et Seam Remoting. Il s’agit ici de pouvoir invoquer un iBean déployé sur un serveur depuis le navigateur, en Ajax, via un appel Javascript. L’exemple ci-dessous montre une telle invocation :
<script type="text/javascript">
var ibeans = new IBeansClient();
creds = ibeans.config.get("twitter.user", "twitter.pass");
ibeans.twitter.setCredentials(creds[0], creds[1]);
ibeans.twitter.getFriendTimeline(readTweets);
funtion readTweets(tweets, error) {
// do stuff
}
</script>
Le futur pour iBeans
Les possibilités offertes par iBeans sont intéressantes, mais le projet n’en est qu’à ses débuts. Ross Mason annonce de nombreuses possibilités supplémentaires à venir :
- Intégration à GWT / GXT, Grail, Play framework, JSF, et Struts 2
- Support des Web Services avec JAX-WS et JAX-RS
- Configuration centralisée
- Mule ESB 3.0 sera capable d’embarquer iBeans ce qui permettra une capitalisation plus importante sur les composants développés
- iBeans s’intégrera avec Mule Data Integrator, la solution graphique de mapping de données sous Eclipse proposée par MuleSoft
Conclusion
Les tâches qu’iBeans permet de réaliser ne sont pas inédites : elles pouvaient déjà être effectuées au sein d’un ESB. Son positionnement de solution d’intégration pour application Web le différencie de ce type de produit, mais il va tout de même à la rencontre des lightweight ESB, tels que Spring Integration et Apache Camel, qui se développent depuis plusieurs années.
On pourra malgré tout trouver l’API proposée par iBeans plus agréable que celle de ces deux concurrents directs dans le cadre d’intégrations au sein d’applications Web. Mais c’est surtout la ré-utilisabilité des iBeans qui semble réussie : les interfaces annotées peuvent très facilement être encapsulées dans un artefact Maven, pour être ensuite importées en dépendance dans les applications intéressées, puis injectées dans les composants métiers, sans configuration additionnelle.
Le choix de MuleSoft d’intégrer iBeans directement à Tomcat peut surprendre. On s’attendrait plutôt à retrouver ce framework au sein du war de l’application. Ross Mason reste flou sur les raisons de ce choix. Si des raisons techniques peuvent le justifier, on peut surtout imaginer des raisons commerciales : l’éditeur distribue ainsi iBeans avec Tcat Server et dispose , avec Mule ESB, de deux produits très séduisants pour l’entreprise.