Le document présente une introduction aux architectures orientées services (SOA) en se concentrant sur leurs besoins, définitions, et principes. Il souligne l'importance de l'adaptabilité des entreprises aux marchés, et décrit les caractéristiques des services, tels que le couplage faible et la mutualisation. La SOA permet de décomposer les fonctionnalités en services élémentaires pour une intégration et une gestion efficaces des systèmes informatiques.

1. Institut National des Sciences Appliquées et de Technologie
Architectures Orientées Services
Chapitre 1 – Introduction aux Architectures Orientées
Services
Dr. Lilia SFAXI
LA3 SIL - 2013-2014

2. 1
Plan du Chapitre

Besoins de la SOA

Notion de Service

Architecture Orientée Services : Définition et Principes

3. 2
Les Besoins de la
SOA
CHAPITRE 1 :
INTRODUCTION AUX TECHNOLOGIES
WEB &
ARCHITECTURES ORIENTÉES
SERVICES

4. 3
Besoins de l’Architecture Orientée Services

Problématique d’intégration en entreprise
o
o

Les entreprises doivent s’adapter et être réactives aux variations des marchés  Impact
sur les SI des entreprises
C’est l’activité qui doit piloter la technologie et non l’inverse
Prise en compte de l’évolution des besoins fonctionnels à la conception des
application
o
La technologie doit apporter la flexibilité

Éviter le décalage entre besoins métiers et leur réalisation

Besoin de réutilisation des fonctionnalités (non fournie par le modèle MVC classique)

Processus métiers de plus en plus inter-départementaux  coût considérable dans
la gestion de flux entre départements

5. 4
Évolution des Architectures
Hier : Architecture en Spaghetti
Demain : Architecture Urbanisée

Organisation du SI à l’image d’une ville

Développement coûteux

Interconnexions redondantes

Le découper en modules autonomes

Grande complexité


Réutilisation et maintenance difficile
Localiser les zones d’échange
d’informations

6. 5
De plus en plus d’abstraction

Procédures et fonctions
o

Modules
o

groupes de fonctions, de méthodes et de traitement, sous forme de
bibliothèques
Objet
o

sous-programmes réalisant une action
brique de base logicielle, représentant une entité du monde
physique, encapsulant un état et des traitements
Composant
o
o
séparation des préoccupations techniques et fonctionnelles
o

élément logiciel contenant du code compilé (donc opaque)
définit une interface pour communiquer avec les autres composants, et une
interface de configuration
Service

7. 6
Notion de
Service
CHAPITRE 1 :
INTRODUCTION AUX TECHNOLOGIES
WEB &
ARCHITECTURES ORIENTÉES
SERVICES

8. 7
Service

Périmètre fonctionnel qu’on souhaite exposer à un certain type de
consommateurs

Ensemble de fonctionnalités qui ont un sens

Expose un petit nombre d’opérations offrant un traitement de bout en
bout

Est implémenté par un fournisseur et utilisé par un consommateur

9. 8
Caractéristiques d’un Service (1/2)

Large Granularité (coarse-grained)
o

Interface
o

Les opérations proposées par un service encapsulent plusieurs fonctions et
opèrent sur un périmètre de données large au contraire de la notion de
composant technique.
Un service peut implémenter plusieurs interfaces, et aussi plusieurs services
peuvent implémenter une interface commune.
Localisable
o
Avant d’appeler (bind, invoke) un service, il faudra le trouver (find).

10. 9
Caractéristiques d’un Service (2/2)

Instance unique
o
o

À la différence des composants qui sont instanciés à la demande et peuvent
avoir plusieurs instances en même temps, un service est unique.
Un service correspond au design pattern Singleton.
Couplage faible (loosely-coupled)
o
o
Ces standards assurent le découplage, c-à-d la réduction des dépendances.
o

Les services sont connectés aux clients et autres services via des standards
Ces standards sont en général des documents XML comme dans les web
services
Synchrone ou Asynchrone

11. 10
Couplage Fort vs. Couplage Faible

Couplage Fort
Agent
Accord de Prêt
Compte
Prêt
SMS Gateway
calculerRisque
vérifierSolde
créerPrêt
envoyerConfirmation
o
« Agent » est lié à « Accord de Prêt », qui est lié à « Compte »
o
« Prêt » est lié à « SMS Gateway »
Objets

