J’ai participé récemment à un Boot Camp Oracle sur leur SOA Suite 11g. Je connaissais jusqu’alors l’ancienne offre de BEA, mais je n’avais, par contre, pas eu l’occasion de voir ce qu’il ressortait vraiment de la gamme Fusion Middleware. Je n’ai pas assez recul pour vous dire si c’est LA solution du marché ni pour vous pointez du doigt les failles de sa mise en œuvre, cet article est juste là pour vous faire partager quelques réflexions que j’ai eues à son sujet.

L’intégration des différents composants dans la version 10g était réputée incomplète/imparfaite, la première impression qui ressort est que dans la version 11g, l’intégration semble bien aboutie.
La plupart des outils sont intégrés dans JDeveloper, la console d’administration Entreprise Manager est très complète et permet de manipuler les différents types de composants, le tout pouvant s’exécuter sur un runtime unique (WebLogic Server).

Avant de décrire quelques éléments de la suite qui m’ont intéressés, je tiens à rappeler tout de suite qu’une telle suite reste sur une solution lourde :

• l’installation de l’ensemble des composants est loin d’être immédiate et comporte de nombreuses étapes ;
• au runtime, de nombreux composants sont nécessaires et nécessitent pas mal de mémoire et de cpu ;
• il est nécessaire d’avoir une installation complète de la suite pour pouvoir faire les tests (on oublie le petit test d’intégration lancé sous JUnit) ;
• sans oublier l’investissement financier pour se la procurer.

L’approche SCA

Rentrons un peu plus dans le vif du sujet maintenant

