Après avoir testé et déployé avec succès plusieurs processus BPEL simples dans Petals ESB, nous en avons conclu que nous utiliserions ce bus pour déployer nos processus métier. Cependant quand nous avons commencé à développer des processus un peu plus élaborés, nous nous sommes vite rendus compte que le moteur BPEL utilisé n'implémentait pas toute une partie de la spécification WS-BPEL 2.0.
Le site de Petals Link propose le moteur BPEL Orchestra de l'OW2 Consortium comme alternative au moteur de base, mais la distribution JBI de ce dernier est encore en cours de développement.

Nous avons donc décidé de regarder ce que faisait la concurrence. Deux principaux serveurs on retenu notre attention car leurs moteurs BPEL implémentaient la spécification WS-BPEL 2.0 : ServiceMix et Glassfish ESB.

• Glassfish ESB est le bus ESB de Sun. Il fournit tout comme Petals une interface graphique et des outils pour faciliter le développement des processus BPEL et leur déploiement sur le serveur. De plus après les premiers tests le moteur BPEL semblait plus complet que celui de Petals. Mais finalement le même problème bloquant que celui rencontré sous Petals nous a fait abandonner Glassfish ESB.

• ServiceMix est le bus ESB de la fondation Apache. Le moteur BPEL de ce dernier est Apache Ode. Ce moteur respecte la spécification WS-BPEL 2.0 et après quelques tests il s'est révélé être le moteur le plus complet que nous ayons testé. Cependant le déploiement sur le serveur des processus pose problème. Que ce soit avec la version 1.3 ou 2.0b de Ode nous avons rencontré des bugs dont un qui n'a pas encore été résolu à l'heure actuelle.

Apache Ode fournit une archive War qui peut être déployée sous n'importe quel serveur d'application JEE et donc indépendant de tout serveur ESB. N'ayant pas trouvé de serveur ESB assez mature pour déployer nos services nous sommes donc contraints d'utiliser Ode avec Tomcat pour développer nos processus, en attendant que des corrections et/ou des améliorations soit apportées aux autres moteurs BPEL.

Après avoir décrit les processus métier à l'aide de diagrammes d'activités UML nous nous sommes attelés à rechercher des solutions techniques pour mettre en place notre architecture orientée services. Pour cela nous nous proposons d'utiliser un bus de services (ESB).

Un bus ESB est une infrastructure logicielle tenant lieu de couche intermédiaire (middleware) à travers laquelle les services métiers réemployables sont rendus disponible par l'intermédiaire de technologies standardisées. Ce bus ESB va nous permettre d'exposer et d'interpréter des processus BPEL. BPEL (Business Process Execution Language) est un langage basé sur XML et décrivant les étapes techniques de mise en oeuvre des processus métier préalablement décrits en UML.

Plusieurs solutions de serveurs ESB Open Source sont disponibles sur le marché : Apache Servicemix, JBoss ESB, Mule, Celtix, etc.
Nous avons choisi d'utiliser Petals ESB qui est un bus conforme à la spécification JBI, spécification décrivant un modèle standard d'implémentation de tels bus.

Voici les principaux avantages qui nous ont fait choisir ce serveur :

• Mise à disposition de nombreux composants (SOAP, BPEL, JMS, Mail, EJB, etc.).
• Documentation assez complète et expliquant bien le fonctionnement du serveur et de chacun des composants.
• Interface web permet de faciliter l'administration du serveur (installation/démarrage/arrêt/test des composants et des services).
• Petals Studio : un IDE basé sur Eclipse facilitant grandement le développement des services.

L'interface web de petals :



La page d'accueil de Petals Studio :



On notera cependant que le serveur manque encore de maturité. En effet des erreurs peuvent survenir pendant le déploiement ou la désinstallation de certains services, il faut alors redémarrer le serveur voir le réinitialiser (désinstaller tous les composants). De plus le moteur BPEL disponible sur le site n'implémente pas la totalité de la spécification BPEL 2.0. Un composant  permettant d'utiliser le moteur Orchestra de l'OW2 Consortium est également disponible mais le développement de ce dernier n'est pas totalement terminé.