Modèles généraux

2.4.1.1 CCM

Le CORBA Component Model (CCM) [6] a été développé pour fournir un mo-dèle de composants distribués avec des composants hétérogènes. Cette hétérogénéité est gérée à l’aide d’une utilisation de plusieurs langages de programmation. De plus, le protocole standard IIOP (Internet Inter-ORB Protocol) assure l’interopérabilité des composants [103]. CCM supporte des applications distribuées orientées objet et déve-loppées selon le modèle client-serveur en se basant sur l’appel de méthodes distantes RPC. Ce modèle fournit une transparence pour le client quand il envoie des requêtes. Aussi, il offre une portabilité des applications afin qu’elles s’exécutent sur différentes architectures. Un composant CCM possède quatre types de ports de base, une fabrique et des attributs (voir figure 2.2) :

— Facette : interface fournie par un composant et qui sert de point de vue sur ce dernier c-à-d qui expose une fonctionnalité ;

— Réceptacle : interface de connexion et de déconnexion entre composants ; — Source d’événement : point d’émission d’événements asynchrones ;

— Puits d’événement : point de réception de données asynchrones à partir d’un autre composant ;

— Fabrique(s) : home(s) est une nouvelle notion introduite dans CCM. Elle fournit des opérations pour gérer le cycle de vie des composants et les associations entre instances de composants ;

— Attribut(s) : principalement destiné(s) à être utilisé(s) pour la configuration des composants.

Figure 2.2 – Un composant CORBA et ses ports.

CORBA IDL (Interface Definition Language) décrit les interfaces qui supportent les fonctionnalités définies dans le corps d’un composant.

L’assemblage des composants CORBA [180] se réalise grâce à un descripteur XML en montrant comment les composants interagissent. Ce langage permet aussi de four-nir une présentation détaillée de l’assemblage concernant les propriétés des compo-sants, la génération de configurations par défaut pour les composants CCM et l’éta-blissement des interconnexions nécessaires entre ces derniers.

Les composants du modèle CCM peuvent être utilisés pour concevoir des appli-cations parallèles. Quelques travaux [130,166] utilisent CCM dans les calculs scienti-fiques.

2.4.1.2 Le modèle FRACTAL

FRACTAL est un modèle qui appartient à un projet open source, pour la construc-tion des systèmes à base de composants, développé par le consortium OW21. FRAC-TAL est un modèle de composants logiciels destiné à construire, déployer et gérer des

systèmes complexes en utilisant différentes formes de composition et de connexion entre des composants, avec un langage de programmation indépendant. Les caracté-ristiques du modèle sont :

— hiérarchie des composants ; — composants partagés ; — capacités d’introspection ; — reconfiguration.

Un composant FRACTAL [57,69] est une entité d’exécution encapsulée suppor-tant une ou plusieurs interfaces. Ces interfaces sont des points d’échanges (port dans d’autres modèles à base de composants) entre les composants exprimant leurs liaisons en termes d’interfaces client (représentant les services requis par le composant) et d’in-terfaces serveur (représentant les services fournis par le composant). Les interactions entre les composants s’acheminent grâce à des connecteurs nommés liaisons qui sont des canaux de communication entre les interfaces. Un composant est soit un composant clientdemandant l’exécution d’un service à un autre composant par envoi de requête contenant le descriptif du service à exécuter et attendant la réponse de ce service par un message en retour, ou soit un composant serveur réalisant un service sur demande d’un client, et lui transmettant le résultat. Un composant comporte généralement deux éléments :

— une membrane qui fournit ou utilise deux types d’interfaces internes ou externes et qui contient un ensemble de contrôleurs. Les interfaces internes permettent de composer les sous-composants à partir de leurs interfaces externes afin de constituer le composant composite alors que les interfaces externes sont acces-sibles depuis l’extérieur du composant. La membrane fournit le contrôle du comportement d’un composant à l’aide de contrôleurs pour, par exemple, gérer le cycle de vie d’un composant c-à-d sa création, son démarrage et son arrêt ; — un conteneur qui est un ensemble fini de sous-composants et de liaisons. Les liaisons sont construites d’une manière explicite lors de la composition et peuvent représenter des voies de communication à distance entre les interfaces. Ceci permet la construction d’une configuration ou architecture répartie de composants FRACTAL. Il existe deux méthodes de liaison : primitive ou composite. La liaison pri-mitive permet de relier une interface d’un composant client avec une interface d’un composant serveur. La liaison composite est constituée d’un ensemble de composants de liaison associés par des liaisons primitives. Le modèle FRACTAL possède un lan-gage de description d’architecture FRACTAL ADL qui définit les configurations c-à-d l’assemblage et la composition des composants. FRACTAL ADL est basé sur XML et il est modulaire et extensible pour décrire les composants, les interfaces et les liaisons en particulier les constructions des membranes. En outre, ce langage peut décrire les informations concernant le déploiement, les comportements et toute autre préoccupa-tion architecturale.

