Faculté des sciences Année universitaire 2010 -2011

Département d’Informatique
Master 2 Génie Logiciel

Module ABCL : Architecture à Base des Composants Architectural

Plan du cours
I. L’architecture logicielle à base de composants (TP & Cours)
 Introduction
 Les trois dimensions d’un composant
 Les composants industriels
 Métamodèle (Niveau M2)
 Les profils UML
 Modèle client-serveur: Niveau M1 (TP)
 Conclusion

II. L’architecture logicielle à base de services (TP & Cours)

 Introduction
 Composants de la SOA
 Le principe de fonctionnement d’un service web
 La composition des services
 Processus métier (BPEL)
 Réalisation d’un processus de virement sous Netbeans: (TP)
 Conclusion

Disponible à : https://sites.google.com/site/altiadel19/support-de-cours
 Chapitre 1 : L’architecture logicielle à base de composants

I.1. Introduction
Le but de ce cours d’objets composants est de construire un métamodéle de composants académique. Nous
allons donc mettre en application et approfondir les notions des composants architecturaux.

La modélisation à base de composants architecturaux permet aux développeurs de faire abstraction des
détails d’implémentation, de se concentrer sur des éléments de plus haut niveau comme les différentes vues
et structures des systèmes complexes et de raisonner sur leurs propriétés (protocole d’interaction,
conformité avec d’autres architectures, etc.).

Cette approche décrit un système comme un ensemble de composants (unité de calcul ou de stockage) qui
interagissent entre eux par le biais de connecteurs (unités d’interactions). Leurs objectifs consiste à réduire
les coûts de développement, à améliorer des modèles, à faire partager des concepts communs aux
utilisateurs et enfin à construire des systèmes hétérogènes à base de composants réutilisables sur étagères
(COTS, commercial off the shelf).

L’architecture logicielle à base de composants (composants architecturaux) décrit les systèmes logiciels
comme un ensemble de composants (encapsulation des fonctionnalités) qui interagissant entre eux par
l’intermédiaire des connecteurs (encapsulation de communication), comme indiqué dans la figure 1.

Configuration
Rôle - Requis Rôle - Fourni
Connecteur
Composant Composant
Glue
Port - Fourni Port - Fourni

Figure 1.1. Description architecturale des systèmes à base de composants.

I.2. Les trois dimensions d’un composant

La première dimension ou niveau d’abstraction permet d’exprimer les degrés de raffinement d’un
composant et ce depuis sa spécification. Elle est considérée comme étant le plus haut niveau d’abstraction.
Son code source représente le plus bas niveau. Chaque niveau d’abstraction peut lui être associé un niveau
de transparence qui définit le niveau de visibilité des détails internes d’un composant lors de sa/son (ré)
utilisation. Le niveau de transparence d’un composant peut être de type :
  boîte noire : l’interface du composant fait abstraction de son implémentation. L’interaction avec
l’extérieur se fait uniquement à travers l’interface utilisateur. Ce qui permet de donner la possibilité de
remplacer un composant par un autre, réalisée par l’offre de la même interface.
 boîte blanche : le composant rend transparent tous les détails de l’implémentation. L’interaction avec
l’extérieur peut se réaliser non seulement à travers l’interface du composant mais aussi à travers son
implémentation. Ce type de composant, a l’avantage de fournir toute l’information relative à son
implémentation.
 boîte grise : il s’agit d’un niveau de transparence intermédiaire entre les composants de type boîte
noire et boîte blanche. Si les détails d’implémentation peuvent être révélés pour comprendre la
réalisation du composant, ils ne peuvent pas être sujet à des modifications émanant de l’extérieur :
l’interaction se fait uniquement à travers l’interface.
La deuxième dimension ou mode d’expression permet de décrire les différents modèles de représentation
d’un composant (représentation textuelle, graphique, flot de données, implémentation). La description d’un
composant doit être simple, compréhensible avec une sémantique pas nécessairement définie de manière
formelle mais au moins claire. En effet, les participants à l’élaboration de composants (concepteurs,
développeurs, utilisateurs, managers…) peuvent requérir différents modes d’expression.

Les utilisateurs peuvent se contenter d’une description graphique de haut niveau (type boîte et flèche). Les
développeurs voudront détailler par exemple les modèles de connecteurs et de composants, alors que les
managers peuvent requérir une vue du processus de développement. Le mode d’expression d’un composant
dépend également de sa granularité. La notion de granularité de composant recouvre, selon les langages de
représentation, aussi bien des unités atomiques telles que les structures de données, les fonctions
mathématiques ou de véritables structures composées d’éléments et de liens.

