Concept: Portefeuille de services
Ce concept décrit les avantages représentés par les services qui permettent aux organisations de promouvoir la réutilisation en composant des applications à l'aide d'un portefeuille de services. Ce document porte aussi sur le stockage effectif et sur la découverte et la suppression de services se trouvant dans des référentiels.
Relations
Description principale

Introduction

L'un des avantages de l'architecture SOA est qu'elle permet de s'éloigner du mode de penser "silo" en informatique, le développement d'applications s'effectuant comme celui d'îles de fonctionnalités. Les applications sont souvent considérées comme une intégration verticale de composants construits pour ce seul objectif. Il arrive souvent que des projets de développement soient établis autour du développement ou de la maintenance d'une application et même parfois que des équipes de développement ne soient responsables que d'une seule application. L'image suivante représente la structure d'une application classique, indiquant que bien souvent la seule réutilisation entre des applications est le partage d'une base de données commune.

Diagramme décrit dans le contenu textuel.

L'approche orientée services donne une vue plus horizontale des applications comme étant l'intégration des services. En réalité, tous les services d'un portefeuille de fonctions sont des pairs à partir desquels les applications, qui peuvent à présent être envisagées comme des parties de solutions IT interagissant avec des utilisateurs, peuvent être développées. Le diagramme suivant indique la façon dont l'application de passation de la commande peut être développée comme un ensemble de portlets conçus pour les utilisateurs et devant être intégré dans un serveur de portail. Il montre aussi que la logique métier est fournie par un ensemble de services utilisant à leur tour un ensemble de services d'infrastructures.

Diagramme décrit dans le contenu textuel.

Les services fournissent des composants déployés de manière indépendante, dont la granularité leur permet d'être "auto-contenus". On obtient ainsi des services gérant et protégeant leurs propres magasins de données au lieu de partager des mémoires de bases de données. Cela semble être en opposition avec la tendance observée dans certaines entreprises qui, au fil des années, introduisent des systèmes de stockage des données communs ou du moins des modèles de données communs que toutes les applications partagent. Une architecture SOA amène généralement les concepteurs à ne pas développer des modèles de stockage des données communs, mais plutôt des modèles de messages communs facilitant l'intégration des services grâce aux technologies middleware.

Vue de l'entreprise 

Comme nous l'avons déjà dit, les projets et les équipes de développement ont une portée et une visibilité limitées concernant les fonctions, les exigences et les objectifs au sens plus large des services informatiques, ainsi qu'au niveau des services pris en charge par l'entreprise. Dans l'optique de l'adoption de solutions orientées services et d'une vue horizontale des solutions intégrées, il est donc essentiel que les architectes IT soient capables de visualiser l'ensemble des services prenant en charge les solutions métier nécessaires au fonctionnement de l'entreprise. L'un des avantages de la modélisation de services est qu'un modèle abstrait est capable de supprimer certains détails et donc de présenter une vue plus générale de l'ensemble des services de façon évolutive, c'est-à-dire qu'en présence de nombreux services, le modèle est capable de présenter des vues du portefeuille indiquant la prise de décision de l'architecte logiciel et du concepteur.

Le fait que les organisations optent pour des architectures SOA entraînera évidemment une augmentation des services (le portefeuille sera donc de taille réduite au départ), mais il est possible d'enregistrer l'état de la transition en terme de services disponibles et planifiés. Le partitionnement des services est très important pour l'organisation du modèle et la catégorisation des services à mesure que le portefeuille est développé.

Catégorisation des services 

Pendant les premières étapes de l'identification des services (voir Activité : Analyse des actifs existants), il est courant que les services candidats soient capturés en tant que simple liste de noms, éventuellement structurée sous forme de liste hiérarchique ou sauvegardée dans un tableur. Une liste de ce type est utile lorsque vous travaillez dans un environnement d'atelier et que vous extrayez les services candidats de matériaux source. Avec l'augmentation du nombre de services candidats, une liste non structurée peut rapidement devenir ingérable. Par conséquent, une structure hiérarchique de services doit être identifiée dès que possible afin que les services candidats puissent être organisés en groupes au sein de la hiérarchie de catégories.

Même si une simple liste de noms de service peut être un point de départ rapide, il reste important d'extraire des informations supplémentaires sur chaque service. Ces informations peuvent être fractionnées en deux types : les informations prenant en charge l'identification des services et les informations prenant en charge la spécification de service. L'identification des services met l'accent sur la construction d'un portefeuille de services pouvant être associés à des fonctions métier, des objectifs métier et des actifs tels que des systèmes existants et indique si le service est considéré comme un candidat ou a été choisi pour être exposé. Le canevas de portefeuille de services peut être utilisé pour documenter les services au niveau de détail nécessaire dans le portefeuille de services.