La SOA Suite 11g est centrée sur des composites comme unité de déploiement.
La notion de composite fait parti de la spécification SCA : Service Component Architecture (http://www.osoa.org/display/Main/Service+Component+Architecture+Home).
Un composite décrit comment un ensemble de composant doivent être relié pour former un composant de plus haut niveau. Il expose une interface et décrit ses dépendances.

Ci-dessous l’illustration d’un composite dans la spécification SCA :

Vous pouvez trouver quelques présentations et tutoriaux à la fin de cette page : http://www.osoa.org/display/Main/SCA+Resources

L’approche SCA m’avait jusque là peu emballé : les présentations que j’en ai lu décrivant principalement la composition de service par chainage des composants, j’avais l’impression qu’un des principaux besoins d’une composition : la transformation des messages échangés entre ces services, n’était pas traité.
Dans ces conditions, je ne voyais pas l’intérêt de mettre en place une telle spécification.

Il m’apparait maintenant que ce n’est pas parce que les problématiques de transformation ne sont pas intégrés dans la spécification que cela lui ôte tout intérêt. Cela signifie juste que certains des composants à intégrer dans un composite doivent être des composants de transformation.

La mise en œuvre du composite dans la SOA Suite traite justement très bien ce sujet : elle propose l’utilisation d’un composant Mediator au cœur de la définition des Composites qui répond très bien à ce besoin (entre autres). Et l’outillage permet de le mettre en œuvre très facilement.

Les composites dans la SOA Suite

Voici quelques caractéristiques d’un composite dans la SOA Suite:

• un composite expose une ou plusieurs interfaces (décrite via une WSDL), synchrone ou asynchrone
• il orchestre les appels vers différents services externes, des adaptateurs permettent d’utiliser ainsi des files jms/ des fichiers / une base / …
• sa définition s’appuie sur quatre composants de base - mediator : cf ci-dessous
• process BPEL : pour gérer des orchestrations plus compliqués
• human workflow : permet d’assigner des tâches aux utilisateurs du système et d’attendre leur complétion avant de continuer les traitements
• moteur de règle : pour externaliser les règles métiers
• Un composite est stateful : pour supporter des process BPEL conversationnel
• Un composite est versionné : plusieurs versions d’un composite peuvent coexister. Le use-case principal est de permettre aux précédentes instances de se terminer normalement tandis que les nouvelles instances sont créées avec la nouvelle définition du composite. (J’ai aussi cru comprendre que la migration des instances existantes vers une nouvelle version était possible)
• La gestion d’erreur est possible de façon déclarative par l’application de fault policy. Une des stratégies de gestion d’erreur intéressante est “HUMAN INTERVENTION” : lors d’une erreur l’instance du composite se bloque et un administrateur peut étudier le problème et après avoir mené les actions nécessaires, relancer le traitement ayant échoué. Il pourra en particulier modifier le contenu d’une des variables d’un process BPEL avant d’effectuer la relance.
• Gestion des transactions JTA possibles (cette transaction ne pouvant bien sûr pas se propager aux appels vers des ressources non transactionnelles tel que les appels de WebService)

Ci-dessous, la représentation d’un composite dans JDevelopper :

Dans l’onglet “composite.xml” : le bandeau gauche représente les interfaces exposées, le bandeau droit représente les références à des services externes qui sont nécessaires, le centre représente la composition de différents composants.
On voit les mediators en violet, les process BPEL en bleu et une tâche en vert.

Le composant mediator

Comme je l’ai indiqué plus haut, le composant Mediator est, à mon sens, la clef de voute pour rendre effective l’approche SCA.

Ce composant est basé sur l’ancien bus d’Oracle : Oracle Enterprise Service Bus (à ne pas confondre avec Oracle Service Bus issu de AquaLogic Service Bus suite au rachat de BEA).
Il permet de traiter les aspects suivants :

• enrichissement/transformation ( pouvant en particulier être définie via l’ éditeur visuel de XSLT dans JDevelopper )
• validation
• routage
• filtrage

Ci-dessous une capture du wizard de création du mediator

On peut y voir différentes routes possibles pour le message en entrée.
Chaque route applique un filtre au message pour savoir si elle doit le traiter ou pas (ici sur un champ “operation”). Le service et l’opération a appelé sont spécifié à côté du filtre (ici des opérations d’un service nommé “Common”). Une transformation XSL est effectuée avant d’appeler le service (le fichier xsl utilisé étant affiché dans la description de la route)

Ce composant illustre à mes yeux une distinction qui n’est pas toujours très clair dans le positionnement des différents bus du marché :

• Le Bus en tant que médiateur : composition des services, routage fonctionnel, etc …
  C’est en partie le rôle du médiator dans la SOA Suite (complété par le moteur BPEL pour des compositions plus complexes).
  On répond ici à un besoin qui n’est pas purement technique : une composition répond à besoin fonctionnel. Sa mise en œuvre nécessite toutefois parfois de gérer des aspects plus technique d’intégration (ce que le composite permet via l’utilisation d’adaptateurs dans les services externes)
  Dans le monde OpenSource, des frameworks tel que Camel ou Spring Integration s’attachent à résoudre ce type de problématique en se détachant justement de la notion de “bus”
• Le Bus en tant que brique d’infrastructure : frontal par rapport aux partenaires / adaptation de protocole / cross-cutting concerns (securité/logging/audit/…) / virtualisation de service / routage technique / …
  C’est le rôle de Oracle Service Bus (anciennement AquaLogic chez BEA) dans la SOA Suite
  Ce sont souvent des équipes différentes qui mette en œuvre ce bus. L’intégration d’aspects fonctionnels (tel que des règles métiers de routage) sont souvent à éviter pour des raisons de maintenance, de centralisation, de cohérence et d’agilité.

Les autres composants de la SOA Suite

La SOA Suite contient d’autres éléments qui peuvent être très intéressant :

• moteur de BAM (Business Activity Monitoring) ;
• l’intégration avec le framework Oracle ADF-Faces (en particulier pour la gestion des tâches dans le cadre des Human Workflow) et ADF-Business Component (en particulier pour créer des SDO : Service Data Objects)
• l’EDN (Event Delivery Network, qui permet de découpler encore plus les différents modules développé en permettant l’envoi d’information en mode publish/subscribe et qui intégré à l’ensemble des composants de la Suite).

Si cela vous intéresse vous pourrez avoir plus d’information sur le site d’Oracle à l’adresse suivante :
http://download.oracle.com/docs/cd/E17904_01/soa.htm