Les difficultés rencontrées dans la construction de solutions logicielles à l'échelle d'une entreprise proviennent d'au
moins quatre sources principales :
-
la compréhension de domaines métier très complexes,
-
l'estimation de l'utilisation la plus efficace des ressources informatiques pour répondre aux besoins du métier,
-
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,
-
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.
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.]
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.
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.
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.
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.
|