Parxeme-SOA (Partie 1)

Introduction
La conception d’un système SOA impose l’usage d’un cadre méthodologique
adapté et public. Pouvons-nous nous lancer dans ces grands travaux sans avoir, en préalable, des réponses claires à la question : « comment nous y prendre ? ».
Répondre à cette question, c’est le rôle de la méthodologie. Le cadre
méthodologique est d’autant plus nécessaire que le développement d’une
architecture de services implique des compétences différentes. Une des grandes difficultés sera d’articuler ces compétences.
C’est une chose d’avoir la réponse à nos questions ; c’en est une autre que cette réponse soit partagée. La première qualité d’une méthode est qu’elle soit connue et reconnue, suffisamment répandue pour servir de référence commune aux différents acteurs des projets, tant internes qu’externes. Pour une Direction Informatique, il n’est pas envisageable d’adopter des cadres méthodologiques SOA différents selon
les prestataires retenus. Inversement, il n’est pas raisonnable non plus qu’une DSI finance la formation lourde de ses prestataires, pour qu’ils puissent se couler dans son propre cadre propriétaire. Il nous faut donc une méthode publique.
En matière de méthodologie, nous disposons aujourd’hui de quelques standards,dont les principaux sont UML1 pour la représentation et MDA2 pour la définition
des modèles. Ces standards fixent une partie des questions de forme. Mais ils laissent sans réponse les questions de définition des modèles, de qualité,
d’organisation du travail, etc. Avec UML, nous disposons d’une boîte à outils qui peut équiper tous les métiers impliqués dans les projets ; toutefois, il nous manque le mode d’emploi.
Nous ne trouvons pas, dans UML, ni dans UP ou RUP, pas plus que dans le
courant Enterprise Architecture, la réponse aux questions soulevées par la mise en oeuvre de l’architecture SOA : Qu’est-ce qu’un service ? Quelle est la typologie des services ? Comment trouve-t-on les services ? Comment structurer les services ? Comment assure-t-on la flexibilité des pré- et post-conditions des services ? Comment dérive-t-on un modèle de classes en structures d’information (format pivot) ? Etc.
La pratique de SOA soulève encore bien d’autres questions : autres questions : relations entre modèle sémantique et ESB, combinaison des approches par règle,par composant, et des modèles, etc.
PRAXEME est une méthodologie d’entreprise dont la vocation est d’articuler
les expertises nécessaires pour améliorer l’activité métier. Le système
d’information y est traité dans la foulée de la modélisation sémantique (Référentiel « Métier ») et de la conception d’organisation (modélisation des processus, notamment). L’approche SOA est inscrite sur la « grande carte » des compétences, au même titre que l’urbanisation de SI qu’elle prolonge. Le fait de disposer d’une vision élargie, multidimensionnelle, de l’entreprise permet de répondre à la question « comment trouver le services ? ». Conformément au standard MDA,c’est en référence à des modèles amont que le concepteur va repenser le système.
Des efforts ont été engagés pour faire de Praxeme une méthode publique, avec la participation de plusieurs intervenants, sous le nom de « Initiative Praxime ».
Praxime est le nom du chantier d’élaboration de Praxeme : c’est l’initiative pour une méthode publique. Le principe d’ouverture répond à l’exigence – évoquée ci-dessus – d’un référentiel largement partagé, à l’instar de Merise en d’autres temps.
Si Merise résultait d’un financement public, nous nous appuyons aujourd’hui sur une logique de mutualisation des investissements. Les contributeurs (Sagem Défense, SMABTP…) financent des composants méthodes qu’ils acceptent de déposer dans le fonds commun. Ils jouissent, en retour, de l’enrichissement de ce fonds.
Au sein de l’initiative Praxime, Orchestra Networks s’attache à mettre en pratique la méthode dans le contexte des systèmes SOA. Nous détaillons alors les composants logiques nécessaires à la spécification des services, les règles d’orchestration et de propagation d’appels entre les services, la typologie des services, la démarche de test des services, la définition des formats pivots et de leurs variantes, la liaison avec la gestion des données de référence (MDM ou Master Data Management), etc.
L’association de plusieurs années de travail des inventeurs de Praxeme
(Dominique Vauquier, Philippe Desfray) avec l’expertise de plus d’une décennie de Pierre Bonnet dans le domaine des architectures orientées services permet de déboucher sur une méthode opérationnelle pour la conception et le développement des systèmes orientés services.
La méthode présentée ici doit beaucoup à l’expérience menée par la SMABTP,sous l’impulsion de Jean-Michel Detavernier (directeur informatique adjoint). Le projet de refonte de la gestion des sinistres a appliqué strictement la démarche et a permis de consolider la méthode pour la mise en oeuvre de SOA.
Les principes du SOA selon Praxeme

