Service Oriented Computing (SOC)

Service Oriented Computing (SOC)

Le Service Oriented Computing (SOC) ou l’informatique orientée services est un nouveau paradigme informatique qui utilise les services comme éléments fondamentaux pour le développement d’applications d’entreprises rapides, économiques et faciles à intégrer (Preist, 2004). L’un des principaux objectifs de SOC est de permettre le développement des réseaux d’applications intégrées et collaboratives, indépendamment des plateformes et des langages de programmation utilisés pour les développer. Dans ce paradigme, les services sont autonomes, auto-descriptifs et indépendants des plateformes, fournissant un accès uniforme et omniprésent à l’information pour une large gamme de dispositifs informatiques, tels que les ordinateurs de bureau, les assistants personnels numériques (PDA) et les téléphones cellulaires. Tout morceau de code et tout composant d’application déployé sur un système peut être réutilisé et transformé en un service disponible sur le réseau. Ces services peuvent alors être facilement décrits, publiés, découverts et assemblés dynamiquement pour développer des systèmes distribués et interopérables.

Services Web

La notion de service est sémantiquement surchargée. Différentes communautés ont une compréhension différente de ce qu’est un service (Preist, 2004). Par exemple, dans le milieu des affaires, un service est considéré comme une activité commerciale qui entraîne souvent des résultats ou des avantages intangibles (Baida et al., 2004), tandis qu’en informatique, les termes service et service Web sont souvent considérés comme interchangeables pour nommer une entité logiciel accessible sur Internet. Dans le cadre de cette thèse nous ne faisons aucune distinction entre les deux concepts.

Définition des services Web

Définition 3.1.1 :
Un service Web est une entité logicielle sans état, modulaire, autonome et disponible, sous un format standard, sur Internet ou dans un intranet qui s’exécute à distance sur le site du fournisseur (Huhns & Singh, 2005).

Définition 3.1.2 :
Les services Web comme toutes autres technologies de middleware ; vise à fournir des mécanismes pour relier des plateformes hétérogènes, permettant aux données de circuler à travers différents programmes (Staab et al., 2003).

Définition 3.1.3 :
Selon le World Wide Web Consortium (W3C), les services Web sont identifiés par un URI (Uniform Resource Identifier), leurs interfaces sont définies dans WSDL (Web Service Description Language), publié dans le registre UDDI (Universal Description, Discovery and Integration), les services peuvent être découverts et invoqués par d’autres systèmes logiciels. Ces systèmes interagissent avec les services Web en utilisant des messages XML véhiculés par le protocole SOAP (Simple Object Access Protocol) (Booth et al., 2004).

La technologie des services Web vise donc à standardiser la présentation des services offerts par une entreprise et à rendre leur accès transparent à tout type de plateformes, à travers un certain nombre de normes d’interopérabilité.

Architecture orientée services (SOA)

Le paradigme de l’informatique orientée service (SOC) peut être mis en œuvre abstraitement par l’architecture du système appelée architecture orientée service (SOA) [(Bajaj et al., 2006), (Bellwood, 2002)]. Le but de cette architecture est de répondre aux exigences de couplage faible, standards, et le calcul distribué indépendant des protocoles, en mappant les systèmes d’information des entreprises d’une manière isomorphique au flux global des processus métiers (Stollberg et al., 2004). Cette tentative est considérée comme le dernier développement d’une longue série d’avancées en génie logiciel traitant de la réutilisation de composants logiciels. Historiquement, la première étape majeure de cette évolution a été le développement du concept « fonction ». En utilisant des fonctions, un programme est décomposé en sous-programmes plus petits et le code d’écriture est axé sur l’idée de l’interface de programmation d’application (API). Une API, pratiquement, représente le contrat auquel un composant logiciel doit s’engager. La deuxième étape majeure a été le développement du concept « objet ». Un objet est un bloc de construction de base qui contient à la fois des données et des fonctions dans une seule unité encapsulée. Avec le paradigme orienté objet, les notions de classes, d’héritage et de polymorphisme sont introduites. De cette façon, les classes peuvent être considérées comme un treillis. Le concept « service » devient la prochaine étape d’évolution introduite avec l’avènement du SOC et de sa mise en œuvre SOA. Selon le groupe de travail du World Wide Web Consortium (W3C), la SOA est définie comme suit :