I.3. Les composants industriels

Actuellement, il y a plusieurs plates-formes d’exécution qui se focalisent sur le développement des systèmes
à base de composants. Les plus connus d’entre eux sont CORBA, EJB, .Net et les Web Services. La
communication entre les composants est complexe dans des plates-formes hétérogènes et la réutilisation
des composants au niveau d’implémentation est limitée.

Les intergiciels représentent le niveau d’exécution des applications (par exemple CORBA, J2EE, .NET, etc.) et
les services normalisés fournissent le support à l’exécution de ces applications (par exemple la sécurité des
transactions et des évènements). Tout cet ensemble, de technologies est utilisé pour supporter différents
domaines tels que la finance, le commerce électronique ou la télécommunication. Si le nombre de modèles
de base disponibles est faible, il n'est pas cependant figé.

I.3.1. La plateforme J2EE

La plateforme J2EE couvre l’ensemble des technologies Java permettent la mise en place d’applications
d’entreprise, c.-à-d. les applications résident du coté de l’entreprise et réalisent toute la logique métier de
cette dernière. Elle permet un développement orienté objet. Son objectif est d’offrir tous les avantages des
paradigmes objet et composants aux applications d’entreprise lesquelles étaient souvent développées à
l’aide de langage non objet.

J2EE permet un découpage multitiers. Elle supporte par défaut la séparation selon les trois présentations,
traitements et données. Pour chacun de ces tiers, J2EE offre des technologies différentes. L’architecture
J2EE repose de deux blocs :

 Servlets/JSP : Ce bloc gère l’interface avec le client. Les servlets et les JSP sont des technologies J2EE
qui permettent les communications avec les clients selon, entre autres le protocole http. Les JSP sont
notamment utilisées pour générer les pages HTML qui seront visualisées par le client. Dans une vision
trois tiers, ce bloc représente la tierce présentation.
 EJB : permet de représenter sous forme de composants les traitements et les données des
entreprises. EJB se déclinent en deux types : les EJB Session et les EJB Entity. Les EJBs sont connectés aux
bases de données de l’entreprise.

I.3.2. La plateforme CORBA

L'OMG ne fournit que des spécifications : aucune implémentation de CORBA n'est proposée. Ces
spécifications sont très précises et complètes. Elles doivent garantir la standardisation des produits proposés
par les différents éditeurs. CORBA est basé sur la technologie objet. L'ensemble des développements réalisés
dans un environnement CORBA doit se faire dans cet esprit, bien que d'autres technologies puissent être
intégrées. CORBA repose sur une architecture client/serveur et un modèle de communication de type RPC.
Cependant, CORBA se veut très universel. D'autres modèles de communications peuvent être instanciés dans
une architecture CORBA, notamment la communication par messages. Un point essentiel est l'indépendance
de la plateforme aux contextes de développement et d'exécution des applications.

 ORB (Object Request Broker) : bus objet. C'est le nœud central de l'architecture. Toutes les
informations échangées entre les différents composants transitent par l'ORB.
 Services : cycle de vie, persistance, nommage, événements, sécurité, licences, etc.
 Interfaces de domaines : objets dédiés à un domaine applicatif (santé, finance, etc.) CORBA Facilities
: gestion des processus, des interfaces utilisateurs, des systèmes)
 Application Interfaces : applications.

I.4. Métamodèle

I.4.1. Niveau M2
Une hiérarchie de trois niveaux d’abstraction pour l’élaboration des architectures logicielles est illustrée dans
la figure 2. Le niveau le plus élevé (M2) contient les différents concepts de base pour définir les architectures
logicielles ADL, le second niveau (M1) contient les modèles d’architectures et le troisième niveau (M0)
contient les instances de ces modèles. La relation entre M2-M1 est nécessaire pour vérifier la cohérence des
modèles, alors que la relation entre les niveaux M1-M0 permet de générer plusieurs instances
d’architectures. Les trois niveaux d’abstraction de l’architecture logicielle sont inspirés de trois niveaux
d’abstraction de l’OMG comme le montre le tableau 1.

Modélisation par objet Modélisation par composants

