Modèle
d'architecture SOA 66(*)
Le pattern d'architecture SOA est basé sur la
constitution de groupes de classes appelés
« catégories » (exemple ci dessous :
« Gestion commerciale »). Les traitements sont traduits en
services et sont rattachés aux catégories qui disposent d'une
interface (port). Comme précédemment, les services ne peuvent
interagir entre eux qu'à condition qu'ils se situent dans la même
catégorie. Si cela n'est pas le cas, il faut alors passer par un moteur
d'orchestration qui assure un découplage.
_
Message
Message
Message
Service Exposé
Illustration 30 :
Données d'échange et Format pivot XML (Master Data
Managment)
Illustration de la
« réuitisabilité »
Le trigramme SOA apparaît en 1996 dans une note de
recherche du Gartner Group :
« Service-oriented architecture (SOA) is a
client/server software design approach in which an
application consists of software services and software
service consumers (also known as clients
or service requesters). SOA differs from the more general
client/server model in its definitive
emphasis on loose coupling between software components,
and in its use of separately standing
interfaces ».
Gartner Group, 1996.
(Sources: SSA Research Note SPA-401-068, 12 Avril 1996,
"'Service Oriented' Architectures, Part 1"
SSA Research Note SPA-401-069, 12 Avril 1996, "'Service
Oriented' Architectures, Part 2")
Dans cette note, le groupe Gartner met l'accent sur le
découplage et la réutilisabilité des services à
l'image de ce qui existe au niveau des ESB.
Lorsque la notion de service est évoquée, il
faut penser au service métier (par exemple : « Calculer
un taux de marge nette ») mais il existe un autre type de services
dits « d'infrastructure » ou
« techniques » permettant aux services métiers de
fonctionner au sein du SI (« Création de compte
utilisateur » par exemple, ou « transfert de
fichier » ...). Ils reflètent un besoin transverse et peuvent
ainsi répondre à la même problématique de plusieurs
métiers.
Les services sont classés en granularité fine
(règles métier, fonctions, comme par exemple : le
« calcul de marge », la « recherche d'une
adresse ») ou grosse (la « gestion des
comptes »). C'est sur cette base que se construit la
réutilisation des services, car si les services de granularité
fine ne peuvent pas se suffire à eux même, ils permettent quant
à eux de définir et d'utiliser des règles de gestion
stables pour l'ensemble des métiers de l'entreprise, quelque soit la
manière dont ils ont été utilisés (portail, batch
etc....). L'exemple si dessous tente de montrer simplement combien le concept
de service apporte de la lisibilité au code mais aussi des
possibilités de réutilisation.
En annexe, est illustrée la flexibilité
apportée par le concept de service.
* 66 Pour
approfondir : Architecture Orientée Services (SOA) - Une
politique d'interopérabilité. [OCT-SOA].
| 
