A PPROCHE O RIENTEE S ERVICE

L’apparition de l’approche orientée service (Service-Oriented Computing ou SOC) a changé le

contexte d’exécution des applications du monde industriel. En effet, peu avant l’an 2000, l’évolution des

infrastructures des réseaux en termes de fiabilité et de performance a offert aux entreprises la

possibilité de décentraliser et d’interconnecter (B2B

⁶

[AFHAl99]) leurs applications. Cependant

l’approche à composant restreint la flexibilité requise pour ce genre d’application. Par rapport à

l’approche à composant, l’approche orientée service offre une plus grande flexibilité et réutilisabilité. En

effet, cette approche propose un style architectural permettant de composer rapidement et facilement

des applications à partir d’éléments distribués et hétérogènes nommés services [PTDLK06]. Cette

approche a été plébiscitée au travers d’une de ses implantations : les services Web, qui permettent de

définir une application composée de services distribués et hétérogènes.

4.2.1 Définition

L’approche orientée services *Pap03+ est basée sur l’idée qu’une application peut être réalisée par

composition des services logiciels mis à disposition par des fournisseurs divers ([BLAl00] [TBB03]

appellent ce modèle "service-based model of software"). Comme pour l’approche à Composant, il n’y a

pas de réel consensus sur la définition du concept de Service. Cependant, les trois définitions suivantes

permettent de recouvrir la majorité des courants du paradigme à Service.

Dans cette définition, A. Arsanjani recentre la définition de service sur le patron d’interaction

promut par cette approche. C’est-à-dire qu’un service est découvrable via une description. Cette

description de service est utilisée :

 pour la recherche/sélection ;

 pour l’établissement d’une liaison entre le consommateur et le fournisseur de service ;

 finalement pour l’invocation du consommateur vers le fournisseur.

6

Business to Business

“A service is a software resource (discoverable) with an externalized service description.

This service description is available for searching, binding, and invocation by a service

consumer. Services should be ideally be governed by declarative policies and thus support

a dynamically reconfigurable architectural style.”

Le consortium OASIS

⁷

définit un service comme étant un mécanisme permettant d’accéder à une

ou plusieurs fonctionnalités. Un service est accessible au travers d’une interface conforme à un

ensemble de contraintes et de politiques d’accès. Un service est une boîte noire où seules les

informations nécessaires à l’utilisateur pour la sélection et l’invocation sont disponibles. Il faut

cependant remarquer qu’il est difficile de discerner une information utile d’une information inutile pour

le choix d’un service.

Dans cette définition, M.P. Papazoglou présente les Services comme étant des entités logicielles qui

sont :

 auto-suffisantes pour fournir ses fonctionnalités ;

 indépendantes des autres services et de la plate-forme d’exécution ;

 décrites par des contrats d’interface.

De plus, il considère que les technologies SOA (Service-Oriented Architecture ;voir section 4.2.3 de

ce chapitre) doivent assumer la découverte dynamique, l’invocation et la reconfiguration des

applications orientées services.

Ces trois définitions portent et insistent sur trois aspects de l’approche orientée service : le patron

d’interaction [Ars04], l’interopérabilité via une description abstraite [OASI06] et « l’atomicité » et

l’indépendance pour la définition des applications [PH07].

4.2.2 Style architectural

Le patron d’interaction que promeut l’approche orientée service est un des principaux apports de

cette approche. Il faut cependant remarquer que ce patron d’interaction n’est pas une réelle innovation

7

Advancing Open Standards for the Information Society : http://www.oasis-open.org/

"A service is a mechanism to enable access to one or more capabilities, where the access is

provided using a prescribed interface and is exercised consistent with constraints and

policies as specified by the service description. A service is accessed by means of a service

interface where the interface comprises the specifics of how to access the underlying

capabilities. There are no constraints on what constitutes the underlying capability or how

access is implemented by the service provider. A service is opaque in that its

implementation is typically hidden from the service consumer except for (1) the

information and behavior models exposed through the service interface and (2) the

information required by service consumers to determine whether a given service is

appropriate for their needs."

Extrait de [OASI06]

“In an SOA, software resources are packaged as “services”, which are well defined,

self-contained modules that provide standard business functionality and are independent of

