Conception et mise en oeuvre d’une plate-forme pour la sûreté de fonctionnement des services Web

Conception et mise en oeuvre d’une plate-forme pour la sûreté de fonctionnement des services Web

Notions de Sûreté de Fonctionnement 

Avant d’aborder l’analyse des architectures orientées services, nous allons rappeler rapidement la terminologie que nous utilisons dans la suite du document pour décrire les notions fondamentales de sûreté de fonctionnement. Cette terminologie et ces concepts sont empruntés à [6, 7]. La sûreté de fonctionnement d’un système est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans la qualité du service qu’il leur délivre. La finalité des recherches dans ce domaine est de pouvoir spécifier, concevoir, réaliser et exploiter des systèmes où la faute est naturelle, prévue et tolérable. Une défaillance du système survient lorsque le service délivré dévie de l’accomplissement de la fonction du système, c’est-à-dire de ce à quoi le système est destiné. Une erreur est la partie de l’état du système qui est susceptible d’entraîner une défaillance, c’est-à-dire qu’une défaillance se produit lorsque l’erreur atteint l’interface du service fourni, et le modifie. Une faute est la cause adjugée ou supposée d’une erreur. On voit donc qu’il existe une chaîne causale entre faute, erreur et défaillance, représentée dans la Figure 1-1. Figure 1-1: Chaîne causale entre faute, erreur et défaillance Notons que dans les systèmes auxquels nous nous intéressons, qui sont formés par l’interaction de plusieurs sous-systèmes, les notions de faute, d’erreur et de défaillance sont récursives : la défaillance d’un sous-système devient une faute pour le système global (c.f la Figure 1-2). Figure 1-2: Récursivité de la chaîne causale faute => erreur => défaillance 

La tolérance aux fautes 

Pour que le système soit digne de confiance, et que cette faute ne se propage pas jusqu’au service délivré aux utilisateurs, on peut combiner un ensemble de méthodes qui peuvent être classées comme suit: – la prévention des fautes, qui permet de limiter l’introduction de fautes pendant la phase de développement; – la tolérance aux fautes, qui a pour objectif d’éviter la défaillance du système en utilisant des techniques de détection ou de recouvrement d’erreur; – l’élimination des fautes, qui réduit la présence (nombre, sévérité) des fautes. Pendant la phase de développement, elle consiste à vérifier, diagnostiquer et corriger les fautes. Lors de l’utilisation, il s’agit de maintenance corrective ou préventive. – la prévision des fautes, qui estime la présence et les conséquences de fautes par des tests prenant en compte leurs activités et leurs occurrences; Parmi ces méthodes, la tolérance aux fautes peut être mise en œuvre par le traitement des erreurs et des fautes. Le traitement d’erreur est destiné à éliminer les erreurs, si possible avant qu’une défaillance ne survienne. Le traitement de faute est destiné à éviter qu’une, ou des fautes ne soient activées à nouveau. Le traitement d’erreur fait appel à trois primitives: – détection d’erreur, qui permet d’identifier un état erroné comme tel; – diagnostic d’erreur, qui permet d’estimer les dommages créés par l’erreur qui a été détectée et par les erreurs éventuellement propagées avant la détection; – recouvrement d’erreur, qui permet de substituer un état exempt d’erreur à l’état erroné. L’un des apports de nos travaux est de proposer des mécanismes permettant de détecter, de signaler ou de recouvrer une erreur d’un composant particulier, le Service Web, afin d’éviter qu’elle ne se propage au reste du système.

La caractérisation 

Un système ne défaille pas toujours de la même manière, ce qui conduit à la notion de mode de défaillance, que l’on peut caractériser suivant trois points de vue : le domaine de la défaillance, la perception des défaillances par les utilisateurs du système, et les conséquences des défaillances sur l’environnement du système. Concernant le domaine de défaillance, on distingue: – les défaillances en valeur, quand la valeur du service délivrée ne permet plus l’accomplissement de la fonction du système; 19 – les défaillances temporelles, quand les conditions temporelles de délivrance du service ne répondent pas aux besoins des utilisateurs. Les modes de défaillance par arrêt sont relatifs à la fois aux valeurs et aux conditions temporelles: l’activité du système n’est plus perceptible aux utilisateurs. On distingue une absence d’activité par figement (quand l’état des sorties reste constant), et par silence (dans un système réparti, le noeud concerné n’envoie plus de message).

