On lit ça et la qu'une architecture SOA n'est pas classique, et que sa mise en place ne s'appréhende pas comme celle d'un projet de développement informatique habituel. Nous devons donc faire face à plusieurs difficultés simultanément, d'ordre technique (XML, MOM, Web Services, ...) d'une part et d'ordre organisationnel et méthodologique d'autre part. 

Un des objectifs de l'approche SOA est de permettre à une entreprise/organisation de présenter à ses partenaires, clients et fournisseurs (en interne et en externe) une vitrine technique homogène d'accès à ses services métier.

D'une façon générale, un projet d'envergure est mené en deux phases distinctes, l'une conduite par la MOA, la seconde par la MOE. Dans un cadre SOA, la responsabilité de la MOA est d'établir à destination de la MOE la liste des services à rendre disponibles, ces services correspondant à tout ou partie des processus métier de l'organisation. Cela peut représenter un aspect stratégique qui dépasse largement le périmètre d'une DSI. Dans un premier temps, nous ne nous intéresserons pas à cet aspect du processus, pour nous concentrer sur les activités essentiellement du ressort de la MOE. 

Rappelons quand même que du côté MOA, la démarche d'établissement de l'expression des besoins comporte une première étape consistant en une étude de faisabilité, suivie d'une seconde étape d'élaboration du cahier des charges qui sera transmis à la MOE:

Dans un cadre SOA, il semble important de se concentrer sur la définition des processus et des objets métier, qui alimenteront la MOE.

Côté MOE, il peut être intéressant de tenter d'appliquer au projet une démarche de type UP, dont on particularisera les sorties de certaines phases:

De façon générale, chacune de ces phases produira un ensemble de sorties de ce type:

La phase de conception préliminaire permet de rapprocher les points de vue "fonctionnel" (éléments issus de l'analyse) et "techniques" (choix effectués par l'équipe d'architecture). Il s'agit notamment de "plaquer" sur les objets métier issus de la branche gauche du Y les choix techniques effectués au long du déroulement de la branche droite.

Pour un projet SOA, nous pourrions envisager d'y ajouter:

Qu'en pensez-vous ?

Le premier processus analysé est celui qui consiste à traiter les rapports d'activité (RA) de chaque intervenant en mission. A la fin de chaque mois, ou à la date d'échéance d'une intervention, l'intervenant rempli un rapport (actuellement sous forme de fichier Excel) indiquant ses jours de présence chez le client. Ce document est signé par le client puis transmis au secrétariat de Leuville Objects afin de donner lieu à une facture.
L'analyse de ce processus a produit un ensemble de diagrammes UML.

• Diagrammes d'activités pour représenter le processus en terme d'activités associées à divers acteurs.
• Diagrammes de classes pour représenter les données véhiculées lors du traitement d'une instance du processus.
• Diagramme d'états-transitions pour représenter les divers états associés à un rapport d'activité

Ces éléments sont éssentiels pour déterminer les services qui seront consommés / exposés au sein du bus de service, ainsi que les structures de données échangées.

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.

• 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.

Une fois tous ces éléments définis, on voit déjà plus clairement le travail à fournir, et on peut alors commencer à réfléchir aux éléments techniques qui permettront de faire fonctionner tout ça.

Références :

• SOA sur wikipedia
• Business Process sur wikipedia
• BPMN sur wikipedia