the state or context of other services.*…+ A service in SOA is an exposed piece of

functionality with three essential properties. Firstly, an SOA-based service is self-contained,

i.e., the service maintains its own state. Secondly, services are platform independent,

implying that the interface contract to the service is limited to platform independent

assertions. Lastly, the SOA assumes that services can be dynamically located, invoked and

(re-)combined.”

en soi. En effet, il existait déjà, dans les applications distribuées, un niveau d’indirection entre les clients

et les serveurs, où les clients passent par le biais d’un intermédiaire qui traduit le nom logique du

serveur cible par l’adresse physique (cf. DNS, les courtiers ODP [IRB94]). Cependant l’approche orientée

service pousse le raisonnement plus loin : on ne recherche plus un serveur/élément logiciel par rapport

à son nom mais par rapport aux fonctionnalités qu’il fournit. En d’autres termes on recherche une

fonctionnalité (un service) et non un fournisseur.

Le patron d’interaction du SOC est basé sur trois acteurs :

 Les fournisseurs de services qui offrent des services

 Les consommateurs de services qui requièrent et utilisent des services offerts par des

fournisseurs

 Un registre de service permettant aux fournisseurs de publier leurs services et aux

consommateurs de découvrir et de sélectionner les services qu’ils veulent utiliser.

Dans ce patron d’interaction, le fournisseur de service publie sa spécification auprès d’un

courtier/registre de service. Lorsqu’un Consommateur de service requiert un service, celui-ci recherche,

auprès d’un ou plusieurs registres de service, un service conforme à ses besoins ; une fois le service

sélectionné, le consommateur interagit avec le fournisseur de ce dernier (cf. Figure 28). Notons que

seule la spécification du service est partagée entre les acteurs.

Figure 28 Patron d'interaction du SOC

Grâce à ce patron, les applications orientées service possèdent les caractéristiques suivantes :

 Un couplage faible (Loose Coupling) : comme la seule information partagée entre les

fournisseurs et les consommateurs est la spécification de service, le couplage entre ces deux

entités est faible.

 Des liaisons retardées(late binding): la liaison entre les fournisseurs et les consommateurs

est établie seulement lorsque le consommateur recherche un service et que ce dernier est

trouvé.

 Un chargement paresseux (lazy loading) : une des conséquences de la liaison retardée est

de permettre de charger l’implémentation et l’instance du service seulement au dernier

moment, c’est-à-dire lors de l’invocation du service.

 Un masquage de l’hétérogénéité (technology neutral) : grâce au couplage faible, plus

précisément grâce à la spécification : un consommateur n’a pas à connaitre les détails

d’implémentation du fournisseur de service.

 Un masquage de la distribution (location transparency) : les consommateurs n’ont pas à

connaitre à l’avance la localisation des services. Cette information est obtenue au travers du

registre de services.

Un point important est que ce patron d’interaction peut avoir lieu à n’importe quel moment dans le

cycle de vie du logiciel; c'est-à-dire que les services peuvent être recherchés lors du développement

mais également à l’exécution. Nous nous intéresserons plus attentivement à ce cas dans la suite de ce

chapitre.

4.2.3 Service : de l’approche à la technologie

Un service est une entité boîte noire qui fournit des fonctionnalités. L’approche ne dit pas

comment implanter un service, elle dit seulement qu’il doit spécifier ses fonctionnalités et les

informations « pertinentes » pour qu’un consommateur puisse les sélectionner et y accéder en fonction

de ses besoins.

Les technologies mettant en œuvre l’approche orientée service sont appelées des architectures

orientées service (Service Oriented Architecture ou SOA) [PaGe03]. Un SOA est un ensemble de

technologies permettant de mettre en place des applications suivant le paradigme de l’approche

orientée service. Un SOA implante les primitives du SOC en utilisant diverses technologies. Par exemple,

les services web sont un SOA, alors qu’OSGi (cf. [OSGia]) en est un autre. Ces deux SOA utilisent des

technologies très différentes.

Les technologies choisies pour mettre en place un SOA dépendent du domaine métier et des

objectifs poursuivis. Par conséquent, la conception d’un service et la définition d’une application par

composition dépendent du SOA utilisé. Tous les SOA ont les mêmes mécanismes de base qui assurent la

