Démarche générale
Comment s'y prend-on pour mener à bien un projet SOA ?
Les architectures orientées services (SOA) sont actuellement très à la mode. Elles facilitent l'implémentation des processus métiers au sein de l'entreprise, favorisent l'évolution des dits processus et permettent d'homogénéiser et de mieux contrôler les communications entre systèmes informatiques.
A la base de ces architectures, on trouve un certain nombre de technologies et de concepts déjà plus ou moins maîtrisées dans nos entreprises : XML (description, validation, transformation, ...), les services Web (SOAP, WSDL), le faible couplage , ... Cependant, si les principes sont relativement simples à comprendre et les technologies déjà connues, il apparaît que la mise en place d'une SOA reste complexe. Cette complexité est essentiellement causée par l'absence d'une démarche adaptée aux objectifs des SOA. Trop souvent, on cherche à mener à bien un projet SOA de la même manière qu'on le ferait pour un développement logiciel. Or, les deux problématiques sont totalement différentes. Un développement logiciel consiste à développer un système répondant à un certain nombre de fonctionnalités, sous forme de composants, s'articulant autour d'une architecture technique solide et adaptée aux contraintes techniques imposées. Une architecture orientée service, quant à elle, doit permettre de faciliter la mise en oeuvre de processus métiers (business process). Un processus n'est pas une fonctionnalité, c'est un ensemble de tâches (activités), mené par des acteurs au sein de l'entreprise (personnes physiques ou systèmes informatiques), initié par un évènement (commande, contact client, ...) et aboutissant à un résultat apportant une plus-value pour l'entreprise. Durant ce processus, des informations (messages) sont véhiculées, transformées, routées, validées ou enrichies (pattern VETRO).
L'essence des SOA est donc constitué des processus, des messages et des interactions (contrats des services) avec chaque participant. La démarche doit donc se concentrer sur ces trois aspects.
Références :
A la base de ces architectures, on trouve un certain nombre de technologies et de concepts déjà plus ou moins maîtrisées dans nos entreprises : XML (description, validation, transformation, ...), les services Web (SOAP, WSDL), le faible couplage , ... Cependant, si les principes sont relativement simples à comprendre et les technologies déjà connues, il apparaît que la mise en place d'une SOA reste complexe. Cette complexité est essentiellement causée par l'absence d'une démarche adaptée aux objectifs des SOA. Trop souvent, on cherche à mener à bien un projet SOA de la même manière qu'on le ferait pour un développement logiciel. Or, les deux problématiques sont totalement différentes. Un développement logiciel consiste à développer un système répondant à un certain nombre de fonctionnalités, sous forme de composants, s'articulant autour d'une architecture technique solide et adaptée aux contraintes techniques imposées. Une architecture orientée service, quant à elle, doit permettre de faciliter la mise en oeuvre de processus métiers (business process). Un processus n'est pas une fonctionnalité, c'est un ensemble de tâches (activités), mené par des acteurs au sein de l'entreprise (personnes physiques ou systèmes informatiques), initié par un évènement (commande, contact client, ...) et aboutissant à un résultat apportant une plus-value pour l'entreprise. Durant ce processus, des informations (messages) sont véhiculées, transformées, routées, validées ou enrichies (pattern VETRO).
L'essence des SOA est donc constitué des processus, des messages et des interactions (contrats des services) avec chaque participant. La démarche doit donc se concentrer sur ces trois aspects.
- Processus : on commence par modéliser les processus existant au sein de l'entreprise. On détermine les activités, les acteurs ainsi que le moyens existant et les procédures adaptés à chaque étape. Une fois l'existant modélisé, il ne reste plus qu'à (sic ?) déterminer comment améliorer le processus, mettre en avant les étapes nécessitant une communication avec un autre système ou avec un être humain. Cette modélisation peut être basée sur les langages UML (diagrammes d'activités, SOAML, ...) ou BPMN.
- Contrats : après avoir modélisé les processus et identifier les besoins de communication, on peut en déterminer les contrats associés. Pour cela, on liste les opérations nécessaires et on les regroupe en tant que service. Encore une fois UML nous aidera dans cette phase, mais il sera également possible de présenter les contrats sous la forme de descriptions WSDL.
- Messages : les données véhiculées lors du déroulement du processus, ou échangées durant l'invocation des services doivent également être modélisées. Il est important de standardiser la représentation des données métiers au sein de l'entreprise si l'on souhaite faire des SOA. En effet, si tous les systèmes utilisent les mêmes descriptions de données, la communication entre eux n'en sera que plus simple. Diagrammes de classes UML et schémas XML (XSD) sont les éléments résultant de cette modélisation.
Références :