Concept: Architecture orientée services
Dans ce concept, l'architecture orientée services (SOA) se caractérise de plusieurs façons : en tant qu'infrastructure technologique, infrastructure préfabriquée conceptuelle pour la conception, pont entre le métier et l'informatique et en tant qu'évolution des techniques à base de composants et des techniques orientées objet (OO).
Relations
Eléments connexes
Description principale

Introduction

Les difficultés rencontrées dans la construction de solutions logicielles à l'échelle d'une entreprise proviennent d'au moins quatre sources principales :

  1. la compréhension de domaines métier très complexes,
  2. l'estimation de l'utilisation la plus efficace des ressources informatiques pour répondre aux besoins du métier,
  3. la gestion d'un travail de développement impliquant de grandes équipes d'ingénieurs dans les phases multiples d'un projet s'étalant sur plusieurs mois,
  4. le déploiement de solutions pour un ensemble complexe de technologies de l'infrastructure ayant évolué au fil des ans implique divers logiciels middleware acquis par différents fournisseurs et regroupés au travers de travaux d'intégration mal documentés et de qualité variable.

Développer des solutions dans un tel contexte nécessite l'adoption d'une approche, en terme d'architecture logicielle, qui puisse aider les architectes à faire évoluer leurs solutions de manière flexible et à réutiliser les travaux existants dans le contexte de fonctions nouvelles qui implémentent rapidement la fonctionnalité métier, même lorsque l'infrastructure cible évolue. Pour pouvoir traiter ces besoins, de nombreuses organisations cherchent à réorganiser les ressources d'informations en fonctions indépendantes, réutilisables et fonctionnelles qui créent un environnement adaptable. En décrivant ces fonctions réutilisables à l'aide de protocoles ouverts et standard, une organisation peut créer des services autodescriptifs dont on peut se servir indépendamment de la technologie sous-jacente. Une telle utilisation indépendamment de la technologie permet d'utiliser les services dans des contextes différents pour obtenir des processus métier et des règles standards. Cette approche pour les systèmes informatiques, appelée architecture orientée services (SOA), est largement reconnue comme ayant le potentiel d'améliorer radicalement la réactivité des organisations métier et des organisations informatiques.

Le passage à une architecture SOA est synonyme de défis pour une organisation. Les concepts orientés services par exemple, introduisent de nouveaux termes et modèles et améliorent l'interopérabilité et l'intégration des processus. De plus, l'intégration des nombreuses couches de la technologie sous-jacente représentant une architecture SOA peut s'avérer très complexe. Les organisations IT disent souvent avoir besoin de changements d'approche, de mises à niveau de leur ensemble de compétences, de nouvelles fonctions dans leurs environnements de développement et de changements de processus de conception de solutions. En résumé, le concept de l'architecture SOA est un phénomène récent et ses caractéristiques sont en constante évolution. Néanmoins, on sait clairement à plusieurs niveaux ce qu'est une architecture SOA et on connaît son rôle dans le traitement des questions clés en terme de construction de solutions logicielles pour une entreprise.

Architecture SOA en tant qu'infrastructure technologique

Les systèmes se composent de regroupements de services appelant des opérations via leurs interfaces de services. De nombreuses organisations expriment leurs solutions en terme de services et d'interconnexions de ces services. L'adaptation d'une architecture SOA a pour objectif final d'atteindre une certaine flexibilité métier et informatique. Un certain nombre de technologies importantes ont été définies pour prendre en charge l'approche d'une architecture SOA, notamment lorsque les services sont distribués entre plusieurs machines et connectés à Internet ou à un Intranet. Ces approches des services Web s'appuient sur des protocoles de communication entre services tels que les protocoles SOAP, permettent d'enregistrer les interfaces de services Web (exprimées dans le langage WSDL - Web Services Definition Language) dans des répertoires publiques et de les chercher dans les référentiels UDDI (Universal Description, Discovery and Integration) et partagent les informations dans des documents définis en langage XML et décrits en schémas standards. De plus, des standards sont développés pour traiter de questions supplémentaires en terme de règle, sécurité, fiabilité, découverte, etc. Cette famille de standards est connue sous le nom de "famille WS-*".

