Architecture orientée services (SOA)

Architecture orientée services (SOA)

Ce chapitre présente une étude bibliographique autour des concepts, des approches et des technologies liés aux objectifs abordés dans le chapitre précédent : la gestion des propriétés non- fonctionnelles des services, la prise en compte de ces propriétés lors de l’étape de modélisation des processus métier et lors de la réconciliation entre les activités métier et les services techniques, et enfin la rationalisation de la gestion des services et de leurs métadonnées en utilisant la gouvernance SOA. Cet état de l’art sert de base au travail de recherche visant à atteindre ces objectifs. En nous basant sur la littérature, nous commençons par détailler l’architecture orientée service, sa brique principale : les services, les services Web ainsi que leurs propriétés non-fonctionnelles. Par la suite, nous introduisons les processus métier d’une façon générale avant de nous intéresser aux processus métier appliqués dans un contexte SOA. Nous étudions les standards existants pour la modélisation de ces processus et pour l’annotation avec des exigences non-fonctionnelles. Enfin, nous étudions la gouvernance SOA et les approches de sélection de services selon les exigences non-fonctionnelles. En quelques années, l’architecture orientée services est devenue un thème majeur pour le système d’information des entreprises. Elle représente une nouvelle approche de conception des applications qui fait gagner en flexibilité, en agilité et en réactivité au niveau du système d’information en reposant sur le principe de couplage lâche et tout en garantissant l’interopérabilité entre ces applications [Erl, 2004], [Krafzig et al., 2005]. Ceci a encouragé les entreprises à baser leur système d’information sur cette nouvelle philosophie. Bieberstein définit l’architecture SOA comme suit

La SOA représente une nouvelle forme architecturale pour les systèmes d’information. Elle fournit une vision où les applications (internes et externes) sont exposées sous forme de services et peuvent communiquer entre elles d’une manière simple [Raymond, 2007]. Dans cette vision, chaque application fournit une partie (ou l’ensemble) de ses fonctionnalités sous forme de services invocables par d’autres applications. Ce concept d’architecture utilise donc les services comme des composants principaux pour la construction des applications distribuées d’une manière facile et peu coûteuse. Ceci Un service est composé de trois parties principales, tel que illustré dans la Figure 8 : (i) l’interface qui constitue la partie « publique » et contient entre autres la liste des opérations, les entrées et les sorties, (ii) l’implémentation qui constitue la partie « privée » et correspond au développement des fonctionnalités du service. Même si l’implémentation dépend de la plateforme utilisée, l’approche SOA permet d’abstraire l’hétérogénéité technique grâce à la publication d’une interface commune appelable. Enfin (iii) le point de déploiement (end-point) qui représente le point par lequel le service peut être invoqué, généralement il correspond à une adresse URL (Uniform Resource Locator).

Ce qui distingue l’architecture SOA des autres architectures, c’est le couplage lâche et la granularité des services. Ces propriétés permettent de faciliter la reconfiguration des processus quand les fonctions métier évoluent ou changent. Le concept de service, qui est véhiculé par le modèle de l’architecture orientée services, se veut indépendant de la mise en œuvre des applications constituantes. D’autre part, la granularité des services rend possible et plus flexible l’adaptation, l’évolution des applications et leurs collaborations avec d’autres. Le fournisseur du service et les utilisateurs (appelés aussi consommateurs) interagissent entre eux sans qu’ils n’aient à faire de concession sur la structure propre, le comportement interne et l’implantation des services. Concrètement, cela se déroule en quatre phases réunificatrices comme l’illustre la Figure 9 ci-après. Les services Web sont des services qui peuvent être publiés, découverts et invoqués par le biais de l’internet. Cette technologie de services constitue une solution pour implémenter une architecture SOA [Newcomer et al., 2004]. Cependant, un service Web peut être considéré comme étant une application autonome, mise à disposition d’autres applications et qui peut être publiée, découverte et invoquée via une infrastructure du Web [Tidwell, 2000] et [Alonso et al., 2004]. Le consortium UDDI (Universal Description, Discovery and Integration) fournit une définition plus spécifique d’un service Web et le caractérise comme suit :