Le niveau métamodèle M2 UML Acme, COSA, Fractal,…
Le niveau modèle M1 Modèles Architectures
Le niveau application M0 Instances Instances
Tableau 1 Les trois niveaux conceptuels dans la modélisation objets et la modélisation composants

Métamétamodéle
Niveau M3
(Méta-ADL)
(MOF 2.0)

Niveau M2
ACME COSA

(UML 2.0) (UML 2.0)

Modèle Niveau M1
Modèle Modèle

Niveau M0
Applications

Figure 1.2. Architecture à quatre niveaux des architectures logicielles

Ainsi nous définissons la liste des suivantes des éléments devant être présenté dans la diagramme UML :

 Les composants sont des unités de calcul ou du stockage pour lesquelles est associée une unité
d'implantation. La plupart des systèmes à base de composants peuvent avoir plusieurs interfaces : chaque
interface définit un point d’interaction entre un composant et son environnement.

 Les connecteurs représentent les interactions entre les composants et les règles qui régissent ces
interactions correspondent aux lignes dans les descriptions de type "boites-et-lignes". Ce sont des entités
architecturales qui lient des composants ensemble et agissent en tant que médiateurs entre elles.

 Les interfaces d’un composant sont des points de communication qui lui permettent d’interagir avec son
environnement ou avec d’autres composants.

 Les propriétés représentent les informations sémantiques des composants et de leurs interactions.

 Les configurations architecturales représentent les graphes de composants et de connecteurs et la façon

dont ils sont reliés entre eux. Leur but est d’abstraire les détails des différents composants et connecteurs.

 La composition/assemblage permet de construire des applications complexes à partir de composants

simples. La composition ou assemblage permet de lier un composant demandant des services à d’autres
composants offrant ces dits services.
 Les styles architecturaux sont des aspects intéressants, même s’ils ne sont présents que dans certains
systèmes à base de composants. Le choix d’un style architectural permet de déterminer l’ensemble des
vocabulaires désignant le type des entités de base (composants et connecteurs) et spécifier l’ensemble des
règles de configuration qui déterminent les compositions entre éléments.

I.4.2. Contraintes
Les contraintes représentent les moyens permettant à un modèle d’architecture de rester valide durant
toute sa durée de vie et de prendre en compte l’évolution et le remplacement des composants logiciels dans
cette dernière. Ces contraintes peuvent inclure des restrictions sur les valeurs permises de propriétés, sur
l’utilisation d’un service offert par un composant et garantir la validité des résultats retournés par ce service.
Les contraintes appliquées sur un connecteur sont :

 Un connecteur doit avoir seulement deux rôles et une seule Glu.

 L’interface d’un connecteur est portée seulement par les ports de connecteur.
 L’interface d’un connecteur doit avoir au moins un rôle fournit et rôle requis.

Contrainte
1
Style Configuration 1
1 1 Propriété

composé de 1 1 composé de
1 1..* 0..* 0..* 1
1
Composant Connecteur
1
1
0..* 0..*
1 composé de
1
1 composé de 1
composé de composé de
1 1
Interface

0..*

Liaison Liaison

0..1 1
1 0..1
Port Rôle
0..1 0..1

Attachment

Port-Fourni Port-Requis Rôle-Fourni Rôle-Requis

Figure 1.3. Les concepts de base des langages de description d’architectures dans COSA.

I.5. Les profils UML (UML Profile)

UML permet de modéliser des architectures logicielles à base d’objets dont les concepts sont suffisamment
génériques pour être utilisés dans le contexte des architectures logicielles à base de composants. En effet,
utiliser UML pour décrire les architectures logicielles, permet à ses utilisateurs de bénéficier des analyses
puissantes offertes par les ADLs et aux utilisateurs d’ADLs pour utiliser les outils UML. Pour permettre
l’adaptation d’UML au domaine de l’architecture logicielle ou à d’autres domaines, l’OMG a standardisé le
concept du profil UML. Un profil est un ensemble de techniques et de mécanismes d’extensions
(stéréotypes, valeurs marquées, contraintes) permettant d’adapter UML à un domaine particulier
(exemple de l’architecture logicielle).

I.5.1. Utilisation de profils existants

Quelques profils sont utilisés dans la modélisation commerciale et les autres pour une technologie
spécifique. Parmi ces profiles, on peut citer: UML Profile for CORBA Specification, UML Profile for CORBA
Component Model (CCM), UML Profile for Enterprise Application Integration (EAI), UML Profile for Enterprise
Distributed Object Computing (EDOC), UML Profile for Modeling QoS and Fault Tolerance Characteristics and
Mechanisms, UML Profile for Schedulability, Performance and Time, UML Profile for System on a Chip (SoC),
UML Profile for Systems Engineering (SysML).