Mais une architecture SOA n'est pas plus un simple ensemble de standards et de description de services que l'orientation objet un simple ensemble de hiérarchies de classes. En effet, il est possible de créer une architecture SOA qui n'utilise pas la technologie des services Web, tout comme il est possible d'utiliser la technologie des services Web d'une manière qui ne soit pas considérée comme orientée services. Il y a encore beaucoup de recherches à faire pour comprendre pourquoi un point de vue orienté services ajoute de la valeur au métier et comment les solutions orientées services sont conçues, implémentées, déployées et gérées. [De plus, une architecture SOA n'équivaut pas à des services Web.]

Architecture SOA en tant qu'infrastructure préfabriquée conceptuelle pour la conception

Créer des solutions pour une architecture SOA signifie repenser les types de systèmes qui sont construits aujourd'hui, reconsidérer les compétences utilisées dans les organisations et redéfinir la collaboration entre les membres des équipes. Plus important encore, adopter un développement de solutions orientées services exige de revoir largement l'impact d'une telle orientation sur la conception de solutions, de revoir les conséquences d'un assemblage de ces solutions à partir de plusieurs services et de revoir comment les solutions orientées services déployées sont gérées et comment elles évoluent.

Un changement clé fait son apparition dans l'utilisation de cette méthode : l'emploi du terme "application", tel que nous le connaissons, devient ici problématique. Jusqu'à présent, l'application était le centre de tous les projets. Ici, c'est le portefeuille de services dont dépend un métier qui devient central. A cet égard, passer des projets orientés application aux projets orientés services revient à passer de la conception d'un ensemble de composants intégré verticalement représentant une application à la conception d'un ensemble de services horizontal. Le terme application représente dorénavant la description de fines couches de logique métier spécifique proche des services d'interaction de l'utilisateur qui chorégraphient l'ensemble des services métier et des services d'infrastructure représentant l'ensemble de la valeur.

Gartner désigne ce contexte plus large d'orientation services sous le terme de développement d'applications orienté services (Service-Oriented Development of Applications - SODA). D'après Gartner, les cinq principes clés de SODA sont la composition, la gestion de processus adaptative, l'interopérabilité et l'intégration basées sur les services, la reconnaissance et la description, la maintenance d'application rapide. Du point de vue d'un fournisseur d'outils, ces principes sont liés à la prise en charge de la technologie offerte dans trois domaines :

Cycle de vie d'une architecture SOA. La "reconnaissance et description" et la "maintenance d'application rapide" désignent le cycle de vie des services, ainsi que leur identification, leur application, leur évolution et leur maintenance. Les fournisseurs d'outils offrent de plus en plus de moyens de stocker, classer, rechercher et extraire des services. La prise en charge de l'évolution de services continue en est un aspect critique, menant à de nombreuses versions de services.

Plateforme et modèle de programmation d'une architecture SOA. L'intégration et l'interopérabilité basées sur les services désignent la méthode utilisée pour connecter, déployer et gérer les services au sein d'une plateforme d'exécution spécifique. Les principaux fournisseurs de plateformes prennent directement en charge les fonctions orientées services en tant qu'exécutions de middleware et font évoluer leurs modèles de programmation d'exécution de concepts de service apparents en éléments de première classe. Il est alors possible de concevoir, d'implémenter et de gérer des solutions à partir d'une seule perspective basée sur les services.

Pratiques et outils SOA. La composition et la gestion adaptative de processus désignent la méthode utilisée pour créer et assembler des services dans le contexte de la résolution de besoins métier changeants. Les fournisseurs d'outils prennent en charge l'exploitation d'applications existantes afin d'identifier des services potentiels, d'encapsuler les fonctionnalités existantes pour les rendre accessibles en tant que services, de créer de nouveaux services et de connecter les services en connectant le comportement exposé à travers leurs interfaces. Pour ce faire, il est essentiel de disposer de conseils clairs et des meilleures pratiques pour élaborer l'architecture de solutions orientées services de manière renouvelable et prévisible.

