L'Architecture Orientée Services et J2EE. Ahmed ALAMI's WEBLOG.

Dans le monde de l’entreprise, la gouvernance de l’entreprise consiste en un ensemble de règles législatives et réglementaires qui définissent les modalités de gestion d’une entreprise. C’est un concept utilisé pour la surveillance économique, financière et morale de l’entreprise.

La gouvernance permet d’établir des chaînes de responsabilité, d’autorisation et de communication en affectant à chaque maillon des chaînes des facultés décisionnelles. Ces dernières sont mesurées et contrôlées par des mécanismes en fonction des rôles et des responsabilités de chacun.

Toute fois, il est nécessaire de faire le distinguo entre le management et la gouvernance, la gouvernance affecte les responsabilités et les contrôle, le management est le processus exécutif des responsabilités.

Le principe de gouvernance est aussi appliqué dans le domaine de l’IT.

La gouvernance IT a pour but de contrôler la validité, l’utilité, la disponibilité, l’efficacité et la performance des choix techniques au sein d’une entreprise. Elle permet donc définir une structure de base capable de relier les ressources techniques aux besoins de l’entreprise. Elle institutionnalise des bonnes pratiques pour planifier, implémenter et contrôler les choix techniques.

L’architecture orientée services est utile dans le cadre de projets d’envergure où l’intégration, l’ouverture, l’agilité, la modularité sont des mots clefs et des critères de réussite. Ces projets font appel à plusieurs interlocuteurs et sortent avec des décisions de choix techniques des fois très coûteuses. C’est la où intervient la gouvernance de SOA.

La gouvernance SOA apporte discipline et bon sens à la conduite d’un projet SOA.

La gouvernance SOA étend la gouvernance IT en se focalisant sur le cycle des vie des services implémentés tout en assurant la ‘business value’ de la SOA.

1. Un service consiste en un ensemble de fonctionnalités fournis par une entité dans le but d’être utilisées par d’autres entités.
2. Les services sont conceptuellement autonomes (autosuffisants) et opaque (indépendant des technologies d’accès aux ressources).
3. Aucune distinction en terme d’architecture ne devrait être faite entre les services consommés dans le cadre d’un processus et les autres consommés directement.
4. Tout service logique a une description canonique.
5. La description d’un service est composée de trois parties logiques :
   • Un modèle de données.
   • Règles et obligations exigées pour les consommateurs et les fournisseurs du service.
   • Contrats qui gouverne l’utilisation du service.
6. Une règle de sécurité peut nécessiter l’utilisation d’un système de sécurité.
7. Une politique de sécurité inexistante est considérée comme une règle de sécurité.
8. Les consommateurs d’un service doivent disposer de sa description afin de pourvoir interagir avec ce dernier.

L’exemple suivant illustre les concepts décrits dans le cadre du modèle de référence SOA.

• Une compagnie d’électricité a la capacité de produire et distribuer de l’électricité (Underlying Capability). Le câblage de la grille de distribution de la compagnie électrique (Service) fournit les moyens nécessaires pour assurer la consommation de l’électricité au sein d’un foyer (Service Functionnality). Une prise murale (Service Interface) est connecté au système de câblage et est censée récupérer de l’électricité (Real World Effect).
• Afin de consommer de l’électricité, le foyer (consommateur du service) doit être capable de savoir quelle type de prise murale utiliser, la tension de l’approvisionnement, les limites possibles de la charge (Service policy). Les deux parties (compagnie d’électricité et consommateur) sont supposées utiliser des matériels compatibles dans les deux sens (Technical Assumptions).
• Le foyer devrait ouvrir un compte auprès de la compagnie d’électricité qui le relie au câblage de la distribution (Service Constraint), la compagnie est supposée être payée pour continuer à donner l’accès au service. Les deux parties conviennent aussi que le paiement n’est fait que dans le cas ou le service est continu (Service Contract) ; dans le cas par exemple d’une détérioration de la grille de distribution, le client ne payera pas pour le service.
• La compagnie se donne le droit de couper tout approvisionnement si le foyer ne paye pas ses dus (Service Policy).
• Dans le cas ou le foyer veuille utiliser un autre service d’approvisionnement, il serait obligatoire d’utiliser un matériel adapté (Service Interface).

La description d’un service consiste en toutes les informations nécessaires et suffisantes afin d’utiliser un service. Il se peut que cette description dépende d’un contexte d’exécution bien précis. Cependant, il existe au sein de la description d’un service des informations statiques (modèle d’information – Information Model) et d’autres dynamiques (règles et contrats).

Le but de la description du service est de faciliter l’interaction et la visibilité entre participants. Il est donc possible pour de construire des processus cohérents et des services compatibles.

Une description de service se doit de détailler les éléments suivants :

• L’existence du service et son accessibilité.
• La fonction ou les fonctions qui sont exécutées par le service.
• Les contraintes et les règles sans lesquelles le service ne peut s’exécuter.
• La nature des informations échangées entre le consommateur du service et ce dernier.

L’accessibilité du service