I.5.2. Définition de nouveaux profils

UML 2.0 facilite la création des nouveaux profils, la figure 2.4 illustre la partie du métamodèle UML 2.0 qui
contient les métaclasses relatives aux profils, nécessaires à la définition de ce dernier. Il n’y pas, à l’heure
actuelle, de définition standard du profil UML. Ainsi, nous pouvons dire que les profils sont des moyens
d’adapter d’UML à un type d’application (systèmes distribués, temps réel, etc.).

I.6. Modèle client-serveur : Niveau M1 (TP)

Selon OMG, Le métamodèle définit la structure de tout modèle UML conforme à ce métamodèle. Par
exemple, le métamodèle UML définit que les modèles UML contiennent des packages, leurs packages des
classes, leurs classes des attributs et des opérations, etc. Pour illustrer notre stratégie de projection par profil
UML, nous proposons d’utiliser un système Client-Serveur (figure 4) . La figure 5 décrit l’exemple du système
Client-Serveur après l’application de métamodèle COSA et la figure 6 montre la représentation de ce même
système en COSA.
 Server
Connection Manager

Clearance Request SQL Query

Security Manager DataBase

Security Query

Figure 1.4. La structure du composant Serveur.

Composant Server

+ send-date ()
Composant DataBase-Manager

Connecteur
SecurityQuery Composant
requestor securityManagement
DataBase

Sec_Glu
secManager

queryIntf

Composant
cerdQuery

SecurityManager Connecteur
SQL_Query
callee

SQL_Glu
secAuthor

caller
Grantor

Connecteur
DBQueryIntf

Composant
ClearanceRequest ConnectionManager

Cle_Glu
requset securityCheck

extrnalSocket

extrnalSocket

provide
 Légende

Connecteur d’assemblage Connecteur de délégation

Figure 1.5. Exemple de composition en COSA.

