Architecture Orientée Services (SOA)
Gouvernance SOA : Principes de l'Architecture Orientée Service
L'architecture orientée service est une organisation du système informatique fondée sur l'identification et l'agencement des services et des messages assurant leur communication. Le service est ainsi l'unité d'oeuvre de l'architecture du système, tant dans les phases de spécification que de développement et de déploiement.
L'approche SOA intègre nativement les principes de modularité, d'interfaçage, de contractualisation, et d'interopérabilité. Elle assure ainsi une adaptation rapide du système d'information au regard des évolutions des besoins de l'entreprise.
Parallèlement, elle permet de capitaliser la mise en place de bonnes pratiques par l'élaboration d’une architecture de référence. Cette architecture de référence pourra également être utilisée pour répondre à des problématiques de convergence de systèmes.
"Mieux vaut une conscience tranquille qu'une destinée prospère. J'aime mieux un bon sommeil qu'un bon lit."
Victor Hugo
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Gouvernance SOA : métier ou informatique, à votre service !
Le service, la glu entre la MOA et la MOE
En urbanisation SI, pour la vue fonctionnelle, les métiers expriment leurs besoins sous forme d'ensemble de comportements qu'ils attendent du système. Ils modélisent et décrivent les fonctionnalités qui doivent à terme être supportées par le futur système.
La MOE (par exemple la DSI) a, quant à elle, pour tâche de regrouper sous forme de services les messages délivrant les informations demandées.
En architecture SOA (Service Oriented Architecture), un service est une unité de traitements cohérents et indivisibles qui coordonne un ensemble de messages et d'événements, dans le but de réaliser une ou plusieurs fonctionnalités.
Les services peuvent être mis en correspondance avec les opérations réalisées à chaque étape des processus métiers de l'entreprise. Les services se présentent ainsi comme point d'articulation entre les métiers et l'informatique. Les métiers les voient par le biais des fonctionnalités rendues, les informaticiens les voient en tant qu'éléments d'architecture du système.
L'architecture orientée service est une organisation du système informatique fondée sur l'identification et l'agencement des services et des messages assurant leur communication. Le service est ainsi l'unité d'oeuvre de l'architecture du système, tant dans les phases de spécification que de développement et de déploiement.
L'approche SOA intègre nativement les principes de modularité, d'interfaçage, de contractualisation, et d'interopérabilité. Elle assure ainsi une adaptation rapide du système d'information au regard des évolutions des besoins de l'entreprise. Parallèlement, elle permet de capitaliser la mise en place de bonnes pratiques par l'élaboration d’une architecture de référence. Cette architecture de référence pourra également être utilisée pour répondre à des problématiques de convergence de systèmes.
"Toute la vie est une affaire de choix. Cela commence par : "la tétine ou le téton ?" Et cela s'achève par : "Le chêne ou le sapin ?"."
Pierre Desproges
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Faites vos gammes : les design patterns de la gouvernance SOA
Canonical Expression ( gouvernance inventaire)
- Problème
- Comment le contrat d’un service peut il être systématiquement compris et interprété ?
- Un contrat peut exprimer des capacités de différentes manières conduisant à des inconsistances ou risque de mauvaise interprétation.
- Solution
- Les contrats de services sont standardisés en utilisant des conventions de nommages
- Application
- Les conventions de nommage sont appliqué aux contrats de services coté analyse formelle et conception de processus
- Impacts
- L’utilisation de conventions de nommage doit être systématique et renforcé dans les grandes structures.
"Un homme n'est pas dévoré parce qu'il a l'ambition, mais parce qu'il est dévoré."
Gouvernance SOA : lachez tout !
Le couplage lâche, c’est une évidence, la logique d’un service est, par nature, fortement liée à son environnement :
Tout d’abord, la logique d’un service est directement dépendante de son implémentation (1). Cette implémentation s’appuie sur un ensemble de ressources qui constituent l’environnement d’implémentation du service. La logique d’un service est donc couplée à ces ressources.
De la même façon, la logique d’un service est fortement liée aux technologies sur lesquelles son implémentation s’adosse (2).
D’autre part, dans le cadre de services composites, la logique d’un service est également dépendante des services qui le composent (3).
Enfin, le contrat de service ainsi que sa logique peuvent être couplés aux processus qui les utilisent (4).
Ces couplages sont inévitables.
Le contrat d’un service et sa logique peuvent être couplés de deux façons différentes :
Couplage du contrat de service vers la logique d’implémentation du service (B) :
De la même façon, la logique d’un service est fortement liée aux technologies sur lesquelles son implémentation s’adosse (2).
D’autre part, dans le cadre de services composites, la logique d’un service est également dépendante des services qui le composent (3).
Enfin, le contrat de service ainsi que sa logique peuvent être couplés aux processus qui les utilisent (4).
Ces couplages sont inévitables.
Le contrat d’un service et sa logique peuvent être couplés de deux façons différentes :
Couplage du contrat de service vers la logique d’implémentation du service (B) :
- Un tel couplage résulte d’une approche contract last lors du design du service (le contrat dérive de l’implémentation). Cette approche, nous allons le voir, est à proscrire car elle induit un couplage du contrat avec l’environnement du service.
- Ce couplage dénote une approche contract first dans la conception du service (le contrat est écrit préalablement à l’implémentation du service). Cette approche est toujours préférable et le couplage du service vers son contrat est considéré comme un couplage positif.
Les consommateurs d’un service sont liés au contrat de ce dernier, et ne doivent être liés qu’à celui-ci (Pas au service lui-même).
C’est ce que l’on appelle le couplage lâche.
Or, si le contrat est couplé avec la logique du service (B), les consommateurs vont hériter par transitivité de l’ensemble des dépendances de la logique du service avec son environnement.
Nous nous retrouvons donc avec des consommateurs qui sont fortement couplés au service.
C’est pourquoi il est préférable d’établir le couplage du service vers son contrat (A).
Les équipes en charge de la conception des consommateurs ne sont pas nécessairement au courant du couplage du contrat à la logique (B). Ainsi, une telle situation aboutit à un ensemble de couplages non désirés et ignorés des consommateurs à l’environnement du service.
La prolifération de tels couplages est catastrophique car ils fragilisent et rendent moins flexible l’ensemble de l’architecture de service (SOA). C’est pourquoi, les approches contrat last sont à proscrire.
À l’inverse, les approches contrat first sont à encourager car elles permettent d’imposer (via le contrat) un couplage lâche des clients au service, permettant ainsi l’évolution des implémentations sans impact sur les consommateurs.
- Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
- Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
- Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
- Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
- Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
- Composabilité : Un service doit être conçu de façon à participer à des compositions de services.
"Le contentement apporte le bonheur, même dans la pauvreté. Le mécontentment apporte la pauvreté même dans la richesse."
Le contrat standardisé (suite)
Le contrat standardisé, standardiser pour faciliter la communication
- Le contrat de service est donc une notion complexe qui ne se limite pas à la (simple) définition d’interfaces.
- Un contrat de service est constitué de nombreux éléments (techniques ou non) qui forment un fond documentaire pour lequel il est préférable (voire indispensable) de respecter un formalisme commun.
- L’utilisation de ce formalisme commun est le meilleur moyen de construire un modèle cohérent et donc facile à comprendre et à partager.
- La notion de contrat de service standardisé ramène à celle de contrat first qui est, comme nous l’évoquions dans notre billet sur l’interopérabilité des Web Services (sans, une fois de plus, limiter la notion de service à ceux-ci), la meilleure approche de conception de services (voire la seule valable ?).
- Dans cette approche, les contrats font l’objet de développements spécifiques en amont de l’implémentation de la logique du service.
- Le développement de ces contrats doit se faire suivant des règles de standardisation établies pour l’ensemble des services d’un même Système Technique.
- Centraliser pour encourager la réutilisation
- En plus de cadrer la définition des contrats (et donc de faciliter la communication), l’utilisation d’un formalisme commun et de règles de standardisations facilite la centralisation des éléments constituant les contrats. Cette centralisation encourage la réutilisation. Parmi les constituants des contrats de services, deux sont de particulièrement bons candidats à la réutilisation :
- Les règles d’utilisation (policies) :
- Les contraintes de sécurité, d’encodage, de versioning sont souvent communes à l’ensemble (ou à un sous-ensemble) des services d’un domaine. De la même façon, les règles métiers sont rarement applicables à un seul service.
- Les formats de données (XSDs) :
- Il est évident que les types et formats de données sont utilisés par plusieurs services. Ces derniers ont même vocation à être utilisés au-delà des services : les types et formats de données sont souvent les mêmes pour les invocations synchrones de service et pour les échanges asynchrones, par exemple au travers d’un bus.
- Pour rendre possible leur réutilisation, il est indispensable de séparer les différents éléments du contrat de service. Plusieurs WSDL pourront ainsi appliquer les mêmes règles (policies) et manipuler les mêmes types de données (XSDs).
-
L’isolation des différents constituants du contrat de service en vue de leur réalisation est une bonne pratique qui tient du bon sens.
-
Il n’est pourtant pas rare de voir des déclarations de type (XSDs) au sein d’une WSDL plutôt qu’un import.
-
Cette approche est aussi aberrante que la re-déclaration en inner class de l’ensemble des types de données manipulés par un Bean (Cette pratique doit être restreinte à des cas bien spécifiques et constituer une exception).
-
La standardisation des contrats de service est donc un élément fondamental de la mise en œuvre d’architectures orientées services (SOA). En effet, la mise en place des bonnes pratiques évoquées dans ce billet offre des gains importants sur deux axes clés :
- Faciliter la communication et le partage de la connaissance :
- La définition d’un ensemble de principes communs de conception des contrats (ex. : conventions de nommage claires pour les entités, les attributs et les relations) permet d’aboutir à un modèle plus cohérent et donc plus facile à comprendre, partager, (ré)utiliser.
- Encourager la réutilisation :
- L’isolation et la centralisation des différents constituants des contrats de services facilitent indéniablement leur réutilisation.
-
Il ne faut pas perdre de vue que la définition de certains de ces éléments dépasse le simple cadre des contrats de service.
-
Il est par exemple souhaitable que les types et formats de données manipulés par les services soient également utilisés au sein des flux d’intégration.
-
Cette pratique, même si la définition d’un Modèle de Données Canonique reste un exercice difficile, est un gage sur le long terme de maintenabilité, de stabilité et de pérennité.
"Si tu veux être heureux pendant une heure, fais une sieste. Si tu veux être heureux pendant une journée, va à la pêche. Si tu veux être heureux toute ta vie, aide ton prochain."
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Un bon contrat, n'est pas un contrat signé mais un contrat standardisé
Le contrat de service définit un accord entre le fournisseur et le consommateur. Il est composé :
- D’un contrat syntaxique qui propose une représentation technique du service :
- Il constitue le contrat d’utilisation du service (son interface). Il présente le nom du traitement, ses paramètres d’entrée et de sortie et les contraintes structurelles (format et contrainte sur les données) qui s’y appliquent.
- D’un contrat sémantique qui fournit une description informelle du traitement:
- Il précise les règles et contraintes d’utilisation du service : La valorisation des messages de réponse (0 représente-t-il le résultat d’un calcul, une erreur, une interruption de service ?) ; Les exceptions ; les pré et post conditions techniques (ex. : volume des données échangées) ou métiers (ex. : écriture comptable équilibrée).
- D’un contrat de niveau de service (QoS & SLA) qui précise les engagements du service :
- Il spécifie par exemple le temps de réponse maximum attendu, les plages horaires d’accessibilité, le temps de reprise après interruption, les procédures mises en œuvre en cas de panne, les procédures de prise en charge du support, …
Par exemple, lorsqu’un service est implémenté sous forme de Web Service (nous parlons bien ici d’un exemple ; il ne faut pas confondre service et Web Service), son contrat est composé :
- D’une WSDL qui décrit les modalités d’accès au(x) service(s)
- La WSDL fait partie du contrat syntaxique. Elle fournit l’interface du service.
- D’un ensemble de XSD qui définissent les types de données échangées par le service :
- Les XSD font partie du contrat syntaxique. Elles définissent les formats de données et les contraintes structurelles. Les XSD font également partie du contrat sémantique. En effet, la richesse des types et restrictions XSD permet d’auto-documenter les valeurs possibles et permet souvent d’éviter des quiproquos.
Le contrat standardisé se compose :
- d’un ensemble de policies qui définissent les règles d’utilisation du service :
- Les policies font parties du contrat sémantique. Les règles et contraintes qu’elles expriment adressent des domaines variés : Sécurité, encodage, langue, versioning, métiers, …
- De documentations complémentaires.
- Ces documentations complètent le contrat sémantique. C’est par exemple dans les spécifications que l’on décrira les pré et post condition d’utilisation du service (elles ne sont pas toutes implémentables sous forme de policy).
- Ces documentations constituent le contrat de niveau de service (QoS & SLA). Notons que l’on parle bien d’un contrat qui définit un ensemble d’indicateurs et de valeurs seuils. Il n’est pas question ici des moyens techniques à mettre en œuvre pour leur supervision (traces, alertes, …).
"La parole qu'on prononce doit être comme le rubis, peu pesante, mais de grand prix"
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Gouvernance SOA : la phase de Change Time
Cohabitation de versions
Des services déployés en phase Run Time peuvent être changés pour s’adapter aux nouvelles exigences métier
Gestion des versions
- Règle 1
- Le message XML contient un numéro de version afin de permettre le contrôle du flux XML en production
- Via le namespace (espace de nommage) si non compatible ascendant
- Via l’attribute version XML si compatible ascendant
- Règle 2
- Le fournisseur doit favoriser la compatibilité ascendante
- Une nouvelle version N n’impacte pas les Consommateurs de la version N-1 (pas toujours possible)
- Règle 3
- Distinguer le cas d’une release sur les opérations (WSDL) et le cas d’une release sur les données (schéma XML)
Les contrat de services
- Expose une définition abstraite
- Nom du traitement
- Paramètres du message d’entrée et du message de réponse
- Nom, format, facettes de contraintes
- Exceptions (erreurs)
- Pré-conditions et post-conditions
- Expose une (des) définition(s) concrète(s) liée(s) à la définition abstraite (bindings techniques)
- Format techniques des messages
- Protocole de transport des messages
- En exploitation il faut garantir que les clauses du contrat sont exécutées… et pas d’autres
- Il faut découpler la validation du service de son code
- On peut utiliser :
- Un moteur de règles comme IBM - ODM (Operational Decision Management) ou JBoss BRMS (Business rules Management System) ou Drools pour la version open source de JBoss BRMS.
- WS-Policy - Xpath
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Gouvernance SOA : la phase de Run Time
Gouvernance Run Time basée sur les politiques
Après les étapes de développement et déploiement, les services se trouvent dans un environnement opérationnel où ils vont être exploités par d’autres applications et services.
- Comment peut-on être sûr que les différents composants d’un service (WSDL, SLA, XSD, SOAP, etc.) sont utilisés comme prévu ?
- Comment gérer le flux des messages échangés par les services ?
- Comment déceler les problèmes de performance, de fiabilité et de sécurité ?
Trouver des réponses aux questions de ce type est justement le domaine de compétence de la gouvernance Run-Time qui se focalise sur plusieurs activités de gestion de services,
- le monitoring des contrats,
- la gestion des processus métier,
- l’implémentation de la sécurité des messages
- la gestion de la qualité (QoS).
Politiques de gouvernance, sachant que dans un contrat de service le rôle des interfaces est celui de décrire les capacités fonctionnelles ainsi que les messages et les protocoles de communication, SOA a besoin d’un composant supplémentaire qui permette de décrire comment les consommateurs doivent« converser » avec le service.
En effet, grâce aux interfaces du service le consommateur est informé sur les capacités fonctionnelles de celui-ci ainsi que des contraintes relatives aux messages qu’il doit lui envoyer et ceux qu’il recevra en retour.
Cependant, ces informations se limitent à décrire ce qu’un service est capable de faire tout en omettant les aspects de sécurité et de qualité des services.
Les politiques sont considérées comme des simples règles et des contraintes permettant de dicter la manière dont une application ou un service doit se comporter
En effet, pour dicter une politique (règle) on procède généralement en suivant deux approches distinctes, à savoir l’approche procédurale et l’approche déclarative. Dans la première, l’application d’une politique est définie par l’occurrence d’un événement précis, suivie d’une ou plusieurs opérations à réaliser.
Un exemple typique du style procédural est celui représenté par les clauses « if/else » utilisées dans les langages de programmation.
Avec l’approche déclarative, les règles sont exprimées d’une manière plus générale qu’auparavant, ce qui permet de dire quelles actions doivent se réaliser ou pas.
Une liste blanche de sites web peut être vue comme un ensemble de règles déclaratives qui clarifient quels sites web peuvent être visités. Par la même occasion, elle interdit l’accès aux sites ne se trouvant pas dans cette liste d’accès.
La gouvernance SOA fait un usage exhaustif des systèmes de gestion de politiques pour garantir la flexibilité de l’architecture et des services SOA.
Dans le domaine de la gouvernance SOA on distingue plusieurs types de politiques
- Les politiques de sécurité qui règlent les aspects de confidentialité, intégrité et contrôle d’accès, aussi bien au niveau de la couche de transport que de la couche des messages.
- Les politiques de routage permettant de gérer le flux des requêtes entrant et sortant pour garantir ainsi que les demandes adressées à un service sont en conformité aux politiques d’utilisation.
- Les politiques sur les niveaux de services qui concernent tous les aspects de la qualité d’un service comme la performance, la fiabilité, la disponibilité et le temps de réponse.
Un système composé d’une interface utilisateur (console ou graphique) permet de définir et de modifier les politiques de services d’une manière complètement découplée et flexible.
Lorsqu’un Service Manager désire créer ou modifier une politique, il peut se connecter à l’interface « Policy Mangement » pour effectuer les changements dans une approche déclarative, sans besoin d’ajouter du code de programmation.
Ensuite, il peut stocker les politiques dans la base de données « Policy Repository » qui peut aussi exister sous la forme d’annuaire LDAP.
Le moteur de traitement des politiques est représenté par le composant « Policy Decision Point (PDP)» qui instancie, analyse et exécute les règles contenues dans le composant « Policy Repository ».
Après le traitement d’une politique donnée, le PDP communique son résultat (sa décision) au « Policy Enforcement Point (PEP)» pour que ce dernier puisse renforcer son application auprès des clients et fournisseurs de service.
Toutefois, le PEP peut aussi consulter directement le Repository sans passer par le serveur de politiques (PDP).
La gouvernance Run-Time peut garantir la conformité des requêtes aux contrats de services définis entre les clients et fournisseurs.
Chaque demande de service arrivée au PEP est comparée aux paramètres définis dans le SLA correspondant, ce qui permet de déterminer s’il s’agit d’une requête valable au niveau de chaque élément d’un contrat de service (politiques, SLA et interface).Gouvernance SOA : la phase de Design Time (5)
Gouvernance Design Time des SLA
Un exemple de gouvernance Design-Time consistant à définir le format d’une SLA.
Dans un premier temps un gestionnaire de service fixe le contenu standard des accords de niveaux de service qui seront appliqués à un groupe de services web.
Les SLA résident dans le référentiel (Repositories) et pointent vers les services concernés.
Malgré la particularité de chacune des SLA, l’utilisation des métadonnées permet de garantir un contenu consistant à l’échelle de l’entreprise.
Il est aussi possible de configurer le SLA d’un service spécifique nécessitant, par exemple, l’implémentation des contrôles de sécurité tels que les mécanismes d’identification et de contrôle d’accès.
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Gouvernance SOA : la phase de Design Time (4)
Processus de développement et management des SLAs
Dans ce contexte, plusieurs éléments sont importants aux yeux de la gouvernance Design-Time, notamment les informations concernant
- la disponibilité,
- la qualité,
- la performance des services
- la qualité du support et de la stratégie de communication.
Généralement, la disponibilité est un concept qui exprime les besoins de base des clients qui est celui d’avoir le service disponible au moment précis et à l’endroit voulu.
Malgré la simplicité de ce concept, l’interprétation de la disponibilité peut poser des problèmes surtout lorsqu’on sait que SOA est hautement distribuée et que la fourniture d’un service peut dépendre d’une multitude d’éléments.
En effet, la disponibilité d’un service peut être partielle lorsque l’état du service est « disponible » mais que certains éléments rencontrent des problèmes, comme par exemple, lorsqu’un groupe de clients n’ont pas pu accéder au service ou certains composants réseaux ne fonctionnent pas.
D’autres détailles de disponibilité devraient être clarifiés lors de la signature des accords de services.
Par exemple, comment le client considère-t-il une augmentation sensible du temps de réponse.
La qualité d’un service est une mesure d’agrégation de l’ensemble des paramètres clés définis dans le SLA.
Elle permet par exemple d’avoir une idée claire sur le comportement générale d’un service concernant le temps de réponse, la disponibilité temporelle et physique et les fréquences d’erreurs.