12. 11
Couplage Fort vs. Couplage Faible

Processus
Métier
Couplage Faible
Processus de Prêt
Vérification de Solde
Calcul de Risque
Création de Prêt
Notification par SMS
o
Chaque entité (service) a un fonctionnement indépendant des autres
o
Le processus métier « Processus de Prêt » permet d’orchestrer les services  Couplage
lâche ou faible
Services

13. 12
Types de Services

Les services de présentations ou de référencement
o

Les processus métiers
o

composés de tâches décrites et faisant appel éventuellement à d’autres
services.
Les services de gestion et d’accès aux bases de données
o

vers les informations affichées et les formulaires de saisies de données.
permettent la gestion des données partagées
Les services d’intégration
o
en charge de la messagerie ou l’échange de données tant à l’intérieur que
vers l’extérieur comme la gestion des courriers électroniques

14. 13
Architecture
Orientée Services :
Définition et
Principes
CHAPITRE 1 :
INTRODUCTION AUX TECHNOLOGIES
WEB &
ARCHITECTURES ORIENTÉES
SERVICES

15. 14
Architecture Orientée Services

SOA (Service Oriented Architecture)

Style
partir de services métiers communs
mutualisés pour un ensemble de lignes métiers ou d’applications.

Permet d’intégrer et de manipuler les différentes briques et composants
applicatifs d’un système informatique et de gérer les liens qu’ils
entretiennent

Objectifs
o
Décomposer une fonctionnalités en un ensemble de fonctions basiques
(services) fournies par des composants
o
Décrire finement le schéma d’interaction entre ces services

16. 15
Du point de vue des acteurs…
Des services que l’entreprise
souhaite exposer à ses clients et
partenaires, ou à d’autres
parties de l’organisation
Dirigeant
Une architecture basée sur un
fournisseur, un consommateur et
une description de service
Architecte
Un style de programmation avec
ses
standards, paradigmes, technol
ogies et outils associés
Développeur
Un intergiciel offrant des
fonctionnalités en terme
d’assemblage, d’orchestration,
de surveillance et de gestion des
services
Intégrateur

17. 16
Principes de la SOA (1/2)

Diviser pour régner
o

Alignement métier
o

Substituer la découpe strictement applicative par une structuration en composants plus
réduits
faire évoluer.
Construire et organiser le système
ses constituants.
partir des réalités métiers, qui doivent se retrouver dans
Neutralité technologique
o
Assurer une indépendance totale entre les interfaces et les implémentations.
o
L’élément qui utilise un service ne doit pas être contraint ni par la technologie
).

18. 17
Principes de la SOA (2/2)

Mutualisation
o
o

Favoriser la réutilisation de services métiers par plusieurs lignes métiers ou applications.
Permettre la construction de services de haut niveau par combinaison de services existants.
Automatisation des processus métier
o

Isoler la logique des processus métiers sur des composants dédiés qui prennent en charge
les enchainements de tâches et les échanges de flux d’information.
Echanges orientés Document
o
Les informations échangées par les services possèdent une structure propre, guidée par les
besoins métiers.
o
On privilégie la transmission de contenus complets et utilisables au profit d’accès direct aux
structures de type objet ou relationnel.

19. 18
Sources

Cours



M. Mecella : A very short Introduction to Web Services, Université de Rome
A. Occello : Module Architecture SOA et Workflow, Polytechnique de Nice
Livre Blanc

Gilbert Raymond, SOA : Architecture Logique - Principes, structures et bonnes
pratiques, Softeam, Paris

20. 19
Références

[Casati01] F. Casati, M.C. Shan, D. Georgakopoulos (eds.): Special Issue on
e-Services. VLDB Journal, 10(1), 2001, Based on the 1st International
Workshop on Technologies for e-Services (VLDB-TES 2001)

[Mecella01] M. Mecella, B. Pernici: Designing Wrapper Components for eServices in Integrating Heterogeneous Systems. VLDB
Journal, 10(1), 2001, Based on the 1st International Workshop on
Technologies for e-Services (VLDB-TES 2001)

[W3C04] W3C Working Group Note, Web Services Architecture
Requirements, 11 Feb. 2004