Le parallélisme sous FRACTAL est supporté pour que les utilisateurs puissent construire des applications parallèles. Ce modèle est utilisé pour concevoir les logiciels

distribués comme [109]. De plus, il est utilisé au niveau d’une méthodologie pour construire des modèles comportementaux de composants hiérarchiques, y compris les opérations de reconfiguration non structurelles [34].

2.4.1.3 Services Web

L’architecture orientée service (Service Oriented Architecture, SOA) [162] exploite le concept de service comme une unité principale pour développer et construire des applications complexes et distribuées. Cette architecture se base sur des technologies Web afin d’établir et gérer les communications entre ses composants. Dans ce contexte, ces composants sont appelés services Web. Un service Web est un module dont les in-terfaces décrivent les opérations et les structures de données utilisées pour mettre en œuvre sa fonctionnalité. Ainsi, ce module est exploité comme une boîte noire qu’on peut réutiliser et déployer. Un service Web peut être aussi utilisé comme programme de communication et d’échange de données entre applications hétérogènes non basées sur des services Web, ceci en se basant sur des technologies standards et des proto-coles. Pour décrire leurs caractéristiques fonctionnelles et non fonctionnelles, les ser-vices Web se basent sur plusieurs standards comme WSDL (Web Serser-vices Description Language) [204], BPEL (Business Process Execution Language) [159] et WSCL (Web Services Conversation Language) [205]. Le protocole de communication qui permet de définir les formats des messages échangés entre les services est le SOAP (Simple Object Access Protocol) [206]. SOAP est un protocole RPC orienté objet basé sur XML. Il permet la transmission de messages entre les services et autorise l’invocation à dis-tance des méthodes en mode requête-réponse. De plus, UDDI (Universal Description Discovery and Integration) [160] est une technologie utilisée pour enregistrer, publier et localiser les services Web. Cet annuaire est un intermédiaire entre les clients et les fournisseurs sur Internet.

La construction des applications autonomes et hétérogènes, en utilisant des ser-vices Web, se base sur la composition de ces derniers. La construction d’une composi-tion peut se réaliser selon deux modes : Orchestracomposi-tion et Chorégraphie [165].

L’orchestration permet de décrire l’enchaînement, l’organisation et la coordina-tion des services à l’aide du standard BPEL. Elle est centralisée par des définicoordina-tions d’opérations explicites et par l’ordre d’invocation des services Web. Les services Web concernés sont sous le contrôle d’un processus central unique qui peut être un autre service Web qui est le coordinateur de l’orchestration (figure 2.3).

Ce processus coordonne l’exécution des différentes opérations de services Web participant au processus. Les services Web invoqués n’ont pas besoin de savoir qu’ils sont impliqués dans un processus de composition et qu’ils participent à la définition des processus métiers.

La chorégraphie ne dépend pas d’un coordinateur central (figure 2.4). Elle per-met de concevoir une coordination décentralisée en utilisant le langage WS-CDL (Web Services Choreography Description Language) [207]. Ce type de composition est colla-boratif où chaque service Web participant décrit son rôle dans son(ses) interaction(s),

en sachant exactement quand est ce qu’il va devenir actif et avec qui il va inter-opérer. Tous les services Web impliqués dans une chorégraphie doivent connaître les opéra-tions à exécuter et leur déroulement. La chorégraphie est utilisée principalement pour échanger des messages dans les processus métiers publics.

Figure 2.3 – L’orchestration des services Web.

Figure 2.4 – La chorégraphie des services Web.

Dans l’orchestration, les services Web invoqués ne savent pas qu’ils appartiennent à un processus métier, par contre, dans la chorégraphie les services Web participants doivent savoir quand ils vont être actifs et avec qui ils vont interférer. De plus, la

chorégraphie pose plusieurs problèmes notamment la gestion d’erreurs et l’évolution dynamique.

Mais, elle permet aux services Web de s’administrer eux-mêmes, ce qui n’est pas le cas pour l’orchestration où les services Web sont dirigés par un seul maître. Le passage à l’échelle est difficile pour les processus complexes en utilisant l’orchestration, par contre, il est plus facile avec la chorégraphie.

Les architectures parallèles, traitant des données de manière simultanée, basées sur les services Web sont devenues dominantes. Il existe de nombreux applications distribuées des services Web pour différents domaines, parmi ces applications nous citons [145,188].