Ces trois domaines sont essentiels au développement des solutions orientées services. Ils doivent tous être traités pour répondre aux besoins d'une entreprise en matière d'efficacité de création de solutions flexibles correspondant mieux aux objectifs métier.

Architecture SOA en tant qu'approche globale des solutions reliant métier et informatique

L'une des premières choses à faire pour développer des solutions à l'échelle d'une entreprise est de connecter les exigences spécifiques à un domaine exprimées par les analystes métier aux solutions spécifiques à une technologie conçues par l'organisation IT. Cependant, il n'est pas conseillé de connecter ces deux mondes distincts. Les deux communautés exigent des compétences très différentes, utilisent des concepts de modélisation et des notations (s'il en existe) différents et comprennent rarement le mappage entre les deux concepts. Une approche orientée services a pour objectif de combler ce fossé entre les analystes métier et les spécialistes du secteur et les spécialistes IT tels que les architectes, les analystes système, les intégrateurs, les concepteurs et les développeurs. En particulier, l'intégration des processus, des actifs et des livrables autour d'un ensemble de services central a pour objectif de connecter ces deux aspects différents du système de manière claire et précise.

L'architecture SOA offre une vue axée sur les services permettant de relever les défis suivants :

Relier le métier aux sciences de l'information. Il est important d'aligner la vue métier des activités et processus sur la technologie utilisée pour réaliser certaines parties de ces activités. Cela inclut la capacité des modèles métier à conduire le développement en aval et à évoluer en association avec les solutions IT. Le concept de services est critique pour une telle action. Les services et le mode de pensée orienté services sont le point d'encrage des analystes système, des architectes IT, des intégrateurs et des développeurs. La nature même de ces services, c'est-à-dire leur degré de granularité et leur niveau d'encapsulation, leur permet d'être davantage alignés sur les modèles de processus métier guidant le métier. Il est essentiel de disposer de pratiques de conception communes pour garantir que les concepts, les produits et les tâches sont synchrones dans les différentes perspectives. Il est donc très important de disposer d'outils pouvant transformer efficacement les modèles représentant l'objectif métier en implémentations efficaces pour relier le métier aux technologies de l'information.

Prendre en charge les rôles changeants dans l'organisation organisation IT. Lors du passage à l'orientation services, les compétences et la composition des équipes d'une organisation changent. Le développement est axé sur la recherche, la définition, la gestion et l'assemblage de services avec des descriptions architecturales mettant en évidence les contrats de service (SLA) et les protocoles interservices. La décomposition habituelle des fonctions de l'outil en fonction de la répartition actuelle des produits ne convient pas à cette approche. La combinaison des fonctions requises par les différents membres dans les organisations IT sera différente. Par exemple, les compétences requises par les rôles existants, comme l'architecte logiciel, changent et l'accent est davantage mis sur l'assemblage et la gestion des services dans un ensemble divers de fournisseurs de services. De même, de nouveaux rôles apparaissent, tels que les spécialistes de l'intégration. L'accent est mis sur l'assemblage d'une chaîne de valeur basée sur les services pour prendre en charge les objectifs métier clés d'une entreprise.

Se concentrer sur les actifs et la réutilisation. Se concentrer sur les actifs clé lors de la conception des systèmes modifie la perception de la valeur de réutilisation de ces services par l'entreprise. Nous avons mentionné plus haut le passage du développement vertical d'un ensemble de composants d'application à l'intégration horizontale de composants. L'un des aspects positifs de ce passage est que les services sont davantage disponibles pour réutilisation. Leur combinaison avec de nouvelles fonctions et leur composition dans de nouveaux services sont en fait un moteur fondamental de changement. Pour de nombreux métiers, cette promesse d'une plus grande possibilité de réutilisation à partir de l'architecture SOA justifie le coût associé à la conception et au développement d'un portefeuille de services. En conséquence, les technologies et techniques de gestion des actifs et les méthodes réitérables d'enregistrement des patterns pour associer des actifs deviennent beaucoup plus importantes. Dans une approche de développement basé sur les actifs, ces actifs ont une valeur critique pour l'organisation et doivent donc être gérés avec précaution. L'infrastructure de l'équipe de gestion des actifs joue un rôle clé dans cette approche.