Définition 3.2.1 :
L’architecture orientée services est un paradigme pour l’organisation et l’utilisation de capacités distribuées qui peuvent être sous le contrôle de différents domaines de propriétés. Il fournit un moyen uniforme d’offrir, de découvrir, d’interagir et d’utiliser des capacités pour produire les effets souhaités compatibles avec des conditions préalables et des attentes mesurables (Booth et al., 2004). Une définition plus récente de SOA donnée par Erl est la suivante:

Définition 3.2.2 :
L’architecture orientée services est une forme d’architecture technologique qui adhère aux principes de l’orientation service. Une fois réalisée à travers la plate forme technologique de services Web, SOA établit le potentiel de soutenir et de promouvoir ces derniers dans les processus métiers et les domaines d’automatisation d’une entreprise (Erl, 2016).

La vue logique fondamentale des services dans SOA est basée sur la séparation de la description du service (fréquemment appelée interface) et son implémentation (Stollberg et al., 2004). Une interface de service définit l’identité de celui-ci et sa logistique d’invocation. Une implémentation de service, implémente les opérations internes que le service est sensé réaliser. Basé sur cette séparation, les fournisseurs de services et les consommateurs de services sont faiblement couplés. De plus, les services peuvent être significativement réutilisés et adaptés à certaines exigences. Etant donné que les interfaces de service sont indépendantes de la plate-forme et que l’implémentation est transparente pour les consommateurs de services, un client depuis n’importe quel périphérique de communication utilisant une plate-forme de calcul, un système d’exploitation et un langage de programmation devrait être capable d’utiliser le service. Les deux facettes du service sont distinctes; elles sont conçues et maintenues comme des éléments distincts, bien que leur existence soit étroitement liée. Basé sur l’autonomie de service et la séparation nette des interfaces de service de l’implémentation interne, SOA fournit une architecture plus flexible qui unifie les processus métier en modulant de grandes applications en services. En outre, des applications à l’échelle de l’entreprise ou même interentreprises peuvent être réalisées au moyen du développement, l’intégration et l’adaptation des services.

Propriétés d’un service Web

Selon Dumas et Fauvet trois types de propriétés peuvent être identifiés pour les services Web ; Ils peuvent être brièvement définis comme suit:

Propriétés fonctionnelles

La description fonctionnelle contient la spécification formelle de ce qu’un service peut faire. WSDL (Web Services Description Language), détaillé plus loin (paragraphe 3.4.1), est un langage de la famille XML permettant de décrire les types de données supportés et les fonctions offertes par un service Web. L’objectif est de fournir la description, en XML, des services indépendamment de la plate-forme et du langage utilisés et sous une forme que des personnes ou des programmes peuvent interpréter.

Propriétés comportementales

La portée de WSDL est limitée à la description des types de données incluses dans les messages qu’un service est capable de recevoir ou d’émettre. Dans de nombreuses applications, ces descriptions uniquement structurelles n’offrent pas assez d’information sur les contraintes régissant les interactions dans lesquelles un service peut ou est censé s’engager. Dans certains cas, ces contraintes sont assez simples, comme par exemple : « le fournisseur n’envoie le bordereau de livraison qu’après avoir reçu la confirmation du paiement ». Parfois, ces contraintes sont relativement complexes. Un fournisseur reçoit un « Bon de Commande » de la part d’un client, il doit répondre avec « un Récépissé de Bon de Commande ». Par la suite, le fournisseur enverra zéro, une ou plusieurs « Réponses » au client jusqu’à avoir donné une réponse (une acceptation ou un rejet) pour chacune des lignes de Commande. Au cours de ce processus, le fournisseur peut recevoir une « Annulation » de la part du client, dans ce dernier cas, le fournisseur répond avec un « Récépissé d’Annulation de Bon de commande ». Dès lors, le fournisseur ne doit plus envoyer de « Réponses » au client.

Propriétés non fonctionnelles

Les descriptions non fonctionnelles capturent les contraintes sur les deux types précédents de propriétés (Chung, 1991). Les services Web étant généralement développés par des équipes indépendantes, ont besoin d’être décrits de façon précise selon des conventions standards, et de telle manière que leurs descriptions puissent être utilisées au maximum pour automatiser le processus de développement et de déploiement des futurs services devant interagir avec un service existant. WSDL permet de décrire les opérations fournies par un service Web, les types de données des messages devant être échangés pour invoquer ces opérations, et les dépendances comportementales entre ces opérations. Cependant, ils ne permettent pas de décrire des aspects non-fonctionnels des services tels que leur capacité à garantir une certaine qualité de service par rapport à des préoccupations telles que la sécurité, la fiabilité, la journalisation des accès ou la gestion de transactions.