La première considération que soulève l’approche orientée services est la
définition même du terme « service ». Cette définition n’est pas si simple, si l’on en juge par le temps passé dans les entreprises pour la fixer. Une telle situation s’explique par le mode d’émergence de cette approche : le discours SOA, comme d’autres courants en informatique, est porté par l’offre de technologies, avant tout.
La réflexion méthodologique n’intervient que dans un deuxième temps. Il ne faut, alors, pas s’étonner du flottement sur les concepts.
Praxeme repose sur un socle : la Topologie du Système Entreprise. Il s’agit d’un framework méthodologique qui identifie et articule les huit aspects d’un organisme. L’approche multi-aspects permet d’accueillir tous les discours et expertises qui portent sur les organismes, et de tout décrire pour éclairer l’action.
Les informations et décisions nécessaires à l’amélioration de l’activité sont ainsi ordonnées dans la chaîne de production.
Praxeme fixe la définition du terme « service » et son positionnement dans la chaîne de production. Pour la méthodologie Praxeme, le service est un terme de l’aspect logique.Sa définition fait référence à la finalité propre à cet aspect : structurer au mieux le système d’information. La Topologie du Système aide à séparer les facettes que véhicule le terme « service ».

Le service est un composant logique, c’est-à-dire qu’il apparaît dans la
modélisation logique. La spécification des services logiques se fait par le
modèle logique.
- À la question « comment trouver les services ? », Praxeme répond que la
majorité des services s’obtient en dérivant les modèles amont. L’origine de
la plupart des services se trouve dans les modèles sémantiques et pragmatiques. Cette référence à la modélisation amont garantit le contenu
fonctionnel des services, à condition, bien sûr, que cette modélisation soitmenée rigoureusement.
- L’architecture technique fournit les conditions de réalisation des services.
Praxeme pose le principe d’indépendance logique/technique. Le concepteur
logique fait en sorte que le modèle logique, relativement indépendant des
choix techniques, soit stable. Toutefois, Praxeme prévoit, dans le processus de développement, une étape de négociation logique/technique assurant la convergence dans l’aspect logiciel.
- Au niveau logiciel, un composant s’obtient en appliquant, à une
spécification logique, les choix de solutions et les procédés de
développement arrêtés par l’architecture technique.
« Service » est, donc, un terme de l’aspect logique. Comme tous les termes
utilisés sur cet aspect intermédiaire, il est motivé par la métaphore, exactementb comme « urbanisation de SI ». En le positionnant dans la vue interne du système, on évacue les connotations qu’il peut avoir pour les acteurs non informaticiens.
Dans SOA, le terme service désigne un composant du système informatique.
Le service est l’unité de construction – et de réutilisation – par laquelle le système fournit une réponse à un besoin d’information, d’action ou de transformation.
Conséquence : le système est restructuré en composants autonomes qui masquent les ressources et qui assurent l’intégrité. Les données disparaissent sous les services. Les règles et contraintes sont encapsulées dans les services, de sorte que,en sollicitant un service, on a la certitude que ces règles et contraintes sont respectées. Le demandeur du service n’a pas à se préoccuper de la solution organique (technique ou physique). Les relations entre le demandeur et le fournisseur d’un service s’établissent sur la base d’un « contrat ». Le contrat en SOA favorise le découplage entre consommateur et fournisseur. Il permet aussi d’augmenter le niveau de confiance et de mieux aligner l’exécution du système sur
les conditions fonctionnelles et techniques de production, ceci d’autant mieux que le contrat est formel et exécutable (runnable). C’est le cas, par exemple, si les conditions de SLA sont exprimées en WS-Agreement et les pré- et post-conditions déclarées en XML Rules (Schematron, CAM…).
On retrouve là les principes des approches structurées, orientées objets ou par composants. Il y a continuité d’inspiration et – nous le verrons par la suite – de procédés.
En conclusion, « service » est une notion très simple et très opératoire. Qu’est-ce qui change ? Quels sont l’originalité et l’apport de cette approche ? Pour bien les percevoir, il faut les opposer aux approches traditionnelles. Si on ne pose pas la question du critère de structuration du système, l’architecture logique applique spontanément une approche fonctionnelle. L’architecture fonctionnelle est une architecture logique qui a opté pour le critère de la fonction. Nous connaissons les
limites de cette approche et les effets qu’elle induit :
- rigidité du système résultant de la verticalité de la décomposition,
- redondance résultant de l’approche hiérarchique descendante.
C’est en réaction à ce style d’architecture que se constitue l’approche SOA.