Les Architectures Orientées Services (AOS)

 L’architecture orientée services est le terme utilisé pour désigner un modèle d’architecture pour l’exécution d’applications logicielles réparties. Les deux derniers modèles (CORBA et DCOM) relèvent de l’architecture par composants logiciels répartis plutôt que de l’architecture orientée services, et le terme « service » est généralement absent de leur terminologie (sauf, par exemple, dans CORBA où l’on parle de services CORBA à propos de fonctions offertes par la plate-forme middleware aux composants applicatifs). De plus, un des avantages des AOS réside dans le fait que les applications réparties n’ont plus besoin d’un système de middleware réparti commun pour communiquer, mais seulement des protocoles et des technologies de communications intéropérables sur Internet. Ces protocoles et technologies seront d’ailleurs présentés par la suite. Construire une architecture orientée services signifie donc d’abord concevoir une architecture en réseau de relations de services, entre applications réparties. La description d’une relation de services est formalisée par un contrat de services. Ce contrat décrit les engagements réciproques du prestataire et du client du service. L’émergence des technologies de Services Web est censée apporter un niveau d’interopérabilité très élevé avec un degré de couplage très faible et donc d’établir les fondations des architectures orientées services à haut niveau de configuration dynamique. Une architecture d’applications réparties faiblement couplées (ou avec un degré de couplage très faible) est constituée d’un ensemble décentralisé d’applications réparties autonomes (Services Web), lesquelles interagissent sur la base de protocoles de communications, et sont mises en oeuvre à l’aide de technologies ouvertes et non intrusives. Parmi les exemples visibles d’AOS, on peut citer la SNCF1 qui a mis en place ce type d’architecture pour son système de réservation (recherche d’horaire, demande de tarif, réservation, …) qui répond ainsi aussi bien aux terminaux des guichets des agences et gares qu’aux sollicitations du site web de commande en ligne. Cette partie a pour but d’éclaircir et de définir la notion de « service », de présenter les concepts de base des AOS, et enfin d’analyser les perspectives et problématiques d’un tel type d’architecture. 

Qu’est-ce qu’un service ? 

La notion de service fait remonter d’un cran le niveau d’abstraction auquel les développeurs d’architectures à composants ont été habitués. Traditionnellement, le composant est représenté par une boîte constituée de plusieurs facettes et/ou réceptacles (des entrées et 1 Voir : http://www.prnewswire.co.uk/cgi/news/release?id=110004 20 des sorties). Lorsqu’on parle de service, celui-ci est caractérisé par un point. Une interface, le contrat de service (le document WSDL) précise les messages d’entrée que peut recevoir ce point d’entrée pour réaliser la prestation. Une architecture orientée services peut donc être représentée par une interconnexion de multiples points d’accès (voir Figure 2). En résumé, la notion de service est le produit d’une démarche d’abstraction par rapport au logiciel qui l’implémente, au processus qui l’exécute et au port qui le localise. Cependant, le service reste un objet très concret et technique. La réalisation d’un service passe par des messages échangés, des transitions d’état et des actions que l’application cliente suppose assurés de la part de l’application prestataire du service. Les caractéristiques fonctionnelles, opérationnelles et d’interface d’un service sont consignées dans un contrat. Un Service Web n’est donc rien d’autre que la réalisation supposée de la prestation définie dans le contrat de service.

Le contrat de service 

Le contrat de service du modèle des AOS s’inspire directement du modèle des contrats professionnels de service. Il s’agit d’un document qui développe l’ensemble des points permettant de décrire et donc de définir la relation de service. Dans le monde des relations professionnelles, un contrat de service est un document comportant plusieurs parties et dont les éléments terminaux sont généralement appelés articles et clauses. Le contrat de service contient des articles et des clauses consacrés à des sujets tels que: l’identification des parties contractantes, la description de la prestation objet du contrat, les modalités d’exécution, les modalités d’interaction entre les parties (il est aussi courant que le contrat de service décrive les actions à entreprendre en cas de défaillance d’un des contractants ou d’impossibilité de réalisation de la prestation). Dans le monde des AOS, les éléments du contrat de service sont organisés en six thèmes majeurs (voir Figure 1-3): l’identification des parties, la description des fonctions du service, la description de l’interface du service, la description de la qualité de service, la description du cycle de vie du service et du contrat, la description des termes de l’échange.