Architectures Orientées Services
On regroupe sous la dénomination d’Architecture Orientée Services ou “Service Oriented Architectures” (SOAs), l’ensemble des architectures mettant en avant la notion abstraite de service pour la mise en œuvre d’une réalisation logicielle, répartie ou non.
De fait, la propriété de couplage lâche entre les principales entités de l’architecture est particulièrement recherchée dans les SOAs. Elle favorise des systèmes s’appuyant sur des couches de médiation, imposées par des standards, capables d’exhiber un certain niveau d’interopérabilité au niveau de leurs communications. D’un point de vue technique, ce couplage lâche induit alors d’effectuer le moins d’hypothèses possibles lors de la description des différentes entités en interaction.
Dans le cas des SOAs, cette approche est rendue possible par la cohérence des normes communément utilisées, avec notamment l’utilisation de modèles d’échanges pivots des données. Les architectures orientées services sont ainsi le fruit d’une lente maturation technologique s’appuyant sur les travaux précurseurs à la base des notions d’objets et de composants. Une compréhension préalable de ces concepts est nécessaire à l’obtention d’une plus fine appréhension des SOAs.
Service Web
La notion de service par elle-même est purement abstraite et ne s’encombre pas de considérations technologiques ; cependant, l’implantation la plus répandue de la notion de service est réalisée par les services Web. Bien qu’il n’existe pas de définition canonique de celle de service Web, nous nous reposons sur celle (suffisamment générale) proposée par Moreau [Moreau, 2009] :
Un service Web est une application autonome qui peut être utilisée et découverte par d’autres applications à travers un réseau. L’ensemble de ces mécanismes reposent sur des normes et technologies Web.
Cette définition, bien que générique, encapsule les principes fondateurs des services Web directement hérités du concept de service : le découplage et l’autonomie du service Web ainsi constitué.
Les services Web sont en effet des applications destinées à être utilisées en partie dans un cadre machine-à-machine de manière répartie sur le réseau. Les normes et technologies citées dans la définition sont celles que l’on retrouve usuellement dans le cadre du Web auxquelles sont ajoutées des spécificités propres aux domaines considérés.
De fait, le W3C se veut beaucoup plus spécifique d’un point de vue technologique, et introduit le langage WSDL pour la description des interfaces des services ainsi que SOAP pour la communication (le plus souvent via HTTP avec une sérialisation XML).
Par ailleurs, les services Web sont des composants sans état offrant un faible couplage. Afin d’y parvenir, des spécifications techniques pour la description et la communication ont été établies et associées aux services Web à des fins normatives.
L’émergence de spécifications propres aux services Web témoigne de l’implication des industriels dans ce nouveau paradigme, ces derniers cherchent ainsi à faire collaborer leurs grands systèmes répartis au travers du Web. Ces spécifications peuvent être divisées en deux groupes : normes de bases et normes complémentaires.
Service Web sémantique
On qualifie de sémantique un service Web mettant en œuvre des technologies issues de la récente rencontre entre le monde des services Web et celui du Web sémantique [Berners-Lee et al., 2001]. Ainsi, si les normes et spécification de services Web que nous avons précédemment abordées fixent un cadre syntaxique à leur utilisation, et ceci en répertoriant les fonctionnalités et les données de ces services de manière rigoureuse et réutilisable, le Web sémantique s’efforce quant à lui de les rendre “intelligible” par un programme informatique. Cette notion va ici se traduire par la capacité d’un programme à mener à bien des raisonnements complexes, de manière autonome, sur des méta-informations (ou “méta-données”) venant caractériser les fonctionnalités et les données des services Web.
D’un point de vue technique, une offre de service Web (donc son interface sur le monde extérieur) est décrite en WSDL. Les informations contenues par cette description sont d’ordre technique (l’adresse du service, le protocole utilisé pour la communication, etc.) et fonctionnel (quel service est rendu par cette entité, caractérisé par ses méthodes et le type de ses données), mais vont, en tout état de cause, se présenter sous la forme d’informations syntaxiques : la forme des méthodes et données est décrite, mais pas leur fond.
Une première étape à la description du “fond” des services par rapport à leur “métier”, et donc du sens accordé à leurs méthodes, données, et même aux services eux-mêmes dans leur ensemble, fut de porter des méta-informations, dans les balises de commentaires prévues à cet effet au sein des offres de services. Cependant, cette sémantique primitive ne permet pas l’interprétation autonome des méta-données par un programme puisque les commentaires sont, par nature, destinés à être lus par un opérateur humain : elles ne peuvent que servir de documentation ou de guide pour un ingénieur. La jonction avec les travaux du Web sémantique s’effectue alors dans une volonté commune d’élever ses méta-informations au rang de véritable sémantique métier librement interprétables par une machine :
le langage naturel dans lequel sont dépeints les commentaires étant particulièrement mal adapté à un traitement automatique, ces travaux proposent alors de décrire les méta-données de manière formelle, pour certains à l’aide d’ontologies fondées sur la logique de description [Kutz et al., 2003], tel que rendu possible par le langage OWL-DL [Welty et McGuinness, 2004].
Des liens étroits avec les SOA Sémantiques et nos travaux
En tout premier lieu, une particularité de l’approche mise en œuvre dans ce cas d’utilisation est d’effectuer un rapprochement entre la notion de “moyen” ou “ressource” et celle de service, au sens SOA du terme. En effet, à chaque ressource considérée (par exemple drone, camion, pompier, etc.)
est associée une représentation sous forme de service sur le réseau interne du système d’intervention. Les interfaces de chacun de ces services permettent de leur envoyer des ordres, et leurs offres de service publiées dans un registre à disposition de tous, exposent aussi bien leurs caractéristiques statiques fonctionnelles que non-fonctionnelles. A cette utilisation des services pour représenter les moyens, s’ajoute celle de processus métier pour spécifier les protocoles de lutte anti-incendie qui exploiteront, à l’exécution, ces services.
Les principales caractéristiques des SOA Sémantiques apportent également des éléments de réponse pour faire face aux problématiques courantes d’interopérabilité et de composition de services dans un contexte de gestion de crise. Ces éléments de réponse se fondent sur :
La formalisation des connaissances propres à chaque corps de métier sous forme de bases de connaissances (par exemple ontologies). On obtient ainsi un modèle sémantique de chaque domaine, voire un modèle de connaissances commun à tous les acteurs.
L’utilisation de ces connaissances de haut niveau lors de la spécification des offres de services et de leurs demandes dans les processus métiers, sous forme de méta-données.
L’exploitation de ces méta-données à l’exécution, ce qui permet d’élargir considérablement le champs et la pertinence de la recherche de services lorsque la crise survient : la jonction entre un producteur et un consommateur de besoin est alors effectuée dynamiquement sur la base de critères sémantiques plus souples que les critères syntaxiques.
Cependant, si l’approche SSOA par elle-même amène effectivement un niveau certain d’agilité lors de la réponse à la crise, elle n’est pas sans contraintes et doit être consolidée pour être réellement exploitable sur le terrain. Plus spécifiquement, il ne suffit pas d’exploiter les informations sémantiques une fois pour toute lors du filtrage statique des services disponibles dans un annuaire, il faut au contraire exploiter l’élasticité du lien entre producteurs et consommateurs de service pour y ajouter de la dynamicité. En réponse à ces limitations, nous proposons alors :
l’implantation d’une architecture pour l’orchestration véritablement dynamique des services, car ces derniers peuvent apparaître et disparaître à tout moment lors de l’exécution (nouveaux arrivants, destructions de matériel, etc.) ;
la prise en compte des informations courantes de Qualité de Service lors de l’exécution des processus métiers, et la mise au point d’outils pour discriminer efficacement entre les services disponibles sur la base de ces informations. Cette approche permet alors, via la satisfaction des préférences spécifiées par les utilisateurs, une optimisation des délais d’intervention et de la répartition des ressources.
|
Table des matières
Chapitre 1 :Introduction
1.1 De l’approche à objets au paradigme de service
1.2 Genèse d’une problématique
1.3 Objectifs de recherche et approche poursuivie
1.4 Contributions scientifiques
1.5 Organisation du document
Partie I Contexte et Etat de l’Art
Chapitre 2 :Contexte technologique
2.1 Architectures Orientées Services
2.1.1 Concepts de base
2.1.2 Service Web
2.1.3 Service Web sémantique
2.1.4 Composition de services Web
2.2 Processus métier
2.2.1 Normes de conception
2.2.2 Norme d’exécution : BPEL 2.0
2.3 Propriétés et contraintes non-fonctionnelles de services
2.3.1 Taxonomies et ontologies de QoS
2.3.2 Politiques
2.3.3 Contrats de Qualité de Service
2.4 Conclusion
Chapitre 3 :Etat de l’Art
3.1 De l’approche linguistique pour raisonner
3.1.1 Modélisation floue des concepts
3.1.2 Raisonnement flou
3.1.3 Formalismes à base de 2-tuples
3.2 De la modélisation compacte de préférences
3.2.1 Modèles linguistiques
3.2.2 *CP-Nets
3.2.3 Réseaux GAI
3.2.4 Synthèse
3.3 De la composition dynamique de services sous contraintes non-fonctionnelles
3.3.1 Gestion de la dynamicité par recomposition
3.3.2 Composition par génération de processus alternatifs équivalents
3.3.3 Composition dynamique dirigée par CP-nets
3.3.4 Synthèse
3.4 Conclusion
Chapitre 4 :Un cas d’utilisation en gestion de crise environnementale
4.1 Introduction
4.1.1 Contexte d’intervention
4.1.2 Phases principales en gestion de crise
4.2 Des liens étroits avec les SOA Sémantiques et nos travaux
4.3 Déroulement du cas d’utilisation en lutte anti-incendie
4.3.1 Scénario 1 : définition des offres services
4.3.2 Scénario 2 : définition d’un processus abstrait de gestion d’incendie
4.3.3 Scénario 3 : élicitation de préférences utilisateur spécifiques à la crise
4.3.4 Scénario 4 : composition agile de services pendant la crise
4.4 Conclusion
Partie II Contributions et mise en œuvre
Chapitre 5 :Composition active de services
5.1 Introduction
5.2 Composition active vs. composition dynamique
5.3 Une approche pour la liaison tardive de services
5.4 Filtrage de services
5.4.1 Impact du calcul des modèles pour l’adaptation de données
5.4.2 Options pour la répartition temporelle des tâches de filtrage et de calcul des modèles
5.5 Supervision des services candidats
5.5.1 Mise en œuvre de la supervision
5.5.2 Un ensemble de contraintes spécifiques
5.5.3 Intégration au processus de composition active
5.6 Liaison tardive d’un service
5.7 Conclusion
Chapitre 6 :Composition utile de services
6.1 Introduction
6.2 Problématique d’une modélisation qualitative des préférences non-fonctionnelles
6.3 Linguistic CP-nets (LCP-nets)
6.3.1 Un ensemble de contraintes à prendre en compte
6.3.2 Cas d’utilisation et LCP-nets
6.3.3 Sérialisation XML
6.4 De l’élicitation de LCP-nets à la sélection de services
6.4.1 Elicitation des préférences
6.4.2 Traduction des préférences
6.4.3 Evaluation des préférences
6.4.4 Sélection d’un service : indécision levée par l’usage d’un LCP-net
6.5 Vers un traitement entièrement linguistique des préférences
6.6 Conclusion
Chapitre 7 :Composition agile de services
7.1 Introduction
7.2 Intégration conjointe des compositions actives et utiles dans l’orchestration de services
7.2.1 Définition d’une activité BPEL de liaison et invocation tardive de service
7.2.2 Définition incrémentale des préférences utilisateur
7.2.3 Notion de fragment de préférences
7.3 Représentation de plus haut niveau des LCP-nets
7.3.1 Syntaxe XML
7.3.2 Syntaxe abstraite de ce nouveau langage
7.3.3 Sémantique opérationnelle : règles de production
7.4 Intégration des HL-LCP-nets et HL-LCP-frags dans les processus métiers
7.4.1 Préférences anonymes en portée lexicale
7.4.2 Vers des LCP-nets entités de plein droit
7.5 QoS globale des processus et liaison tardive des services
7.6 Conclusion
Chapitre 8 :Formalisation du modèle LCP-net
8.1 Introduction
8.2 Notations préliminaires
8.3 Formalisme et test de dominance sur un LCP-net
8.4 Conclusion
Chapitre 9 :Mise en œuvre
9.1 Introduction
9.2 Canevas de modélisation et décision sur LCP-nets
9.2.1 Modèle de données structuré des préférences et des fragments
9.2.2 Outillage des LCP-nets
9.2.3 Calculs et décisions sur LCP-nets
9.2.4 Retour sur les principaux choix d’implantation
9.3 Canevas de liaison tardive de services Web
9.3.1 Contexte technique et architectural
9.3.2 Implantation de l’activité lateBindingInvoke dans Orchestra
9.3.3 Configuration et intégration de la supervision de services
9.4 Conclusion
Chapitre 10 :Conclusion et perspectives
Télécharger le rapport complet