Tâche: Documenter des décisions de réalisation de services
Cette tâche met l'accent sur la réalisation d'un modèle de services en termes de composants de logiciel devant être exécutés dans des environnements de logiciels intermédiaires existants.
Disciplines: Implémentation
Objet

L'objectif de cette tâche est de fournir un modèle conceptuel d'implémentation qui puisse être utilisé par les développeurs pour implémenter les composants de service susceptibles de fournir les services requis.

Relations
Description principale

Le modèle de service a essentiellement pour but d'identifier les services, leur organisation, leur collaboration et leur spécification complète et détaillée. La responsabilité de l'implémentation est déléguée au modèle de conception Rational Unified Process (RUP) existant, et plus particulièrement à l'élément de modèle Composant de service. En général, le modèle de services est réalisé par un modèle de conception. Cependant, il est possible de générer des artefacts directement depuis le modèle de services si les spécifications requises sont simples. Il peut être également utile de créer un modèle de cas d'utilisation à partir du modèle de services , afin de permettre une description plus approfondie des services avant leur construction.

Etapes
Déterminer l'approche du sourçage

Un certain nombre d'alternatives peuvent être prises en compte concernant la décision de la réalisation des services (voir la figure ci-dessous). Il n'existe pas de décision évidente opposant le développement à l'achat d'une solution ; d'autres options intéressantes peuvent également être prises en compte. La "transformation" utilise une combinaison de techniques comprenant l'extraction de règles métier afin d'obtenir un segment de fonctionnalité à utiliser indépendamment pour la réalisation du service du composant. L'"intégration" est l'"emballage" des fonctionnalités existantes permettant d'obtenir de nouvelles fonctionnalités ; l'intégration est basée sur les appels. L'abonnement est basé sur la disponibilité d'un modèle de publication/abonnement (dans un contexte de logiciel intermédiaires orienté messages) dans lequel un consommateur s'abonne aux services proposés par le fournisseur. L'une des options consiste à externaliser la fonctionnalité (par exemple, la paie) à une autre entreprise. Avec la prépondérance croissante des services Web et de l'intégration business-to-business , cette option sera également prise en compte pour une utilisation sur une base plus large.

  • Construire : pour différentes raisons, la décision est de développer le service en interne.
  • Acheter : acheter un service qui peut être déployé et hébergé en interne.
  • Transformer : utiliser une combinaison de techniques comprenant l'extraction de règles métier afin d'obtenir un segment de fonctionnalité à utiliser indépendamment pour la réalisation du service du composant.
  • S'abonner - basé sur la disponibilité d'un modèle de publication/abonnement (dans un contexte de logiciel intermédiaires orienté messages) dans lequel un consommateur s'abonne aux services proposés par le fournisseur.
  • Intégrer - emballage des fonctionnalités existantes permettant d'obtenir de nouvelles fonctionnalités ; l'intégration est basée sur les appels.
  • Externaliser : avec la prépondérance croissante des services Web et de l'intégration business-to-business, cette option sera également prise en compte pour une utilisation sur une base plus large.

Les décisions de réalisation de services sont associées aux composants de service. Chaque composant de service peut être considéré comme un conteneur de fonctionnalités nécessaire à la réalisation d'un service. Il est constitué de composants fonctionnels et techniques ou les utilise seulement. Il est important de décider comment ces composants de service vont être réalisés. Il ne s'agit pas d'une simple décision entre "acheter ou développer". D'autres considérations doivent être prises en compte, telles que :

  • La transformation qui peut impliquer l'extraction de règles ou le clonage du code existant et sa réécriture afin de l'utiliser comme un composant avec une interface définie.
  • L'intégration avec la messagerie ou des encapsuleurs.

Exemple

Nous souhaitons capturer les décisions de réalisation pour l'exemple d'agence de location de véhicules, or cela est difficile dans le modèle UML que nous avons utilisé dans plusieurs exemples. Pour nous aider dans ce processus, nous pouvons utiliser le canevas de matrice de réalisation afin de documenter le résultat de ces décisions, comme illustré dans la figure ci-dessous.

Déterminer l'approche du développement

Les avantages des options décrites sont que quelle que soit la solution choisie, du modèle de cas d'utilisation au modèle de conception, puis à l'implémentation, il existe toujours un lien de traçabilité entre chacun de ces artefacts.

Diagramme décrit dans le contenu textuel.

Nous recommandons de réaliser le modèle de services à l'aide d'un modèle de conception. Ainsi, le concepteur et l'implémenteur pourront appliquer des patterns au modèle de conception et modéliser des capacités et structures supplémentaires avant de générer des artefacts d'implémentation.

Mappage à granularité fine des actifs existants