Augmenter les niveaux de collaboration dans et entre les rôles des techniciens. Le développement d'application d'entreprise a toujours reconnu que le développement logiciel exige un travail d'équipe et une attention particulière accordée dans le cycle de vie à la gestion des actifs, processus et pratiques partagés et de la traçabilité des produits. Le travail de collaboration pour le développement logiciel augmente avec une distribution géographique plus grande des organisations, une communication en temps réel plus importante entre les membres des équipes et un logiciel qui est imbriqué en tant que partie des initiatives de développement de systèmes de plus grande envergure. Le rôle des infrastructures de développement logiciel sera de plus en plus perçu comme un environnement de développement collaboratif pour les techniciens logiciels, qui encourage le partage et la réutilisation de services entre équipes.

Architecture SOA en tant qu'évolution des techniques à base de composants et des techniques orientées objet

Dans tout nouveau développement dans le domaine du génie logiciel, il est très facile de supposer que l'on peut appliquer les mêmes techniques et utiliser les mêmes outils que ceux qui ont donné de bons résultats pour les projets précédents. Cette tendance à résoudre des problèmes inédits avec des solutions dépassées n'est pas nouvelle. Lorsque les développeurs ont commencé à créer des applications à base de composants, ils ont essayé d'utiliser leur expérience en matière de développement orienté objet pour résoudre les problèmes rencontrés. Avec le temps, on a compris que la technologie et les langages orientés objet pouvaient être très efficaces pour implémenter des composants, même s'il faut comprendre les compromis que cela représente en terme de décisions et d'implémentation - par exemple les compromis entre héritage et agrégation pour mettre en oeuvre un comportement polymorphe ou la refonte des bibliothèques de classes pour pouvoir utiliser des ensembles de composants plutôt que la base de l'application C++ monolithe.

Il en est de même pour les composants que nous voyons comme le meilleur moyen d'implémenter des services, même s'il faut comprendre qu'une application à base de composants exemplaire ne fait pas forcément une application orientée services exemplaire. Une fois le rôle joué par les services dans l'architecture de l'application compris, il peut être très bénéfique d'optimiser le développement des composants et les composants existant de l'entreprise. La clé pour faire la transition est de réaliser qu'une approche orientée services implique une couche supplémentaire d'architecture applicative. La figure ci-dessous montre comment on peut appliquer des couches technologiques à une architecture applicative pour offrir des implémentations à granulation plus grossière au fur et à mesure que l'on se rapproche des utilisateurs de l'application. Le terme inventé pour cette partie du système est "application edge" ("périphérie applicative"), qui reflète le fait qu'un service est une manière efficace d'exposer une vue externe d'un système, avec réutilisation et composition internes à l'aide de la conception classique de composants. Observer la manière dont les objets, les composants et les services sont associés à leur implémentation permet de voir leurs différences : les objets sont étroitement associés à leur langage de programmation, les composants sont associés à une exécution ou une plateforme (COM, CORBA, J2EE etc.), tandis que les services sont uniquement associés à l'ensemble des standards utilisés pour décrire leur spécification.

Diagramme décrit dans le contenu textuel.

Le passage du modèle orienté objet au modèle à base de composants prenait en général entre 6 et 18 mois, les développeurs se formant à cette nouvelle technologie et à ses nouveaux critères au fur et à mesure. On peut espérer que le passage aux systèmes orientés services prendra moins de temps. Pour cela, les développeurs devront comprendre les défis, les compromis et les décisions de conception qui permettent de développer et de réutiliser des composants pour des solutions orientées services.