> Comment
définir une architecture orientée services ?
Lancée par le Gartner, la notion
de SOA (pour architecture orientée services) définie un modèle
d'interaction applicative mettant en oeuvre des connexions en couplage lâche
entre divers composants logiciels (ou agents). Ici, on entend par "service"
une action exécutée par un composant "fournisseur" à
l'attention d'un composant "consommateur", basé éventuellement
sur un autre système.
>
Quels sont ses
éléments constitutifs ?
La mise en oeuvre de connexions en couplage
lâche implique l'utilisation d'interfaces d'invocation et de vocabulaires de description
de données qui soient communs à l'ensemble des agents, à la fois
côté fournisseurs et côté consommateurs. Plus ces éléments
seront avancés, en termes de schémas de structuration d'informations et de fonctions
de requêtage, plus les services délivrés pourront supporter de possibilités
de traitement différentes et plus leur marge d'évolution sera importante.
Une fois généralisée à l'ensemble du système
d'information, ce dispositif de communication universelle permet en principe de
réutiliser et de combiner à loisir les applicatifs métier,
au sein de processus par exemple. Et ceci de façon très réactive.
C'est d'ailleurs le principal apport que le Gartner perçoit dans ses analyses.
Selon l'institut, le SOA contribuera à accélérer la capacité
des entreprises à s'adapter à un nouveau contexte de marché.
> Quelle différence entre
une architecture orientée objet et une SOA ?
Au sein d'une architecture orientée objets,
les données manipulées sont directement associées au mode de traitement qui leur
est appliqué (cf. les méthodes et les classes du langage Java). Ce n'est
pas le cas au sein d'une architecture de SOA dans laquelle ces deux éléments sont
dissociés. Le terme de "service" vient d'ailleurs de cette caractéristique. Par
définition, un service a en effet pour but de proposer un résultat particulier,
en fonction d'informations qui lui sont envoyées par un tiers. Ce dernier pouvant
d'ailleurs très bien décider de transmettre parallèlement ces données
à un service complémentaire ou même concurrent qui les prendrait
en charge de la même façon.
> A quelles technologies
s'adosse une architecture de type SOA ?
Apparues assez récemment sous l'impulsion
de plusieurs grands éditeurs (dont Microsoft, IBM et Sun), les interfaces
XML de type Web Services reposent une bibliothèque de standards conçus
précisément pour construire une architecture orientée services. Les uns
couvrant les questions d'invocation de composants (WSDL, etc.), les autres les
problématiques liées au transport et à la description des
informations transmises (SOAP, etc.).
Force est de constater que des technologies plus anciennes (nées à
la fin des années 1990) poursuivaient les mêmes objectifs. Les plus
connues d'entre-elles sont Corba et DCOM. Ces alternatives qui peuvent se révéler
intéressante pour certains projets n'en demeurent pas moins limitées :
à la différence des Web Services, elles restent cantonnées à
des environnements d'exécution bien particuliers - les serveurs d'applications
J2EE pour Corba et les systèmes Microsoft dans le cas des composants DCOM.
> Quel lien entre
SOA et bus de services d'entreprise (ESB) ?
Alors que les SOA font avant tout référence à un concept
d'architecture, les bus de services d'entreprise désignent les plates-formes
d'intégration du marché mettant en application cette notion. Schématiquement,
ces produits sont conçus pour administrer et orchestrer des liens entre
services applicatifs, pourquoi pas au sein de processus métier. Bref, il
ne s'agit ni plus ni moins que d'EAI dont les connecteurs s'appuient sur des Web
Services (voir le panorama).
> Quels autres acteurs ?
Ce créneau est également occupé par des acteurs traditionnels
de l'EAI, comme WebMethods ou Seebeyond. Depuis peu, ces éditeurs cherchent
à mettre à jour leur solution en vue de supporter ces architectures
- le plus souvent par le biais de politiques d'acquisitions d'ailleurs.
C'est également le cas chez les fournisseurs
de progiciels de gestion intégrée (ERP). Conscients du potentiel
de ces nouveaux middleware, ils se sont lancés très tôt dans
la mise au point de couches de Web Services. Objectif poursuivi : faciliter
les appels de fonctions au sein de processus ou de systèmes d'orchestration
tiers (voir l'article).
|
[