Penser l'architecture à partir des besoins

Ludovic Arbelet, Frédéric Bordage et Philippe Davy

01 Informatique

le 12/03/2007 à 07h00

envoyer
par mail

imprimer
l'article

Les applications traditionnelles de nos systèmes d'information sont en train d'être remodelées en vue de s'insérer dans une architecture modulaire, souple, et adaptable. L'objectif des architectes est de favoriser l'émergence des notions de service et de composition au sein d'un système par nature hétérogène, et soumis à une évolution perpétuelle.

Une approche par services préconise l'assemblage en cassant le couplage fort traditionnel pour miser sur des liaisons asynchrones. La plupart des environnements de développement autorisent désormais la publication du code sous forme de services Web, supportant tous les standards associés – Soap pour les accès et l'invocation, et WSDL et UDDI pour le référencement. Mais la logique est à la réutilisation de l'existant.

“ C'est le besoin qui doit guider, recommande Yves Guéry, responsable des services professionnels pour Seagull Software en France. On ne passe pas son temps à créer ou ajouter des services. Souvent, les projets relèvent de la synthèse, du regroupement. Les informations sont éparpillées dans le système, et l'on cherche à les organiser, à centraliser. ” Mais, isoler au sein des applications les blocs fonctionnels candidats au statut de services est une tâche souvent ardue.

Identifier les bons candidats

Il ne s'agit pas de tout modifier dans l'architecture existante. Une vision claire et précise du système d'origine est néanmoins nécessaire. En fonction de son âge, celui-ci ne fournira pas le même niveau de documentation. “ SOA s'inscrit dans une définition d'architecture et une logique de réutilisation, comme toutes les approches précédentes des systèmes distribués, explique Grégory Tanneau, architecte Java pour la SSII Onepoint. Il faut d'abord découper le système d'information, en identifier les grands concepts, et avancer progressivement. ”

L'objectif est de réutiliser certaines fonctions susceptibles d'être réparties dans de multiples programmes : prise de commandes, tarification, stocks, saisie de commandes, etc. Exemple : une compagnie d'assurances automobile dispose d'une application centrale pour établir ses devis. Elle souhaite la déployer sur Internet et l'utiliser dans d'autres configurations. La compagnie doit alors créer l'infrastructure permettant à plusieurs applications de l'exploiter. “ Nous ne voulons pas réécrire le code, explique Yves Guéry. C'est pourquoi ces invariants doivent être identifiés avec précision. ”

Ainsi, une fonction de recherche dans une base ne retournant que des données spécifiques pour une application n'est qu'un piètre candidat en raison des lourdeurs qu'elle impose pour un bénéfice nul. A l'inverse, une fonction interrogeant plusieurs bases dont les données rapatriées servent plusieurs applications a des chances de devenir un excellent service, dans la mesure où elle mutualise une fonction au sein d'une ressource le plus largement accessible. Dans le cas où plusieurs fonctions proches sont éligibles et concurrentes, il faut choisir une fonction maîtresse et l'enrichir.

La cartographie du patrimoine applicatif est une donc une phase obligatoire et assez longue. “ Parfois, quand le code est très ancien, on ne dispose pas de la documentation, décrit Grégory Tanneau. On procède alors à une évaluation fonctionnelle à partir de la rétro-ingénierie du schéma de la base de données. Or, la plupart du temps, celui-ci a été modifié. ”

Regarder la technique avec une vue métier

Quoi qu'il en soit, les services doivent être conçus avec l'idée de les intégrer à un processus métier. Leur définition et leur granularité dépendent donc du ou des processus auxquels ils participeront. “ Cela implique l'existence d'un vocabulaire commun, permettant de regarder la technique avec une vue métier, détaille Sylvain Cailliau, directeur technique de Serena Software France. Le bon niveau de granularité pour un service, c'est bien souvent la règle de gestion. ”

L'approche SOA est une démarche pragmatique, où l'on capitalise sur l'existant. Pour bien identifier le besoin, le référentiel de services s'impose de plus en plus. De nombreuses implémentations initiales ont pu en faire l'économie en raison du nombre maîtrisable de services exposés. Aujourd'hui, la nécessité d'un tel référentiel devient plus évidente. Les grands éditeurs ont d'ailleurs mis cette année les bouchées doubles pour doter leurs plates-formes de ces outils. En les développant ou en acquérant de petits éditeurs spécialisés.

Les solutions de type annuaire, utilisées en exécution, fournissent les références des services appelés. Celles de type référentiel, elles, incorporent le service proprement dit, et assurent la gestion de son cycle de vie.

Comment identifier les services

agrandir la photo

Une méthode de définition des services consiste à réaliser parallèlement deux analyses, l'une “ top down ”, à partir des besoins métier, sans considérer l'existant, et l'autre, “ bottom-up ”, en ne considérant que lui.