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.
 
Xavier Borderie, JDN Développeurs
 
 
Accueil | Haut de page