Les Interfaces
Une interface (ou ensemble d'opérations),
représente le ou les services d'un composant. Elle peut
être « synchrone » ou
« asynchrone » (car fonction de certains
évènements) ou encore dite « de
contrôle » lorsqu'elle regroupe les opérations
nécessaire à la validation d'un contenu par exemple (formulaire
HTML, document XML etc ...), d'une authentification ... Une même
interface peut se situer sur plusieurs ports.
Les ports
L'assemblage de plusieurs composants nécessite la mise
en oeuvre d'un ensemble de « ports requis » et de
« ports fournis ». Ils constituent des portes
d'accès au composant en terme de réponse à une invocation
(port requis) ou en terme d'invocation (port fourni). Ces ports
représentent le point d'ancrage d'un ensemble d'interfaces
cohérentes vis à vis des fonctionnalités qu'elles
apportent.
Les contrats
Le « contrat exigé » fixe les
critères (aussi appelés « dimensions ») de
compatibilité d'assemblage entre deux composants. Le « contrat
offert » quant à lui offre des valeurs mis en regard avec le
contrat exigé. Le langage d'expression des contrats est le langage des
contraintes UML : OCL, déjà présenté dans la
première partie. Un contrat peut être :
q syntaxique : dans la mesure où il définit
l'ensemble des opérations.
q sémantique : car il précise le fonctionnement
des opérations.
q pragmatique : lorsqu'il est a l'écoute de
l'environnement et entre autre des contraintes de temps, d'espace
(répartition des données).
Les connecteurs
Les connecteurs sont des objets permettant une interaction
entre plusieurs composants. Autant ils restent abstraits dans la partie PIM de
la démarche MDA, autant ils deviennent concrets dans la partie PSM. Ils
peuvent être de différentes natures : de diffusion quand il
s'agit de données à transmettre, de synchronisation, de
coordination etc ...
Résumé
L'informatique, science en mouvement, est en constant
renouvellement. D'abord laboratoire de quelques spécialistes, elle ouvre
progressivement ses portes au plus grand nombre, passant ainsi dans le domaine
publique. Les mentalités des usagers s'adaptent à son langage et
le système d'information s'ajuste à l'usage des utilisateurs.
Chaque nouveau cycle donne ainsi naissance à une mini-révolution
de plus, ravivant l'espoir de redonner plus de pouvoir aux utilisateurs.
Très vite, la difficulté d'intégrer un
système d'information complexe s'est traduite en syndrome
« spaghetti ». Des boites noires sont alors venues
s'ajouter au centre de l'assiette pour simplifier cette vision de flux. Mais,
si ces boites répondent à certains besoins par un niveau
d'abstraction supplémentaire, elles ne constituent néanmoins que
des couches apportant leur propre lot de code.
La démarche SOA tente cette fois d'aligner la
stratégie IT sur celle des métiers par une participation active
des utilisateurs aux définitions de processus. Pour que le
« plat de spaghetti » ne devienne pas un
« rizotto de services métiers », SOA ne se focalise
plus sur une technologie mais prend corps autour d'une démarche
architecturale. Cette force constitue néanmoins sa faiblesse car tout ne
repose plus sur le seul bon vouloir des informaticiens mais sur l'entreprise
toute entière.
Mots clés : SOA, Architecture, Services, Processus
Métiers, Interopérabilité,
« Réutilisabilité ».
Summary
Computing, science in movement, is in constant renewal. At
first laboratory of some specialists, it gradually opened its doors to most
large number, so passing in the common domain. The mentalities of the users
adapt themselves to its language and the information system adjusts in aid of
the users. Every new cycle so gives birth to a mini-revolution furthermore,
reviving the hope to restore the power to the users.
Very fast, the difficulty integrating a complex information
system is symbolized by the « pasta theory » on software.
Black boxes are then deposited in the center of the plate to simplify this
vision of stream. But, if these boxes answer certain needs by a level of
supplementary abstraction, they establish nevertheless layers bringing their
own piece of code.
The step SOA tries this time to align the IT strategy on
Business strategy by an active participation of the users in the definitions of
process. So that the «pasta theory on software» does not become a
«rizotto of business services», SOA does not focus any more on a
technology but takes shape around an architectural step. This strength
constitutes nevertheless its weakness because everything does not base any more
on the only good will of the computer specialists but on the whole company.
Keywords: SOA, Architecture, Services, Business Process,
Interoperability, Reutilisability.
| 
