|
|
PRATIQUE ALGO/METHODES |
|
|
|
Expliquez-moi... L'architecture orientée service |
|
Ce nouveau principe de conception d'application vise à libérer les développeurs grâce un usage fort des services Web.
(13/10/2005) |
|
|
Forum |
|
Réagissez
dans les forums
de JDN Développeurs
|
L'acronyme SOA, pour Service Oriented Architecture (architecture
orientée services), apparaît de plus en plus souvent dans les
spécifications des outils de développement : Eclipse
avec STP,
Oracle avec BPEL
Process Manager ou IBM avec son offre
SOA, les grands éditeurs se lance un à un
sur ce marché.
Ce n'est pas un hasard : le concept répond à un besoin d'abstraction
qui, lui-même, découle de la complexité grandissante
des projets informatiques.
Mieux développer, et surtout mieux maintenir les fonctionnalités
conçues : voici deux objectifs de l'architecture orientée
services.
Cette nouvelle couche d'abstraction fait suite à d'autres abstractions
créé au fur et à mesure des besoins et
des avancées technologiques : la création des fonctions
et procédures, la programmation orientée Objet, les logiciels
à base de composants.
L'architecture orientée services ambitionne
d'aider les développeurs à gérer l'hétérogénéité des "milieux
applicatifs" : l'objectif est d'autoriser les applications
ou service àcommuniquer et de travail ensemble, quel
que soit leur plate-forme respective.
La SOA
promet donc l'interopérabilité des applications par le biais
de services. Un service qui n'est rien d'autre qu'un composant
dont les interfaces et contrats d'utilisation sont connus, et
qui est indépendant de tout système. Pour ce faire, XML est
utilisé dans lors des échange d'informations, enrobé le plus
souvent d'une enveloppe SOAP (lire notre
article du 7 juillet 2005).
Plus généralement, une architecture SOA peut être
construire sans utiliser XML ni les services Web, mais avec
des formats de type CVS, ou des technologies comme Corba ou
COM/DCOM, mais XML offre certainement une plus grande ouverture.
L'architecture en elle-même se représente en faisant
intervenir trois acteurs : le consommateur, le service,
et le répertoire de services. Le consommateur correspond
à l'application cliente (ou à un autre service), qui
fait appel au service pour une tâche précise. Ce consommateur
trouvera les informations à propos du client au sein du répertoire
de services, où sont enregistrés et triés un grand nombre
de ceux-ci. Un répertoire peut être privé,
c'est-à-dire interne à l'entreprise, ou public.
Le service répond à trois fonctionnalités caractéristiques :
il est indépendant, il peut être découvert et appelé de manière
dynamique, et il fonctionne seul.
Le répertoire de services a un rôle primordial dans la SOA.
C'est lui qui reçoit la requête du consommateur, lui qui découvrira
le service idoine, et lui qui agira en tant que proxy
(intermédiaire) entre consommateur et service. En s'assurant
que les fournisseurs de services informent régulièrement les
répertoires de leurs nouveautés, le consommateur peut constamment
profiter de celles-ci sans pour autant devoir mettre à jour
ses méthodes.
Ainsi, une banque pourra mettre à jour son service de
calcul d'intérêt, et si celui-ci est enregistré
correctement sur un répertoire (public ou privé),
l'utilisateur pourra sans rien changer profiter des évolutions.
Le tout enfin, enfin, repose fondamentalement sur les services
Web. La SOA utilise tous les standards dédiés aux services Web
(XML, HTTP, WSDL, UDDI, SOAP...) pour s'assurer de l'interopérabilité
de son fonctionnement. Ce n'est pas pour autant qu'ils sont
synonymes : une SOA n'est pas en soi une technologie, mais un
principe de conception, tandis que les services Web en sont
une implémentation technologique. |
|
|