La phase de « Run-Time »

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.

Lorsque l’on a introduit le sujet des architectures orientée services dans la section 3 on a pu constater que SOA est caractérisée, d’une part, par une infrastructure déjà connu, comme celle constituée des serveurs d’applications, mainframe, et autres composants. D’autre part, elle ajoute d’autres éléments nouveaux, tels que les moteurs d’orchestration et les ESB qui auparavant étaient employés dans des contextes d’utilisation spécifiques. En plus, en fonction du modèle du service, celui-ci peut résider dans une ou autre couche de l’architecture et être en relation avec plusieurs composants internes et externes au domaine auquel il appartient.

Par conséquent, plusieurs questions se posent lorsque les services sont exécutés dans un environnement si complexe comme celui de SOA. Par exemple, on peut se demander :

 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, à savoir le monitoring des contrats, la gestion des processus métier, l’implémentation de la sécurité des messages et 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. Dans le but de combler ces défauts c’est qu’interviennent les politiques de gouvernance.

Dans [Ritu and Latha 2008, p. 26] on définit le concept de politique comme étant ;

«a mechanism to configure a behavior of software in ways that are not predictable at policy definition time».

Les politiques, dans leur forme la plus élémentaires, 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. Les significations les plus importantes se trouvant dans ces définitions sont celles communiquées par les concepts de règles et contraintes. 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.

Quant aux contraintes, il s’agit d’un concept très proche de celui de règle mais qui a une connotation beaucoup plus négative. Lorsque l’on exprime une politique sous la forme d’une contrainte c’est parce que l’on veut déclarer les limites physiques et logiques dont fait l’objet une ressource donnée. Cette dimension est en fait très importante dans le contexte de la gestion des services car elle permet de paramétrer plus facilement leur contexte d’exécution ainsi que les propres performances du service.

L’autre terme définissant précisément ce qui est une politique est celui de « mécanisme ». En effet, lorsque l’on se réfère aux politiques comme étant des mécanismes on veut dire par là qu’elles doivent être dynamiques plutôt que statiques. C’est d’ailleurs sur ce point que se situe la différence principale entre un paramètre de configuration et une politique de gouvernance.

Avec le premier, on peut paramétrer le comportement d’une application ou d’un dispositif donné en lui passant des valeurs connues au moment de la configuration du système. Pour qu’une telle approche se révèle efficace il faut que l’administrateur ait connaissance de tous les variables importantes décrivant le comportement attendu.

Dans le contexte de SOA, cela est loin d’être le cas, surtout dans les environnements où l’on a affaire à plusieurs clients et fournisseurs de services. Bien qu’il soit toujours possible de déterminer à l’avance la plupart des scénarios d’utilisation d’un service, la définition des mécanismes (système de politiques) est une approche beaucoup plus efficace que la configuration des valeurs statiques. Sans exclure l’utilisation des paramètres de configuration statiques, 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 parmi lesquelles on peut citer: 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. Ces politiques étant très souvent référencées dans les SLAs, les OLAs et enfin dans les contrats de sous-traitance. Indépendamment de ces types de politique, il est nécessaire de disposer d’une infrastructure permettant d’implémenter, déployer et maintenir les politiques de services SOA. Le besoin fondamental pour gérer efficacement les politiques est celui du couplage faible vis-à-vis des couches de services. Autrement dit, de la même manière que l’on découple les SLA et les interfaces des implémentations d’un service, on doit découpler aussi la gestion des politiques de gouvernance. Pour ce faire, SOA s’inspire des

systèmes de gestion de réseau basés sur les politiques dont l’architecture est illustrée dans la Figure 33. Comme on peut le voir, il s’git d’un système composé d’une interface utilisateur (console ou graphique) qui permet de définir et de modifier les politiques de services d’une manière complètement découplée et flexible. En effet, 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).

Policy Enforcement Point Policy Mangement

Services Layer

Policy Decision Point Policy Repository

?

Figure 33: GouvernanceRun-Timebasée sur les politiques [Cf. Ritu and Latha 2008, p. 31].

Avec un modèle de gestion des politiques comme celui de la Figure 33 la gouvernance Run-Timepeut 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 SLAs correspondante, 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).

La qualité des services par la sécurité

Les services en SOA sont développés pour répondre à des besoins bien précis en termes de qualité de service qui doivent être garantis pendant leur utilisation. Un service qui est sollicité

par une multitude de clients doit fonctionner d’une manière consistante et conforme aux paramètres de qualité qui apparaissent dans son contrat. Généralement, la qualité d’un service peut s’évaluer en tenant compte des éléments tels que la performance, la fiabilité, disponibilité et la sécurité. Pour garantir que chacun de ces éléments se trouve dans un état valable, la gouvernance Run-Time est chargée d’implémenter les processus de gestion sur lesquels sont basés la sécurité, le monitoring des processus et la résolution de problèmes liée à l’exploitation des services.