Il faut être capable de catégoriser les services dans un portefeuille de plusieurs manières, mais la plupart du temps on emploie une terminologie qui décrit l'objectif, le propriétaire et l'organisation du service. Afin de prendre en charge cette catégorisation ou cette classification, chaque partition de service a une propriété de classification pouvant être utilisée pour spécifier le type de classification. Dans ce schéma de classification, le nom de la partition devient une valeur.

Par exemple, le diagramme suivant (ou des modèles qui lui sont proches) a été développé par certaines entreprises pour mieux visualiser les types de services contenus dans un portefeuille. Remarquez que cette catégorisation, bien que commune, ne constitue qu'un exemple de segmentation du portefeuille de services. Dans cet exemple, chaque partition porte le nom de sa "zone" de propriété de classification.

Diagramme décrit dans le contenu textuel.

  • Les services des interactions utilisateur sont utilisés pour décrire la façon dont l'utilisateur interagit avec l'application. Un service peut, par exemple,avoir besoin d'attribuer une tâche à un utilisateur humain ; il faut donc qu'un service soit capable de prévenir l'utilisateur de cette tâche, puis d'avertir le service une fois que la tâche a été accomplie.
  • Les services spécifiques aux applications, développés au sein d'une activité de développement jugée impropre à la réutilisation, ne sont donc pas considérés comme faisant partie du portefeuille. Les services étant des entités composables, il est également possible qu'un service fasse partie d'un portefeuille et que les services imbriqués qu'il utilise ne soient pas publiés.
  • Les services d'intégration de processus, généralement fournis par un middleware à vocation commerciale, fournissent la chorégraphie des services de façon à ce que les processus puissent avoir lieu dans le middleware et utilisent les services dans le portefeuille pour implémenter un processus.
  • Les services d'intégration des services sont des services middleware à vocation commerciale qui fournissent des services pour la formats des données et du contenu des messages entre les services ; par exemple, le message d'un client peut être généré par le service constitué d'une agrégation de données provenant d'autres services du portefeuille.
  • Les services métier sont des services propres à l'entreprise, développés pour elle et permettant une prise en charge directe des applications développées pour prendre en charge le métier. On peut citer, par exemple, la gestion client, les stocks, les ressources humaines, etc.
  • Les services d'infrastructure fournissent des fonctions IT requises par les services métier, mais aussi par les services d'intégration. Des exemples de services d'infrastructure sont la messagerie, le répertoire, l'authentification, l'accès existant, etc.

Pour obtenir plus d'exemples de types de classifications, voir le concept Partitionnement de services.

Référentiels de services 

Pour la conception et l'implémentation, les concepteurs et les développeurs doivent donc avoir accès à un modèle de l'ensemble des services, mais aussi à la spécification détaillée des services. Il est aussi possible que plusieurs services implémentent la même spécification et un registre permettant la génération de requêtes ayant la forme "tous les services implémentant la spécification de la commande" permet aux développeurs de composer des solutions à partir des services existants et aux développeurs de l'intégration d'identifier les services à utiliser pour satisfaire les exigences métier ou techniques.

Les référentiels des services peuvent également utiliser la valeur de classification introduite par la partition de service pour compléter les valeurs comme des métadonnées décrivant les services contenus par le référentiel.

Par exemple, une solution peut demander un service d'expédition, le registre identifiant alors trois services s'occupant de l'expédition ; deux de ces services garantissent la sécurisation des messages échangés, mais un seul passe par Java Message Service (JMS), tandis que l'autre fournit SOAP avec HTTP. Les exigences métier spécifient seulement que les informations client doivent rester confidentielles et donc que l'échange de message doit être sécurisé. Les standards IT conseillant de ne pas utiliser JMS pour un service à distance, le choix est donc plus limité.

Différentes implémentations techniques disponibles pour les registres de services :

  • UDDI : registre standard des services Web. Il fut très largement adopté et devait prendre en charge le développement et l'intégration des requêtes temporelles. Toutefois, le niveau de personnalisation nécessaire pour garder une trace de toutes les données associées à une spécification de service a certainement contribué à soulever des questions sur le fait qu'UDDI est capable ou non de prendre en charge le portefeuille de services d'une entreprise dont traite ce document.
  • Référentiel RAS : la spécification RAS devait prendre en charge la description personnalisable des métadonnées d'éléments réutilisables et elle a en effet un profil de métadonnées pour les services Web. Si l'objectif de la spécification RAS n'était pas de fournir un portefeuille de services, il serait cependant possible de le faire pour les métadonnées temporelles de développement, bien que ce ne soit pas forcément conseillé pour l'intégration de requêtes temporelles.
  • Personnalisation : de nombreuses organisations, devant cette multiplicité de solutions, ont décidé d'implémenter des référentiels de services personnalisés, gérant un ensemble de métadonnées ou de documents de conception pour les services au moment de la conception et en association avec les artefacts de services Web au moment de l'implémentation. Dans la plupart des cas, un référentiel UDDI distinct est ensuite utilisé pour déployer des services de production pour les requêtes temporelles d'intégration.