Conception déclarative et Validation de Systèmes d information

Transcription

1 Proposition de sujet de Master Conception déclarative et Validation de Systèmes d information Résumé : De nombreux systèmes d information (SI) sont distribués sur le net, et font appel à des composants distribués : bases de données, services, etc. pour remplir leur tâche. En quelques décennies, le mode de gestion de tels systèmes est passé d une vision «système d information centralisé», avec contrôle d accès, le plus souvent localisé sur un seul site, à une vision «système distribué (par exemple sur le web) et ouvert», accessible depuis l extérieur par des requêtes, et réalisant ses tâches de manière compositionnelle, en agrégeant les contenus fournis par des sous-systèmes. Un des paradigmes en vogue actuellement pour la conception des S.I. est celui de «declarative data centric service». Les architectures logicielles de type «data centric services», sont des architectures distribuées, ouvertes à l extérieur, qui s échangent des données, et dans lesquelles le flot d exécution d un service dépend fortement des données manipulées. L aspect déclaratif est également très apprécié pour la conception : comme il est quasiment impossible de concevoir et maitriser le workflow complet d un système composé de multiples composants hétérogènes, ces systèmes sont définis de manière déclarative, c est-à-dire qu ils sont décrits à l aide de règles définissant quand et comment des données doivent être modifiées ou échangées. La définition de systèmes à l aide de règles permet de plus d impliquer des utilisateurs durant la conception du système, qui connaissent et utilisent un ensemble de «règles métier» sans pour autant savoir définir un SI complet et cohérent. Le sujet de master proposé consistera à étudier un modèle déclaratif, de type «règles de récriture communicantes» permettant une conception intuitive de systèmes centrés données, et l application de techniques de vérification.

2 Description du sujet : Les systèmes d information (SI) sont passés en une décennie d une vision très centralisée à une vision plus distribuée, s appuyant sur des services et des échanges de documents. Dans une organisation de système d information de type documents et services, les moyens de communication entre sites sont supposés fiables et fournis. Le plus souvent, il s agit du Web plutôt que d un réseau privé, au-dessus duquel les communications peuvent être sécurisées si nécessaire. Les systèmes ainsi construits restent cependant complexes : les informations conservées ne sont pas nécessairement localisées à un seul et unique endroit, et accéder à de l information doit parfois se faire à travers des invocations de services distants. L utilisateur ou le concepteur d un système d information utilisant un service n est pas nécessairement le concepteur de ce service, et peut très bien jouer un simple rôle d agrégateur de contenu, sans rien connaître de la mécanique interne des services qui lui fournissent des informations. Il est cependant habituel de disposer d une description des entrées et sorties d un composant, sous forme d interface. Enfin, ces systèmes d information distribués peuvent à leur tour jouer le rôle de fournisseur de contenu, en publiant des données dont ils sont propriétaires, des données agrégées d autres sites, ou en offrant de la puissance de calcul à des utilisateurs. Les SI doivent donc être pensés comme des systèmes ouverts, c'est-à-dire acceptant des requêtes venant de l environnement du système. Dans ce contexte, nous nous trouvons donc devant des systèmes d information distribués, ouverts, hétérogènes, parfois dynamiques, De tels systèmes sont difficiles à concevoir, car ils doivent tenir compte de composants extérieurs mais pourtant essentiels au bon fonctionnement du système. Les spécifications de ces composants externes n étant pas disponibles, ils sont souvent vus comme des boîtes noires. Un autre aspect non négligeable est que dans des SI, données et traitements s influencent mutuellement, et il est difficile, sinon impossible de séparer les aspects traitement des données et l enchainement des tâches et appels de services dans un système. Ainsi, une succession de traitements particulière peut se déclencher lorsqu une valeur seuil est produite lors de l invocation d un service (les données influencent le flot de contrôle du système), et inversement, l invocation de services dans un ordre donné, ainsi que les temps de réponse peuvent avoir un impact si un site utilise par exemple les données de la première réponse fournie. Dans un tel contexte, il est difficile de connaitre à l avance les flots de contrôle d un système d information. De tels systèmes sont souvent désignés par l appellation : «data centric services». Les data centric services sont plutôt définis comme des réactions à des événements, sans connaissance globale de l état complet du système. Comme il est très difficile de concevoir et maitriser le workflow complet d un système composé de multiples composants hétérogènes, ces systèmes sont définis de manière déclarative, c est-à-dire qu ils sont décrits à l aide de règles définissant quand et comment des données doivent être modifiées ou échangées. L aspect déclaratif est très apprécié pour la conception : la définition de systèmes à l aide de