La gestion de la sécurité SOA est un domaine qui est pris en charge par la gouvernance SOA.

En effet, dans la phase Run-Time on implémente les stratégies de protection des services qui ont été définies dans le cadre de la gouvernance TI et pendant la phase Design-Time. Pour ce faire, elle peut déployer les stratégies de sécurité sur plusieurs niveaux de l’architecture, notamment au niveau des protocoles de transport et au niveau des messages. La gouvernance Run-Time doit donc implémenter les politiques d’authentification et d’autorisation destinée aux services SOA, ce qui oblige à prendre de décisions importantes concernant les mécanismes d’identification des utilisateurs. En principe, SOA utilise les mécanismes d’authentification existants comme par exemple, l’authentification via les certificats de la norme X.509, l’authentification dite de base utilisant un nom d’utilisateur et un mot de passe, le protocole Kerberos d’authentification d’utilisateurs et des services à l’intérieur d’un domaine spécifique et le standard SAML basé sur XML.

En plus des décisions concernant les mécanismes d’identification on doit tenir compte des besoins de confidentialité et d’intégrité de messages qui sont échangés entre les différentes parties. Comme pour l’authentification et l’autorisation, il existe aussi plusieurs mécanismes de sécurité qui sont utilisés pour protéger le contenu des messages. Parmi ces mécanismes on peut mentionner la signature des messages XML qui supporte l’intégrité de ces derniers ainsi que l’authentification de son émetteur. Le chiffrement des messages XML qui sert à garantir la confidentialité des messages en cachant son contenu par l’application des algorithmes de chiffrement. Tant l’authentification comme la confidentialité et l’intégrité des messages peut être implémentée en partie par les protocoles de transport sécurisés tel que SSL. En effet, ce protocole offre les services de sécurisation de messages mentionné ci-dessus mais il est dépendant du protocole HTTP, ce qui n’est pas recommandé dans un environnement comme SOA qui admet d’autres types de protocoles (SMTP, FTP, etc.).

Gateway

Figure 34: GouvernanceRun-Timedans la gestion de la sécurité des services.

La Figure 34 montre un exemple de gouvernanceRun-Timedans le contexte de la sécurité des services web. Il s’agit d’un exemple typique d’implémentation de la sécurité où trois consommateurs envoient des requêtes aux services web résidant dans une SOA. Le consommateur « A » envoie une requête avec un message SOAP qui est intercepté par un composant intermédiaire (Gateway) capable de faire appliquer les politiques de sécurité relatives aux services web. Dans cette passerelle on a défini une politique concernant surtout la validation des messages provenant de ce type de consommateur. Si le message s’avère conforme aux contraintes de validation alors il est autorisé à communiquer avec le fournisseur du service et le message est délivré à sa destination. Dans le cas du consommateur « B », le message n’a pas atteint sa destination et a été effacé parce qu’il ne correspondait pas aux exigences de sécurité. Cela peut survenir par exemple lorsque le consommateur envoi une requête via un autre canal que celui attendu par le point terminal. La passerelle se charge alors de renvoyer une réponse ^Soapfaultpour notifier les problèmes survenus ou tout simplement supprimer la connexion. Au niveau du consommateur « C », la politique de sécurité consiste à combiner l’envoie d’un message encrypté et signé via WS-Security et transporté par le protocole SSL. Comme dans les cas précédents la passerelle s’assure que les conditions de sécurité sont bien remplies et route les messages vers le destinataire de la requête.

Bien que dans la description cela ressemble assez évident, il faut compter sur l’occurrence de certaines conditions pour pouvoir appliquer les politiques de sécurité comme il a été fait ci-dessus. En effet, l’architecture basée sur une passerelle de sécurité fait souvent appel aux composant PEP et PDP mentionnées auparavant car en SOA la sécurité est gérée sous forme de politiques. Donc, grâce aux systèmes de gestion de politiques on peut faire appliquer les contraintes de sécurité aussi bien aux fournisseurs qu’aux consommateurs. A cela s’ajoute le

fait que dans le contexte distribué des services on peut rencontrer un grand nombre d’intermédiaire avant que le message n’arrive à destination. Dans une situation idéale, les consommateurs et le fournisseur communiquent en « point-to-point » mais la plus part du temps cela n’est pas possible et la sécurité doit être conservée « end-to-end ». Par conséquence il est important d’implémenter la sécurité de telle manière que le contexte de sécurité des messages ne soit pas perdu et l’échange d’information se fasse comme prévu dans le SLA.

L’implémentation de la sécurité peut encore devenir plus complexe, notamment avec l’intégration de services de processus appartenant à des organisations différentes. Lorsqu’un consommateur provenant de l’extérieur envoie une requête à un service on doit faire en sorte que ses attributs de sécurité restent transparents aux différents partenaires. Autrement dit, il faut pouvoir identifier le client pour établir une relation de confiance dans le partage de ces informations, tout cela malgré les différences dans les modèles de sécurité de chaque organisation concernée. Dans ce cas le défi est d’implémenter la portabilité des attributs de sécurité à travers les différents partenaires concernés. Par exemple, à l’aide du standard SAML et d’une passerelle comme celle illustrée dans la Figure 34.