L’accessibilité est entre le consommateur et le fournisseur des services. La description du service se doit donc de décrire l’adresse du service et le protocole à utiliser.

Cette description peut aussi contenir des informations sur la disponibilité du service.

La fonctionnalité du service

Tout service doit fournir les fonctions utilisées et les types d’informations échangées avec son consommateur. Ces informations peuvent aussi contenir des pré-requis techniques qui précisent les limitations des fonctionnalités du service.

L’interface du service

L’interface du service est le seul moyen ou point d’entrée pour interagir avec un service. C’est une notion fondamentale dans les principes de la SOA.

Une règle consiste en un ensemble de contraintes ou conditions lors de l’utilisation, du déploiement ou de la description d’une entité du modèle de référence. Les règles sont définies individuellement par chaque participant du modèle. Un contrat représente un accord accompli entre deux ou plusieurs participants.

Les règles du service

Une règle est définie à travers trois concepts :

• L’assertion décrivant la règle
• Le propriétaire (le sujet de la règle)
• La mise en œuvre de la règle

Une assertion se doit d’être mesurable, c'est-à-dire qu’il existe un mécanisme capable de déterminer si l’assertion dans un contexte d’exécution est fausse ou vraie. Une assertion de règle est toujours dépendante du contexte d’exécution d’un service. Par exemple, une assertion comme ‘Tous les messages doivent être cryptés’ est tout à fait mesurable.

Les règles peuvent avoir un aspect technique comme métier. L’exemple précédant de la règle ‘Tous les messages doivent être cryptés’ est une règle technique. La règle ‘L’exécution des services se fait entre 12h et 14h’ est une règle métier.

Une assertion correspondant à une règle doit être partagée par les participants à une interaction pour être prise en compte. On peut donc se retrouver dans une situation ou un consommateur d’un service affirme que ses messages sont cryptés alors que le service invoqué n’ait pas de contrainte à ce niveau.

Les règles sont appliquées dans plusieurs principes de la SOA.

• La sécurité
• La qualité de service
• La manageabilité

Les assertions des règles doivent être écrites dans une grammaire compréhensible et facile à traiter.

Les règles correspondantes aux services doivent être formalisées au niveau de la description du service.

Le contrat de service

Alors que la règle est associée au point de vue d’un seul participant, un contrat est un engagement mutuel entre deux ou plusieurs participants. Les contrats de service font parties de principes comme :

• La sécurité
• Qualité de service
• Accord de chorégraphie
• Accords commerciaux …

Les contrats sont décrits en sorte d’automatiser leur interprétation.

Un contrat peut ne pas faire partie d’une SOA.

Un service consiste en un mécanisme à travers lequel il est possible d’accéder à une ou plusieurs ressources ou fonctionnalités. Cet accès est définit via une interface dont l’appel est soumit à des contraintes et des règles (Contract & Policy) spécifiées dans la description du service.

Un service est fourni par un Service Provider.

Un service peut réaliser son exécution en faisant appel à d’autres services. Cet appel constitue un process. Ce process peut être automatisé ou manuel.

Un service est opaque dans le sens ou son consommateur n’a aucune visibilité ni sur son implémentation ni sur l’accès aux ressources sous-jacentes.

Real world effect est le résultat de l’invocation d’un service. Ce résultat peut être :

• Des informations retournées en réponse à une requête exigeant cette information
• Un changement de l’état des entités partagées ou manipulées
• Une combinaison des deux effets précédents.

Le consommateur du service n’est pas à même de déterminer la manière avec laquelle l’information a été retournée ou le changement de l’état des entités a été effectué.

Les ressources auxquelles accède le service ne font pas partie du contexte de la SOA.

L’adoption de l’architecture orientée services a pris un essor conséquent depuis sa réintroduction dans les bonnes pratiques d’architecture et la souplesse apportée par les services web. La prolifération d’articles et de documents parfois incohérents, surtout que la plupart des solutions proposées pour l’implémentation de l’architecture orientée services penchent pour une technologie et restent assez spécifiques.

Le modèle de référence pour l’architecture orientée services répond à cette problématique en lui associant, un dictionnaire, un vocabulaire, des concepts généraux qui guident les et définissent une template de design de haut niveau pour toutes les implémentations des SOA.

Cet article reprend les concepts du modèle de référence développé par l’organisme OASIS.

Un modèle de référence est un framework abstrait qui aide à comprendre les relations entre les entités d’un environnement donné. Il consiste en un ensemble minimal de concepts, axiomes et définitions qui ne dépendent ni des standards ni des technologies utilisés pour leur implémentation.

Le but du modèle de référence SOA est de définir l’essence de l’architecture orientée services et construire une sémantique compréhensible et commune pour la SOA. Ce modèle fournit des normes qui ne prennent en aucun cas compte des inévitables évolutions technologiques qui peuvent influencer le déploiement de la SOA.

Les concepts et les relations définies par le modèle de référence sont les bases nécessaires pour décrire les architectures de référence, des dernières permettent de construire des architectures concrètes en prenant en compte les spécificités imposées par le contexte ou l’environnement de déploiement (standards, protocoles, spécifications, ..)