SOA par la pratique

Lorsqu'une DSI souhaite mettre en oeuvre une Architecture Orientée Services (SOA), il lui est souvent conseillé de suivre une démarche en cascade qui part des processus métier de l'entreprise et qui visent à définir des services ré-utilisables. Même en supposant que ce long processus réussisse, la matérialisation informatique de ces services dans le SI passe généralement par de lourds projets de refonte de l'existant qui est généralement peu aligné sur ces visions théoriques. Qui peut alors réalistement défendre auprès de sa Direction Générale un projet de refonte même partiel de son SI aux seules fins de le rendre SOA ?

A cette démarche " top-down " longue et coûteuse, je conseille à mes clients une approche organique plus respectueuse de l'existant et qui tient compte des actifs informatiques, qu'ils soient des applications " maison " ou des progiciels intégrés au SI. Il peut par exemple s'agir de votre logiciel de paie, de votre annuaire d'entreprise ou d'applications liées à votre coeur métier.

Ceci étant dit, il nous faut encore examiner comment il est possible de faire participer cet existant - souvent appelé " legacy systems " par nos amis anglophones - à une architecture orientée services. En effet, ces applications legacy exposent rarement leurs fonctionnalités / données sous forme de services.

Prenons l'exemple d'un progiciel de comptabilité dont on souhaite exposer le référentiel de tiers au reste du SI. Il s'agit classiquement d'une application client / serveur déployée sur un ou plusieurs postes de travail avec en général une base de données hébergée sur un serveur de l'entreprise.

Figure 1 : Une application client /serveur

Vous n'avez probablement pas la main sur l'application cliente qui est livrée sous forme de binaire par l'éditeur ou l'intégrateur et qui propose souvent comme seul de communication un rudimentaire système d'import et d'export de fichiers actionné par l'interface utilisateur. Il n'est donc pas possible de faire une autre application avec le client de logiciel de comptabilité.

Figure 2 : Pas d'échange avec le client

Reportons nous du côté de la base de données. Avec un peu d'analyse, il est possible d'identifier dans le modèle de données du progiciel les tables relatives aux tiers. Eureka ! Votre DBA sera probablement capable de vous écrire quelques requêtes vous permettant de récupérer tous les tiers, de récupérer un tiers par sa clé ou bien une liste de tiers respectant certains critères.

Une première approche consisterait à donner ces requêtes SQL aux autres applications qui ont besoin d'accéder au référentiel tiers.

Figure 3 : Intégration par la donnée

Evidemment cette approche extrêmement simple et rapide peut poser des problèmes :

• Couplage fort entre les applications clientes et le modèle de donnée du progiciel de comptabilité
• Surcharge induite sur la base de données
• Création de comptes applicatifs dans le SGBDR pour se connecter
• Ouverture des ports réseaux adéquats pour effectuer ces requêtes SQL
• Etc.

Une autre possibilité consiste à interposer entre la base de données et les applications clientes un artefact applicatif en façade des tables de la base de données. Chez OCTO, nous donnons souvent le nom d'émissaire à ce type d'application. La métaphore consistant à dire que lorsqu'une application du SI a besoin d'échanger avec une autre application, elle doit s'adresser à l'émissaire de cette dernière. Autrement dit, l'émissaire expose sous forme de services les fonctions / données de l'application qu'elle représente.

La façon la plus simple d'exposer les données stockées dans la base sans se coupler fortement à la structure des tables est d'introduire des vues ou des procédures stockées qui encapsulent une représentation des données à exposer. L'application consommatrice peut ainsi par exemple récupérer la liste des tiers du logiciel de comptabilité sans dépendre de la structure du modèle de données. Cette première implémentation diminue le couplage des applications mais présente encore certains inconvénients liés à l'utilisation de SQL comme middleware d'échange (surcharge non contrôlée de la base de données, ouverture de ports ésotériques, gestion des droits d'accès rudimentaire, etc.).

Figure 4 : Première version de l'émissaire

Si ces limitations vous posent problèmes dans le contexte de votre projet, il est possible de créer l'émissaire en dehors de la base de données sous la forme d'une petite application qui se connecte d'une part à la base de données et expose ces données sous forme de services.

Figure 5 : Deuxième version de l'émissaire

Les avantages sont multiples :

• Faible couplage entre la base de données et les applications consommatrices.
• Possibilité d'intégrer dans l'émissaire des fonctions de filtre, de transformation, de transcodage, de cache, etc.
• Possibilité d'exposer les services suivant plusieurs protocoles (RMI, HTTP, etc.)

Vient-on de remplacer notre projet de refonte de SI par un projet de bus SOA d'entreprise quasiment aussi long et coûteux ? Non, car là encore il existe des alternatives pragmatiques à une approche " grands travaux ".

Ca sera d'ailleurs l'objet d'un autre article qui montrera comment implémenter simplement un émissaire de services avec le framework Grails.