La qualité des services par la performance et la fiabilité

Depuis la perspective de la gouvernanceRun-Timela qualité des services doit être garantie en gérant les aspects de performance et de fiabilité des services. La performance d’une SOA doit être évaluée à plusieurs niveaux, notamment au niveau des processus métier, au niveau des différents modèles de services et au niveau des applications sous-jacentes. Dans le cas des services de processus, les problèmes de performance se trouvent au niveau de la composition de services car dans un contexte comme celui-ci la charge de traitement est normalement plus élevée qu’avec un service simple.

Un bon modèle de gouvernance doit s’intéresser aux compositions de services depuis la phase de Design-Time pour éviter qu’un modèle de composition inefficace n’ait des répercussions en temps d’exécution (Run-Time). Par exemple, des services à granularité anormal, trop de membres dans une composition et un nombre important d’opérations (validation, transformation, etc.) exécutées par chaque membre, peuvent diminuer de manière sensible les performances d’un service de processus. Quant aux services d’application présentés dans la section 2.2, la performance doit être analysée en tenant compte des applications et systèmes sous-jacents. Ici, les problèmes de performances peuvent surgir des sources de données utilisées par les applications sous-jacentes. Autrement dit, si les opérations dans les bases de données deviennent trop lentes, les services d’application seront aperçus comme étant aussi lents que les applications qu’ils exposent, surtout dans les échangent synchronisés.

La performance dépend aussi de la quantité de données contenues dans les messages. Si pour des questions de sécurité on doit inclure dans un message un grand nombre d’informations supplémentaires, il est clair que le traitement du message prendra beaucoup plus temps que d’habitude. Le même problème peut venir des données attachées aux messages, ou de n’importe quelle autre approche susceptible d’augmenter la taille des messages. Par rapport à

ces derniers on peut encore dire qu’un volume trop important de messages peut avoir des incidences négatives sur la performance de l’architecture.

Or, face à ces nombreux risques, que peut faire la gouvernance Run-Time pour conserver la performance de SOA ? La première réponse à cette question consiste à développer un processus de gestion de la performance comme celui de la Figure 35. Dans cette dernière on illustre un processus défini dans le cadre du Framework ITIL qui contient les étapes nécessaires pour mesurer la performance d’un système ou d’un service informatique. La première étape, à savoir celle du contrôle, peut en effet être implémentée dans SOA par le monitoring des services. Les résultats ainsi obtenus sont ensuite analysés (étape 2) pour extraire les signaux ou les données clés qui permettent de détecter les problèmes liés à l’utilisation des services. Dans la troisième étape il s’agit de définir les différentes solutions applicables aux problèmes en question. Enfin, dans la dernière étape qui est celle de la mise enœuvre on implémente les solutions prédéfinies auparavant.

Figure 35: Processus de gestion de la capacité [Cf. Macfarlane and Rudd 2006, p. 55]

D’une manière plus concrète, le processus décrit ci-dessus n’est autre chose qu’un processus de monitoring permettant de gérer et de mesurer la performance d’un système informatique.

Dans le cadre de SOA, on utilise aussi le monitoring à plusieurs niveaux de l’architecture couvrant ainsi presque tous les domaines de celle-ci. Le monitoring étant un exercice d’observation et d’analyse de l’activité d’un système il représente une bonne solution pour déceler les problèmes de performance posés par les services et par SOA en générale. Donc, pour mieux maîtriser l’ensemble des activités dans une architecture orientée services, il est important de pouvoir déterminer les « points d’observation » les plus pertinents où le monitoring sera effectué. Dans SOA, le monitoring est pratiqué en suivant plusieurs approches différentes et complémentaires. La supervision des activités métier (Business Activity Monitoring) est un exemple de monitoring que l’on peut utiliser dans le cadre de la gouvernance Run-Time. Bien qu’il s’agisse d’un concept très différent, il est cependant très proche de SOA grâce au lien qu’il garde avec les services de processus. Concrètement cela

consiste à étudier de près les processus métier en collectant des informations provenant des systèmes d’information concernés par ces processus [Pulier and Taylor 2006, p. 91]. Les mesures collectées au niveau des processus métier sont interprétées au même niveau, cet-à-dire, au niveau des indicateurs de performance métier. En fonction des résultats mesurés, les propriétaires des domaines SOA peuvent ensuite définir des actions pour optimiser la performance des services.

Un autre point d’observation ayant une importance certaine dans la mesure de la performance SOA est notamment le message lui-même. En analysant le flux de messages on peut

Un autre point d’observation ayant une importance certaine dans la mesure de la performance SOA est notamment le message lui-même. En analysant le flux de messages on peut