Considérant l’exemple du bon de commande présenté ci-dessus, en invoquant sa fonctionnalité (payement) peut être contraint en utilisant une connexion sécurisée (sécurité comme propriété non fonctionnelle) ou en effectuant réellement l’invocation des services à un certain moment (disponibilité temporelle comme propriété non fonctionnelle).

Table des matières

Introduction générale
1. Contexte
2. Problématique et objectifs
3. Motivations
3.1 Scénario 1
3.2 Scénario 2
4. Contributions
5. Plan de la thèse
Chapitre 1 : Vue d’ensemble des technologies clés
1. Introduction
2. Service Oriented Computing (SOC)
3. Service Web
3.1 Définition des services Web
3.2 Architecture des services Web (SOA)
3.3 Propriétés d’un services Web
3.2.1 Propriétés fonctionnelles
3.2.2 Propriétés comportementales
3.2.3 Propriétés non fonctionnelles
3.4 Technologies des services Web
3.4.1 Langage de description des services Web (WSDL)
3.4.2 Protocole d’accés aux objets simples (SOAP)
3.4.2.1 Structure d’un message SOAP
3.4.2.2 Mode de traitement
3.4.2.3 Protocole de liaison
3.4.2.4 Avantages et incovénients de l’utilisation de SOAP
3.4.3 Description universelle, protocole de découverte et d’integrétation (UDDI)
3.5 Caractéristiques des services Web
3.6 Types de services Web
3.7Avantages de l’utilisation des services Web
4. Paramètres de qualité de services (QoS)
5. Personnalisation des services Web
6. Réseaux sociaux sur le Web
7. Systèmes de recommandation et filtrage collaboratif
8. Conclusion
Chapitre 2 : Sélection des services Web
1. Introduction
2. Défintion
3. Sélection des services Web sociaux
3.1 Approches basées sur la réputation
3.2 Approches basées sur la recommandation
3.3 Approches basées sur le renvoi
4. Sélection des services Web et défis des approches basées sur la recommandadtion
4.1 Problème de démarrage à froid
4.2 Problème de confidentialité
4.3 Evolutivité
4.4 Capture des préférences et des évaluations des utilisateurs
5. Etude comparative des différentes approches de sélection des services Web sociaux
6. Conlusion
Chapitre 3 : Composition des services Web
1. Introduction
2. Modèles de composition des services Web
2.1 Orchestration
2.2 Chorégraphie
2.3 Coordination
2.4 Modèle de composant
3. Exigences de la composition des services Web
3.1 Automatisation
3.2 Dynamicité
3.3 Qualité de service (QoS)
3.4 Evolutivité
3.5 Préférences des utilisateurs
3.6 Indépendance au domaine
4. Différentes approches de composition automatique des services Web
4.1 Approches orientées Workflow
4.2 Approches basées sur les modèles
4.3 Approches mathématiques
4.4 Approches orientées intelligence artificielle
4.5 Approches basées sur la recommandation
5. Discussion
6. Conclusion
Chapitre 4 : Intégration flexible des services Web: une nouvelle approche sociale personnalisée
1. Introduction
2. Architecture proposée pour la composition des services Web sociaux personnalisés
3. Communautés de services Web
4. Construction du réseau social de services Web
4.1 Paramètres qualité de services (QoS) considérés
4.2 Fonction objective
4.3 Associations de collaboration pour la composition
4.4 Associations de collaboration pour la substitution
4.5 Associations de recommandation pour la compostion
5. Sélection des services Web atomiques pour la composition
6. Composition des services Web sociaux personnalisés
6.1 Construction des préférences utilisateur
6.1.1 Attributs statiques
6.1.2 Attributs acquis
6.2 Algorithme pour la composition des services Web sociaux personnnalisés
7. Tolérances aux pannes dans le cadre de l’approche proposée
6.1 Associations de recommandation pour la substitution
6.2 Algorithme de sélection des services Web pour la substitution
8. Implémentation et évaluation
8.1 Approche de composition des services Web personnalisés
8.2 Algorithme de sélection des services Web pour la substitution
9. Conclusion
Conclusion générale

Lire le rapport complet