Il ne faut pas oublier que très peu de solutions sont construites sans prendre en compte les applications existantes qui fourniront des fonctionnalités de prise en charge de la solution ou avec lesquelles la solution doit interagir. De ce fait, il est donc essentiel que les applications existantes qui seront réutilisées dans une solution soient cataloguées et que leurs fonctionnalités soient identifiées. Dans le cas d'une solution orientée services, il existe plusieurs méthodes d'intégration de nouveaux services à la fonctionnalité existante. Elles sont illustrées dans la figure ci-dessous :

  • Encapsuler une fonction existante comme un service. Dans ce cas, le but est de conserver la fonction en l'état tout en utilisant des outils ou des logiciels intermédiaires (middleware) pour l'exposer comme un service. Par exemple, IBM permet d'exposer des transactions CICS existantes comme des service Web SOAP.
  • Encapsuler une fonction existante et la remplacer par un service. Dans ce cas, la fonction est encapsulée comme indiqué ci-dessus, mais on utilise la spécification de service qui en résulte pour redévelopper le service à une date ultérieure, en remplaçant le service d'origine et en redirigeant les clients vers la nouvelle implémentation.
  • Utiliser un adaptateur plus flexible pour l'appel de service. Il n'est parfois pas possible d'encapsuler une fonction et de l'exposer comme un service, mais il est possible de l'encapsuler dans un élément mieux adapté à l'intégration, par exemple une interface MQI ou l'architecture J2EE Connector. Cela permet à de nouveaux services d'accéder à la fonction en place.
  • Intégrer la fonction dans le service. Dans certains cas, il est évidemment possible pour le nouveau service d'accéder à la fonction existante, en utilisant simplement cette fonction comme un composant logique de l'implémentation du service.

Diagramme décrit dans le contenu textuel.

Prenez en compte le fait que les troisième et quatrième options offrent les meilleures performances en termes de flexibilité car elles utilisent la fonction existante, mais cessent d'exposer la fonction en l'état aux clients. Parallèlement, les première et deuxième options peuvent faire apparaître des problèmes d'encapsulage des fonctions en tant que services, car les performances des protocoles de service Web et les disparités entre les formats de données natifs et le langage XML peuvent faire naître des préoccupations en termes de performances.

Les ressources logicielles existantes et leurs dépendances ainsi que les interfaces devront être analysées pour déterminer si des modifications sont requises pour prendre en charge la fonctionnalité métier. Par exemple, pour créer une interface de services Web pour l'implémentation existante d'une fonction métier, l'analyse peut impliquer l'examen de la composition et du flux des transactions en ligne ou des travaux par lots ou encore des magasin de données persistants qui aident à exécuter cette fonction. La conception actuelle de ces applications existantes devra peut-être être modifiée pour prendre en charge la fonctionnalité. Il faut également identifier tout obstacle potentiel à la création d'une interface de services Web avec la qualité de service souhaitée.  Par exemple, l'implémentation par lots monolithique d'une fonction métier peut nécessiter un temps de réponse inférieur à la seconde lorsqu'elle est appelée en tant que service.  

Encapsulage de ressources existantes en tant que pattern de services

Dans certains cas, cependant, il est utile de développer une partition de service existant lorsque des fonctions existantes de niveau inférieur formant un ensemble sont exposées chacune comme un service. Cette partition n'est accessible qu'à des services de niveau supérieur qui l'utilisent pour présenter aux clients une spécification alignée métier plus granulaire. Cette encapsulation des fonctions existantes doit être considérée comme une solution temporaire et ne doit être entreprise que si les caractéristiques de performance de la technologie d'encapsulage sont suffisamment maîtrisées. Pour plus d'informations, voir le concept Partitionnement de la solution.

Une façon d'envisager l'encapsulage d'une fonction existante est de penser à la forme très simplifiée de l'élément de modèle Fournisseur de services, dans lequel un service spécifique réalise une spécification donnée avec une opération unique. Le diagramme ci-dessous illustre ce pattern pour la fonction existante "UpdateCustomerAddress" (mise à jour de l'adresse d'un client).

 Diagramme décrit dans le contenu textuel.

Pour personnaliser ce pattern, vous pouvez effectuer les actions suivantes :

  • Il est probable qu'un ensemble de fonctions existantes sera fourni par un même composant ; il convient donc d'utiliser un seul et même fournisseur de services.
  • Le pattern présenté ci-dessus a été généré automatiquement ; il peut être préférable de renommer l'opération par défaut appelée "exec${service}".
  • De même, il serait utile de renommer les messages générés par défaut ; à ce stade, les structures de message doivent également être modélisées.
  • Le pattern par défaut suppose que l'opération reçoit un message et en renvoie un ; il est possible que la fonction existante ne renvoie aucun message ou qu'elle ne soit qu'une notification, la signature de l'opération générée doit être modifiée.
  • L'architecte/le concepteur doit s'assurer que des valeurs correctes sont définies pour la propriété "allowedBindings" (liaisons autorisées) du fournisseur de services.
Plus d'informations