3 règles permet de plus d impliquer des utilisateurs durant la conception du système, qui connaissent et utilisent un ensemble de «règles métier» sans pour autant savoir définir un SI complet et cohérent. Le sujet de ce stage est l étude de systèmes d information distribués, de type «declarative data centric services», définis par des ensembles de règles de récriture d information. Le formalisme envisagé est un ensemble de règles simples décrivant la logique des traitements locaux de l information, et les communications entres sites qui se produisent lors de tels traitements. Ce type de modèle peut être vu comme des règles de récriture communicantes. La définition de systèmes par règles a été proposé dans des formalismes tels que Active XML [1,3,5,6], et plus récemment Datalog communicant [2]. Le principe est de définir un ensemble de règles locales à chaque site du système, qui se déclenchent lorsque des pré-conditions sont satisfaites, et produisent en conséquence une récriture locale d information, et une communication d information à un certain nombre d autres sites (par exemple à travers l invocation de services). De tels modèles sont par exemple étudiés dans les business artifacts proposés par IBM [4]. Des formalismes de ce type sont particulièrement adaptés pour décrire la logique d un système, et sont très appréciés dans des SI de type bancaire [7], dans lesquels un agent doit réagir localement selon un ensemble de règles, mais pas nécessairement de manière déterministe, sans avoir connaissance d un workflow global dans lequel s inscrit sa tâche. Nous voulons développer des techniques de validation pour ces systèmes. Les questions que l on se pose sont, par exemple, si un système donné sous forme de règles ne viole pas certaines propriétés de sécurité, quelle que soit son utilisation (i.e. quel que soit l environnement dans lequel les composants définis par des règles sont placés). Ce type de problème est rapidement indécidable, et les règles communicantes ne devraient pas faire exception. Il semble donc conseillé de s attacher à des propriétés simples. Dans les systèmes de transactions par exemple, il est important de pouvoir vérifier que le système évite tout conflit d intérêt. Un exemple classique de conflit est lorsqu un client d un site web ne peut jouer le rôle de la banque garantissant sa transaction durant une session. Même pour des propriétés simples, il se peut que le raisonnement sur le formalisme des règles communicantes ne puisse se faire que modulo abstraction. Une autre question importante est de vérifier si un assemblage de composants particulier est correct. Cela nécessite de vérifier que les données envoyées lors d une invocation de service sont prévues par le composant fournissant de service, que les valeurs possibles renvoyées par un composant sont bien attendues par le composant appelant, et surtout que chaque invocation de service s achève bien par le retour des données demandées.

4 Profil recherché : Ce stage est ouvert à tout candidat motivé par les méthodes formelles et la vérification, mais également soucieux de l application des techniques formelles à des problèmes réels. Encadrants : Eric Badouel eric.badouel@inria.fr Loïc Hélouët loic.helouet@inria.fr Plan de travail : 1) Bibliographie : Le stage débutera par une étude bibliographique. On regardera particulièrement le modèle proposé dans [1]. En parallèle, le candidat sera formé sur des modèles plus classiques (automates, automates communicants, réseaux de Petri), et les techniques de vérification de propriétés : accessiblité, couverture. 2) Définition d un modèle de règles communicantes : Suite à sa bibliographie, le candidat devra proposer un modèle de modules de règles communicantes. On s attend à ce que le modèle proposé soit suffisamment expressif pour envisager des cas d étude (systèmes de vente en ligne, de gestion d enchères,.) 3) Techniques de vérification : Une fois le modèle défini, le stage abordera le problème de la vérification. Il semble raisonnable pour le type de modèle visé de regarder en priorité des propriétés de couverture (eg : «le système peut-il atteindre une configuration dans laquelle un client de moins de 18 ans est inscrit dans le fichier ClientsAdultes»). Les propriétés de couverture sont décidables pour de nombreux modèles, mais il est possible que les règles communicantes ne permette pas de décider de la couverture. Dans ce cas, on envisagera des techniques d abstraction ou des restrictions à apporter au modèle. 4) Extensions : Une fois les points 1,2,et 3 résolus, les techniques utilisées pourront être spécialisées pour réponde à des questions liées à la composition. Une des question que l on se pose est celle de la compatibilité des modules : i.e. les données échangées entre des modules sont-elles toujours celles attendues, et un service invoqué termine-t-il toujours? De même, on envisagera des techniques de vérification pour des systèmes dans lesquels certains modules ne sont connus que par leur interface, c est-à-dire vus comme des relations entre données d entrée et données de sortie d un service.

5 Bibliographie [1] Serge Abiteboul, Meghyn Bienvenu, Alban Galland, Emilien Antoine: A rule-based language for web data management. PODS 2011: [2] Serge Abiteboul, Luc Segoufin, Victor Vianu: Static analysis of active XML systems. PODS 2008: [3] Serge Abiteboul, Omar Benjelloun, Ioana Manolescu, Tova Milo, Roger Weber: Active XML: A Data-Centric Perspective on Web Services. Web Dynamics 2004: [4] Elio Damaggio, Alin Deutsch, Richard Hull, Victor Vianu, Automatic Verification of Data-Centric Business Processes, Business Process Management (BPM), [5] Benoît Masson, Loïc Hélouët, Albert Benveniste: Compatibility of Data-Centric Web Services. WS-FM 2011: [6] Loïc Hélouët, Albert Benveniste. Distributed Active XML and Service Interfaces. Research report INRIA, No 7082, [7] Hassan Ait-Kaci, A Sorted-Graph Unification Approach to the Semantic Web, WSFM 2011, invited talk. [8] Sidney Rosario, Albert Benveniste, Stefan Haar, Claude Jard: Probabilistic QoS and Soft Contracts for Transaction-Based Web Services Orchestrations. IEEE T. Services Computing 1(4): , 2008.