Class Configuration client-serveur {
Class Component Serveur {
Properties {password-needed = true; data-type = format-1;}
Constraints {max-clients=1;}
Interface { Connection-Mode : synchronous ;
Ports provide{provide;}
Services provide {Send-data;}
Use {Send-data to provide;} }

Define-Composition {
Class Components {
Class Component ConnectionManager {
Interface { Ports provide {externalSocket; DBQueryIntf;}
Ports request {securityCheck;}}
Class Component SecurityManager {
Interface { Ports provide {securityAuto;CerdentialQuery;}}}
Class Component Database {
Interface { Ports provide{queryIntf;}
Ports request{securityManagement;}}}
Class Connector SQLQuery {
Interface { Ports provide{callee;} Ports request{caller;}}
Class Connector CleranceRequest {
Interface { Ports {grantor; requestor;}}
Class Connector SecurityQuery {
Interface { Ports provide{securityManager; requestor }
}
Attachments {
ConnectionManager. SecurityCheck to CleranceRequest.requestor;
SecurityManager. SecurityAutothorization to CleranceRequest.grantor;
ConnectionManager.DBQueryIntf to SQLQuery.caller;
Database. queryIntf to SQLQuery.callee;
SecurityManager.cerdentialQuery to SecurityQuery.SecurityManager;
Database. securityManagement to SecurityQuery. Requestor;
}
Bindings {ConnectionManager. ExternalSocket to server.provide; }
}
}

Class Component Client {

Properties {Request-rate = 21.0; data-type = format-2;}
Interface { Connection-Mode : synchronous ;
Ports request{request;}
Services request {Damend-data;}
Use { Damend -data to request;} }
}

Class Connector RPC {

Interface {Roles {callee; caller}}
Constraints {max-roles = 2;}
Glue {Definition of service….}
}

Instance client-serveur arch-1 {

Instances {
S1: server;
C1: client;
C1-S1: RPC;}
Attachments {C1.request to C1-S1. callee;
S1.provide to C1-S1. caller; }
}
}

Figure 1.6. Système Client-Serveur en COSA.

I.7. Conclusion
Le but de ce cours d’objets composants est de construire un métamodèle de composants dans le but de
modéliser le système client/serveur. Après avoir méta-modélisé, à l’aide de cours, les concepts du cours, les
concepts de base des composants, nous avons procédé à l’instanciation de ce diagramme en vue de
présenter le modèle client/serveur. Nous avons approfondi ce modèle par la description COSA du système.
Nous avons également réalisé un diagramme de déploiement du système client/serveur.

Ce cours a permis de mettre en application les notions vues en cours et ainsi de mieux centrer les concepts
des composants. A présent, nous allons pouvoir nous pencher sur la définition d’un méta-métamodèle (méta
ADL).
 Chapitre 2 : L’architecture logicielle à base de services

II.1. Introduction
L'architecture orientée services (calque de l'anglais Service Oriented Architecture, SOA) est une forme
d'architecture de médiation qui est un modèle d'interaction applicative qui met en œuvre
des services (composants logiciels) :

1. avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent XML),
2. et des couplages externes « lâches » (par l'utilisation d'une couche d'interface interopérable, le plus
souvent un service web WS).

II.2. Composants de la SOA

Les architecture orienté services basé sur les concepts suivantes :
1. Le fournisseur de service : représente la personne ou l’organisation qui fournies le service, elle
accepte et exécute les requêtes clients, ainsi le fournisseur de service spécifié leur services par des
descriptions qui permettent de faciliter la découverte et l’invocation par l’utilisateur.
2. Le consommateur de service : est l’application qui a besoin d’un service en termes de fonctionnalité,
communique avec le service à travers un protocole pour exécuter la fonction offre par le service.
3. L’annuaire de service : est une entité centrale qui stocke les descriptions des services, et qu’il est
utilisé par le fournisseur de service pour publier ces services et aussi par le client pour découvrir des
services répondant à ces besoins.
4. Le contrat de service : est un ensemble des conditions à respecter entre le fournisseur de service et
le client pour exploite le service.

II.2. 1. Service
Le service est l’un des composants clés des architectures orientées services, « le service dans les
architectures orientées services expose une partie de fonctionnalité qui respecte les propriétés suivantes :
(1) Le contrat d'interface pour le service est indépendant de la plateforme, (2) le service a une
localisation dynamique et invocation, (3) le service est autonome et sait maintenir son propre état courant ».
Le service possède plusieurs caractéristiques :

1. Le service est fournit par un fournisseur.

2. Le service peut s’exécuter de manière synchrone ou asynchrone.

3. Un service exécute un ou plusieurs fonctions.

4. Il offre une description externe pour faciliter leur découverte.

5. Il possède une description des fonctionnalités pour faciliter leur invocation.

 6. Il possède la propriété de couplage faible, c.-à-d. le service utilise le format XML pour la
communication.

II.2. 2. Web Service

La définition W3C : « A Web service is a software application identified by a URI, whose interfaces and
binding are capable of being defined, described and discovered by XML artifacts and supports direct
interactions with other software applications using XML based messages via internet-based protocols ».
Un service web est un logiciel accessible par internet et qui fournie l’interopérabilité entre les machines
sur un réseau, il est constitué d’une interface lisible décrite en WSDL, l’interaction entre le SW et les autres
applications ce fait par le protocole SOAP, ce dernier transmis via le protocole HTTP avec les messages décrit
en XML.

II.2.3. Les standards du service web

Les services web reposent sur un ensemble des protocoles et des standards utilisés pour la communication
entre les systèmes hétérogènes.

 SOAP
Simple Object Access Protocol possède un format XML pour échanger des informations structurées et
typées entre deux pairs distants dans un environnement décentralisé et distribué, c.-à-d. l’échange et le
transfert de messages ce fait à l’aide de protocoles http, SMTP, etc. La structure de L’enveloppe SOAP
(figure 1) repose sur deux parties essentielles:

1. SOAP Header : est l’entête de message contient tous les informations sur le message et son
acheminement.
2. modèle de données qui spécifier le format à transmit.

Figure 2.1. La structure de L’enveloppe SOAP.

 WSDL
Le Web Service Description Language, est un format décrit en XML pour la description des services Web, il
repose sur deux groupe de sections, la définition abstraite et la description concrète, la définition abstraite
inclut les éléments : types, message, portType, et la description concrète inclut les éléments : binding,
service. Nous allons décrit les détails de ce Standard dans la section 3.1 du chapitre 3.

 UDDI
« Universal Description Discovery and Integration » est standard repose sur le format XML, utiliser
par le fournisseur de services pour la publication et utiliser aussi par le consommateur de service pour
découvrir des services qui répond à ces besoins, il est spécifique aux approches centralisées fondées sur
le langage XML Schéma, et connu aussi par l’annuaire des services ou (UDDI registry en anglais), et
destiné aux services

II.2. 4. Description du service

Le Web Service Description Language (WSDL) est un format XML pour la description des services Web, il
décrit un service à travers une interface présentant un ensemble d'opérations et leurs paramètres
d'entrée et de sortie respectifs.

La structure d’un document WSDL en six éléments : <definition>, <types>, <message>, <portType>,
<binding>, <service>, un document WSDL divisé en deux groupes de sections, l’un sur l’autre, la section
en haut connu par la définition abstraite, qui inclut les éléments <types>, <message>, <portType>, et la
section en bas connu par la description concrète , qui inclut les éléments <binding>, <service>.

La figure 2.2 ulster les éléments fondamentaux pour la description d’une interface WSDL et les
relations entre eux, la <definition> inclut les deux groupes de sections : définition abstraite et description
concrète, la section message utilise les définitions de la section types, la section portType utilise les
définitions de la section message, la section binding réfère à la section portType et la section service
réfère à la section binding, les sections binding et portType contiennent des éléments d’opérations et
la section service contient des éléments de port. Les éléments d'opération de la section portTypes sont
modifiés ou décrits plus précisément par les éléments d'opération de la section Bindings. Dans ce qui
suite la définition des éléments précédente :

1. <types> : les données peuvent être simples ou complexe, simple comme l’âge, qui prend une
valeur décimale, données complexe si par exemple un service qui cherche la position d’un client,
il prend en entrée location comme une donnée complexe, constitué des éléments country et city,
comme montre la figure (a).
 <definitions
>
<types>
Définition
<message> abstraite

Contient, réfère <portType> <operation>

Utilise
<binding> <operation> Description
Modificateur
concrète
<service> <port>

Figure 2.2 - la structure WSDL et les relations entre ces éléments.

2. <message> : représente une définition abstraite des données communiquant, un message est
constitués d'une ou plusieurs parts, chaque part est associé à un type de données définit dans
l’élément <type>, le message de la figure (b) possède un nom getInternationalTimeRequest, un
part est associe au type de donnés getInternationalTime.

3. <portType> : est un ensemble d'opérations abstraites et les messages abstraits impliqués, le

portType décrit le web services, le portType ServiceDescription de la figure (c) contient
l’opération getInternationalTime, l’input et l’output de cette opération sont les messages
getInternationalRequest, getInternationalResponse.

4. <binding> : définit les formats des messages et les détails de protocole de transmission des
messages pour les opérations et les messages définit pour un portType particulier, l’exemple de
la figure (d) ulster le binding possède deux attributs, le name définit le nom de l’attribut binding
et le type qui définit le portType utilisé pour le binding, dans l’élément soap:binding l’attribut
transport définit le protocole http pour véhiculer les messages SOAP.

5. <service> : un service agrégé un ensemble associé de ports. l’exemple de la figure (d) présente
le service serviceDescription à travers un port, le port associe au binding
tns:ServiceDescriptionSOAP et une adresse http://example.com/ServiceDescription.
 L’élément WSDL <types>

L’élément WSDL <message>

L’élément WSDL <portType>

L’élément WSDL <binding>

L’élément WSDL <service>

Le WSDL v1.0 en 2000 est la première version développée par IBM, Microsoft et Ariba, le
WSDL 1.1 a été proposé en 2001 comme une note W3C mais n’est pas agréer, la version 2.0 a
été agréer en 27 juin 2007 comme une recommandation officielle du W3C, dans ce qui suite la
différence entre ces versions :

1. Description concert renommé Service implementation.

2. <definition> renommé <description>.
3. <portType> est devenu <interface>.
4. <port> renommé <endpoint>.
5. <message> a été retiré et définie à l’intérieur de l’opération par <xs:element>.
La description comportementale consiste à décrire l'ordre d'invocation des opérations d'un
service, Un service peut avoir plusieurs descriptions comportementales tel que chaque
description est une vue sur le comportement possible du service dans une interaction donné,
plusieurs approche ont été proposé pour décrit la description comportementale : OWL-S,
WSCL, WSMO Web Service Interface, etc.
II.3. Le principe de fonctionnement d’un service web
Le scénario de la figure 2.3 présente le principe de fonctionnement d’un web service, en
d’autre terme, le processus de l’invocation de services.

L’annuaire de
service (UDDI)

Dé
ou SOAP Publier
vr
e
Appeler
Consommateur Fournisseur
Application Clients Exploite Service

Figure 2.3- fonctionnement global d’un service web

Toute d’abord le fournisseur de service publie ses services dans un annuaire de services, ces
dernies serons disponible, lorsqu’un client demande d’utiliser un service, il cherche dans
l’annuaire les services qui répond à ces besoins, ensuite l’annuaire renvoie une liste de services
disponibles, la liste contient la description de chaque service et ses fournisseurs (numéro de
téléphone, adresse, etc.), un contrat est mis en place concernant les conditions d’utilisation,
dont le fournisseur doit respecter le bon fonctionnement de service et l’utilisateur doit
respecter les conditions d’utilisation, comme : le payement si nécessaire, n’utilise pas le service
dans un contexte malveillants, etc.
Le protocole SOAP est utilisé pour l’échange des messages entre les acteurs : fournisseur,
consommateur et l’annuaire.
II.4. La composition des services
Les architectures orientées services soufre des problèmes lors de l’intégration des services
dans les environnements distribués, l’objectif de l’intégration est de fournir un service qui offre
une fonctionnalité qui n’est pas fournie par les autres services. Pour résoudre ce problème,
plusieurs travaux ont été proposés, avant de discuté les détails, nous allons présenter quelques
définitions et types de composition.

II.4.1 Définition
La composition est le processus de sélection, la combinaison et l’exécution des services web,
pour atteindre à l’objectifs de l’utilisateur »,
II.4.2 Les types de composition
Dans la littérature, nous distinguons les types de composition de services web : la
composition manuelle, la composition semi-automatique et la composition automatique.

 La composition manuelle

La composition manuelle repose sur l’expert qui génère la composition, car il nécessite des
connaissances préalables sur la programmation, l’expert fait le choix pour construire leur
processus de composition, si par exemple un service web destiné à l’utilisateur supporte ce
type de composition, l’utilisateur rejette cette application dans le cas où l’utilisateur n’est pas
un expert.

 La composition semi-automatique

L’annotation sémantique des fichiers de description des services permet une découverte
semi-automatique et plus précise. L'utilisateur exprime sa requête en fonction des concepts et
des instances de l'ontologie de référence utilisée pour annoter les descriptions des services. Le
système pré-sélectionne les services susceptibles de satisfaire la requête de l'utilisateur. Ce
dernier intervient pour choisir le service qui lui semble le plus pertinent parmi ceux pré-
sélectionnés.

 La composition automatique
Cette technique repose sur une composition automatique et ne nécessite pas l’intervention humaine,
le choix de la composition est fait par un moteur de composition intelligent, ce dernier fonctionne d’une
manière dynamique et choisit les services pertinentes selon des critères fonctionnelles pour répond au
besoin de l’utilisateur, le mécanisme de composition dans cette technique est transparent à l’utilisateur,
OWL-S (Semantic Markup for Web Services) est une approche sémantique pour la composition
automatique qui présente une ontologie de processus spécifiant la composition en trois classes de
processus :
1. Le processus atomique : correspond à l’action qui peut être engagé par le service afin
d’effectuer une tâche avec une seule interaction, c’est un processus invocable qui s’exécute dans
un seul pas, possède comme input un message et effectue ces fonctionnalités puis retourne
comme output ces résultats.
2. Le processus simple : est processus non exécutable et non invocable, un processus simple est
utilisé pour fournir une vue de certains processus composés ou processus atomiques.

3. Le processus composite : correspond à l’action qui peut être effectué par l’engagement de
plusieurs services, le processus composite peut être décomposé en sous-processus non
composable ou composable, la décomposition spécifier par des instructions du contrôle comme
séquence, split, split-join, choise, etc. et les instructions de branchement comme if-then-else,

II.4.3 les approches de composition des services

Il existe deux approches pour la composition des services, la composition statique et la composition
dynamique, la figure 2.4 présente ces deux approches, la composition statique repose sur le processus
métier en utilisant la technique de chorégraphie ou d’orchestration, et la composition dynamique
repose sur les services qui sont en cours d’exécution selon ses fonctionnalités et ses disponibilités.

La composition
Service web
Service Web sémantique

La composition statique Composition

dynamique

Orchestration choreography Composition

sémantique

Figure 2.4 - les types de composition.

I.5. Processus métier (BPEL)

I.5.1. La structure d’un processus métier

Dans cette section, nous allons présenter la structure syntaxique du WS-BPEL, la figure 2.5 résume la
structure de base d’un processus métier.
 1. <partnerLinks> : définit les différentes parties qui interagissent avec le processus métier, un
<partnerlink> pourrait être n'importe quel service invoqué par le processus, ou le processus
invoqué par le service, ainsi chaque <partnerlink> possède un rôle.
2. <documentation> : pour annoter la définition d’un processus métier.
3. <variables> : cette partie définit les variables traitées par le processus.
4. <faultHandlers> : cette partie gère les exceptions lorsque les opérations sont invoqué dans des
situations incompatible qui provoque un mauvais fonctionnement de ces opérations.

Processus

Processus
documentation
.....
partnerLinks
partnerLink
partnerLinkType

myRole

variables

faultHandlers
.....

Figure 2.5 - La structure de BPEL

I.5.2. Les activités d’un processus métier

Chaque processus métier possède une activité principale, le tableau suivant illustre les activités du
processus métier.
 Les activités Le symbole Description
Permet de mettre le processus métier en
<receive> attente, et de le terminer lors de la réception
d’un message.

<reply>

<invoke> Invoqué le service web approprie.

Est une activité qui permet de répéter une

<while>
activité à chaque où la condition est vrai.
Sert à répéter un bloc d’activité jusqu’à ce
<repeatUntil>
que la condition soit vraie.
Cette activité permet de boucler les activités
d’une manière parallèle ou séquentielle. Le
<forEach>
nombre d’itérations est la différence entre le
nombre maximal et minimal.
Cette activité attends un message parmi
<pick> plusieurs, lorsque le message est arrivé le
pick exécute le block d’activité qui lui associe.
Est utilisé pour spécifier et exécuter les
activités d’une manière concurrente, est se
<flow>
termine lorsque tous les activités sont
exécutés d’une manière séquentielle.
Cette activité permet de valider les valeurs
des variables par rapport aux autres associes
<validate>
à XML et les définitions des données dans le
WSDL.

Tableau 2.1 - La structure de BPEL

I.5.3. Les standards de l’orchestration (BPEL4WS)

Business Process Execution Language for web service, issu du consortium OASIS, avec la
première version 1.1 en 2004, ensuite la version 1.1 en 2007, est un langage standard fondé sur
l’XML destiné à exécuter les procédures de l’entreprise, et décrit le processus de composition
des services web élémentaires. Un processus métier peut être décrit en deux modes
essentielles, le processus métier abstrait et le processus métier exécutable, l’objectif de
BPEL4WS est de modéliser le comportement de processus à la fois exécutable et abstrait.

 le processus métier abstrait : ou le protocole métier spécifier pour l’échange des

messages, il décrit la description de rôle de processus (n’est pas conçue pour exécuter),
 et peut faire cacher certains détails opérationnels concrets, avec un ou plusieurs cas
d’utilisation, un cas correspond à la description du comportement observable d’un ou
plusieurs services fournis par le processus exécutable.

 le processus métier exécutable : est un processus conçue pour être exécuter, il décrit le
comportement actuel du processus participé à une interaction métier.

I.6. Web service calcul : WSVirement (TP)

Le but est de ce TP est de réaliser un BPEL qui fait l’invocation de un service web qui permet de réaliser
un service composite virement sous NetBeans. Le service virement se compose de deux sous-
services : donneur et bénéficiaire. Le service donneur est décrit par les opérations: verif_coord et
créditer. Le service bénéficiaire est décrit par les opérations : verif_coord et débiter. La figure suivante
présente un exemple simple d’invocations des opérations de service donneur.

Montant 100

code 1 Donneur.crediter
Donneur.verif_coord [solde = solde -100] 12
Mot passe 1000

1. Compléter ce processus par l’invocation des opérations de service bénéficiaire ?

2. Réaliser le BPEL de service virement sous Netbeans?

I.7. Conclusion
Dans ce chapitre, nous avons étudié les aspects importants des architectures logicielles à base des
services, la description du service et les et les approches de composition des services. La première gère
un aspect important pour fournir des modèles d’architecture interopérables. Et la deuxième décrit la
sélection pour choisir un service parmi plusieurs, ce service établie les objectifs fixé par l’utilisateur.