Dans le chapitre I, nous avons précisé que ces travaux de thèse se positionnaient dans plusieurs projets de recherche et notamment le projet MISE1dont le but est de fournir un
Système d’Information de Médiation (SIM). Ce projet se base sur de nombreux travaux de thèse qui ont chacune produit des briques constituant l’architecture permettant la conception puis l’exécution du SIM (cf. Figure V.2) suivant trois niveaux qui s’enchaînent permettant respectivement l’obtention du modèle de collaboration, de la dynamique collaborative et du modèle du SIM. Ces trois niveaux sont regroupés sous l’appellation Design Time.
FigureV.2 – Les trois niveaux de conception du SIM dans MISE : Design Time Ces trois étapes de conception font écho aux trois types de sources d’évolution des processus collaboratifs (évolution du contexte, évolution du réseau, occurrence du dys- fonctionnement). Il est donc possible de redéfinir tout ou partie des processus colla- boratifs afin de les adapter au contexte de la collaboration à l’instant t. Ce choix est légitimé par le fait que la détection du besoin d’adaptation se fait sur la base de l’ana-
lyse des informations provenant à la fois du terrain de la collaboration, du système de traitement (les partenaires de la collaborations et le SIM) et du suivi de l’exécution des processus collaboratifs et de leurs effets réels. Avant d’étudier les conditions menant à un niveau d’adaptation en particulier, nous allons rappeler les principes et les mécanismes fondamentaux des trois niveaux du Design Time de MISE.
V.2.1 Modèle de collaboration
Dans cette première étape de la conception du SIM, il s’agit de recueillir et exploiter la connaissance relative à la collaboration que l’on souhaite établir. Comme évoqué en Section I.4.2.3 du Chapitre I, un méta-modèle intégrant les principaux concepts d’une situation collaborative au sens général (méta-modèle coeur) ou spécialisée (B2B, gestion de crise, etc.) est utilisé pour recueillir et formaliser cette connaissance. L’instanciation de ces concepts permet de caractériser la situation étudiée [Mu, 2012]. Ces instances servent à peupler l’« ontologie collaborative », dont la structure (concepts et relations entre les concepts) respecte le méta-modèle. Ainsi, il est possible de collecter et analyser les données permettant de décrire le contexte de la collaboration, les partenaires de la collaboration et les objectifs de la collaboration.
Comme présenté plus avant dans ce manuscrit, un éditeur a été créé afin de permettre la caractérisation d’une situation collaborative, suivant les concepts du méta-modèle [Mu, 2012]. L’introduction de nouvelles instances permet d’enrichir l’ontologie collaborative.
V.2.2 Dynamique collaborative
La cartographie de processus collaboratifs a été détaillée par Wenxin Mu dans ses travaux de thèse [Mu, 2012]. Cette cartographie regroupe l’ensemble des processus mé- tiers collaboratifs, permettant d’atteindre les objectifs de la collaboration (définis dans le précédent modèle collaboratif), à l’aide des fonctions métier mises à disposition par chacun des partenaires de la collaboration. L’établissement de la cartographie de pro- cessus se déroule en deux phases : (i) la sélection des combinaisons de fonctions métier parmi l’ensemble des fonctions disponibles chez les acteurs de la collaboration, et (ii) l’agencement des fonctions retenues dans le but de créer la dynamique collaborative qui sera par la suite exécutée.
La sélection des services exploite la notion de transitivité apportée par les liens sé- mantiques entre les instances des concepts dans l’ontologie collaborative. Afin d’éclaircir cette notion de transitivité, nous pouvons l’illustrer par un exemple issu du quotidien : « en train de préparer un repas de famille, M. fait fondre de la graisse de canard dans une casserole, qui prend soudainement feu. M. doit faire face à un feu de casserole. A sa disposition, elle a une planche à découper en bois. Or, un feu de casserole contenant de la graisse présente les mêmes risques qu’un feu de friteuse. Le meilleur moyen d’éteindre un feu de friteuse est de le priver d’air en couvrant ladite friteuse d’un couvercle de
casserole... élément que notre cuisinière n’a pas à portée de main ! Elle estime que sa planche à découper en bois aura les mêmes propriétés occultantes qu’un couvercle de
casserole. Elle se sert donc de sa planche à découper en bois pour éteindre son feu de
casserole. »
Les relations de proximité ou de similarité entre les instances permettent ainsi de sélectionner un ensemble d’activités (parmi celles proposées par les partenaires) qui peuvent répondre (totalement ou partiellement) aux objectifs de la collaboration.
La définition de l’enchaînement des fonctions métier passe dans un premier temps par l’étape nécessaire de priorisation des objectifs de la collaboration et par conséquent leur priorité de traitement. Dans un second temps, l’étude des entrées et sorties des services métier (définies dans l’ontologie de collaboration) permet d’établir une struc- turation entre les services grâce aux liens sémantiques qu’ils entretiennent [Mu, 2012] . Par exemple, soient les services B et A respectivement d’entrée Eb et de sortie Sa. Si
Sa est sémantiquement proche de Eb, alors A peut être considéré comme un possible
prédécesseur de B du point de vue du flux de messages entre les services.
Par ailleurs, il faut noter que la sélection des services métier a été réalisée du fait de leur couverture des objectifs de la collaboration. De fait et grâce aux liaisons assure et
contribue à entre les services métier et les objectifs, il est possible de savoir si les services
sélectionnés couvrent tout (assure) ou partie (contribue à) des objectifs pour lesquels ils ont été retenus. Il est alors possible de déterminer la nature des relations entre les services sélectionnés et la façon dont ils doivent être appelés : concurrents, il faut permettre le choix entre les services ; complémentaires, ils doivent s’exécuter en série ou en parallèle. Dans ce dernier cas, pour choisir entre série et parallèlisation, de nombreux critères sont étudiés comme (liste non exhaustive) la mobilisation des ressources, l’appartenance au partenaire, les effets sur l’environnement collaboratif, etc. Sur la base de ces critères, un ensemble de règles a été établi afin de pouvoir déduire le choix de séquencement entre des activités complémentaires.
L’utilisation conjointe de ces trois principes permet de dégager une structuration des processus en vue de répondre aux objectifs de la collaboration. Il faut souligner quand dans le cadre du projet MISE, les processus collaboratifs sont décrits suivant le forma- lisme BPMN.
La cartographie s’occupe également de classer les processus suivant les niveaux déci- sionnel, opérationnel et support [ISO, 2005a] [ISO, 2005b]. Si une fonction principale est une fonction de type décisionnel, alors elle sera placée dans le pool (conteneur au sens BPMN) des processus décisionnels. La démarche reste la même s’il s’agit d’une fonction de type support ou opérationnel. Dans le cas où une fonction principale inclut deux fonctions de type décisionnel, une de type opérationnel ou support, la fonction est alors placée dans le pool général (voir Figure V.3).
L’ensemble des fonctions des différents pools communique à l’aide de messages « ob- jectif », « rapport », « information ».
Figure V.3 – La cartographie de processus dans MISE 2.0, d’après [Mu, 2012]
Message « objectif » : il contient le résultat d’une décision prise au niveau décision-
nel. Ce message peut être envoyé vers les niveaux opérationnels et support, qui doivent atteindre les buts définis dans le message,
Message « rapport » : il transmet le résultat d’une action réalisée au niveau opé-
rationnel. Il sert à envoyer un rapport d’exécution au niveau décisionnel et/ou support : erreur d’exécution, exception, résultat, etc.,
Message « information » : ce type de message peut contenir n’importe quelle sorte
d’information (ressource, rapport, erreur, alerte, etc.).
V.2.3 Modèle du SIM
L’objectif de cette étape est l’obtention du SIM exécutable, suivant deux étapes : d’abord la sélection des combinaisons de services techniques répondant à la couverture fonctionnelle des activités métier parmi les services proposés par les acteurs de la col- laboration, puis l’agencement des services entre eux en respectant la logique imposée par la cartographie de processus BPMN obtenue précédemment, en vue de déployer des workflows exécutables.
La sélection des services se fait en utilisant les principes de la réconciliation syntaxo- sémantique (au niveau des services mais aussi des messages reçus/émis par ces services), telle qu’expliquée et détaillée dans les travaux de thèse de Nicolas Boissel-Dallier [Boissel- Dallier, 2012]. Chaque partenaire possède une ontologie de domaine qui représente ses activités, produits et données métier. Les ontologies des partenaires sont ensuite rappro- chées afin de créer des liens d’équivalence entre les concepts sémantiquement proches. Ce rapprochement permet la création d’une ontologie commune à l’ensemble des partenaires
de la collaboration et servira de base à la réconciliation des services. Une autre ontologie va quant à elle servir à la réconciliation des messages.
Le savoir-faire de chaque acteur est représenté par un ensemble de Web Services. L’utilisation du standard SAWSDL [Kopecký et al., 2007] au niveau des contrats des Web Services permet au partenaire dont il dépend de les annoter sémantiquement. En effet, SAWSDL ajoute des attributs aux différentes balises des fichiers WSDL et XML Schema (XSD) qui sont déjà présentes dans le contrat de service. Les annotations sé- mantiques sont sélectionnées depuis l’ontologie que nous avons évoquée précédemment. Les processus métier BPMN 2.0 (résultant de la caractérisation de la dynamique colla- borative) sont eux aussi annotés sémantiquement grâce aux champs disponibles.
La réconciliation syntaxo-sémantique est alors exécutée (via le moteur de réconci- liation) pour proposer, pour chacune des activités des processus, un ou plusieurs Web Services (Figure V.4). Chaque proposition fait l’objet d’une note (ou score) permettant de guider l’utilisateur dans le choix final du ou des Web Services réalisant une activité donnée. Il faut souligner le caractère n-m de cette réconciliation sémantique : plusieurs activités peuvent être assurées par plusieurs Web Services.
Figure V.4 – Principes de la réconciliation n-m des services
Une fois la réconciliation des services effectuée, l’étape de réconciliation des messages est réalisée (Figure V.5). Il s’agit ici de s’assurer de la compatibilité des données entrante et sortantes de chaque service vers les services suivants/précédents (dans la dynamique collaborative). Cette réconciliation va générer tous les fichiers XSLT en charge de réaliser les transformations de données nécessaires pour chaque échange de message entre les
services.
Figure V.5 – La réconciliation des formats de données des messages échangés entre les services : données liées et règles de transformation associées, d’après [Boissel-Dallier, 2012].
Cette étape terminée, les workflows exécutables sont générés et déployés sur un ESB embarquant un orchestrateur.
Maintenant que nous avons détaillé le contenu des trois étapes du Design Time de MISE et le principe de fonctionnement des outillages développés par [Mu, 2012] et [Boissel-Dallier, 2012], nous allons pouvoir examiner les trois recommandations d’adap- tation qui en découlent.