publication, la découverte, la composition, la contractualisation et l’invocation des services. Cependant,

chaque domaine métier possède des propriétés non-fonctionnelles et des mécanismes propres (cf.

Figure 29) tels que l’administration, les transactions, la sécurité... Dans [PTDL07], M. P. Papazoglou

hiérarchise ces mécanismes de base dans une pyramide selon trois niveaux :

 Le niveau fondation (base de la pyramide) contient les fonctionnalités nécessaires à

l’approche orientée service : spécification, publication, découverte, sélection et liaison.

 Le niveau composition contient les mécanismes qui permettent de composer une

application en termes de services et de valider sa conformité.

 Le dernier niveau contient les mécanismes qui permettent d’administrer et de superviser les

compositions et leurs services.

De manière transversale à ces niveaux, une architecture orientée service étendue doit prendre en

considération la gestion des propriétés non-fonctionnelles, comme la sécurité ou encore la qualité de

service. Notons cependant que peu de SOA sont conçus dans l’optique d’être étendus par un domaine

métier. Généralement, ces extensions sont standardisées puis incorporées dans le SOA. En d’autres

termes bien que les SOA offrent des mécanismes étendus du SOC, cette extensibilité reste en général

limitée.

4.2.4 Dynamisme et Sélection

Si on s’en tient à la définition, l’approche orientée service permet d’être hautement dynamique. En

effet, le couplage faible permet – via la spécification du service (interface) – de lier un consommateur de

service à un service seulement à l’exécution, voir de retarder la sélection du fournisseur et la création de

la communication au moment de son utilisation. Cette propriété, nommée liaison tardive (Late Binding),

était déjà utilisée par l’approche à composant (cf. section 4.1.4 de ce chapitre). Cependant, le fait que la

communication entre un client et un fournisseur se fasse par sélection, offre un second avantage : la

substituabilité. En effet, un service est considéré sans état [OASI06] [PH07], conséquemment il est

possible de substituer un fournisseur de service par un autre entre deux invocations.

La substitution peut se faire pour deux raisons :

 Le service utilisé par le consommateur n’est plus disponible, il faut donc qu’il en sélectionne un

autre (auto-réparation cf. Figure 12) ;

 Un autre service est disponible offrant de meilleures caractéristiques (par exemple une meilleure

qualité de service) (auto-optimisation cf. Figure 12).

La deuxième raison (auto-optimisation) nécessite un mécanisme de notification. Il faut noter que ce

mécanisme n’existe pas nécessairement dans tous les SOA.

En résumé, outre la flexibilité apportée par la liaison tardive et le chargement paresseux (lazy

loading), l’approche orientée service permet théoriquement la définition d’applications dont

l’architecture ou la composition change dynamiquement à l’exécution. Cependant cela reste souvent

théorique (cf. les sections 4.1.1 et 4.3.3 de ce chapitre).

4.2.5 Synthèse

Le but de l’approche orientée service est de permettre la construction d’applications à partir

d’entités logicielles particulières, les services, tout en assurant un couplage faible. Cette approche n’est

pas une technologie ; elle peut être vue comme un style architectural.

Dans cette approche les concepts d’implémentation ou d’instance n’ont pas de sens, car cette

approche définit un patron d’interactions permettant de composer des applications à partir de

ressources atomiques, partageables et potentiellement distribuées. Dans cette vision, ce qui est

important c’est que l’on puisse accéder aux fonctionnalités ; « savoir quelle est son implémentation »,

« savoir si l’on accède à une instance » sont des concepts non pertinents. En effet ce qui importe pour

un utilisateur c’est que le service soit une spécification de fonctionnalités atteignables au travers des

points d’invocation.

Par conséquent, pour définir une application orientée service il faut une technologie SOA

fournissant les mécanismes de base ainsi que des mécanismes étendus pour le support de propriétés

non-fonctionnelles. Il existe de nombreux SOA (CORBA [Corb08], Jini [Jini], service Web, OSGi [OSGi-s],

iPOJO [iPOJO-s]), qui peuvent être catégorisés selon deux approches du SOC, qui sont :

 Composant à Service ;

 Composant Orienté Service.

Dans le document Sam : un environnement d'exécution pour les applications à services dynamiques et hétérogènes (Page 56-61)