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).A découvrir aussi
- Gouvernance SOA : la phase de Change Time
- Un bon contrat, n'est pas un contrat signé mais un contrat standardisé
- Le contrat standardisé (suite)
Retour aux articles de la catégorie Gouvernance SOA -
⨯
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 720 autres membres