Tâche: Appliquer les tests Litmus de services
Cette tâche décrit les exigences permettant de qualifier les services candidats afin d'assurer que les services développés ultérieurement répondent réellement aux besoins de l'entreprise.
Disciplines: Analyse et conception
Relations
Description principale

Une fois que les services candidats ont été sélectionnés et documentés dans le portefeuille de services (catégorisé), il s'agit de déterminer quels candidats doivent être exposés en tant que services. Bien qu'en théorie tout service candidat peut être exposé via l'exportation de son interface en tant que description de service, tous les services candidats ne doivent pas être exposés. D'un point de vue économique et pratique (les exigences non fonctionnelles peuvent être compromises), cela peut ne pas être réalisable. Notamment, la décision naïve d'exposer "toutes les méthodes de toutes les classes" crée un nombre écrasant et souvent ingérable de services, entraînant l'apparition du "Syndrome de prolifération des services". Cela crée des problèmes très importants de performances et de gestion des services, sans mentionner le fait que le capital intellectuel de l'entreprise peut être gâché. En outre, il faut se souvenir qu'il existe un coût associé à chaque service que nous choisissons d'exposer : le financement, la gouvernance et l'infrastructure sous-jacente (sécurité, performances et gestion) du service et des composants qui vont les implémenter doivent être pris en compte.

Par conséquent, certains critères sont nécessaires pour déterminer s'il faut exposer un service et, principalement, s'il faut financer la création du composant de service qui fournira la fonctionnalité du service ainsi que la maintenance, la surveillance, la sécurité, les performances et d'autres contrats de service du service. 

Tests Litmus de services

Les expériences de projet indiquent un ensemble de critères sous la forme de Tests Litmus de services qui peuvent et doivent être utilisés pour filtrer les collections de services candidats. Cette métaphore est utilisée pour décrire un ensemble de tests qui, lorsqu'ils sont appliqués, vont déterminer si un service donné peut être exposé à l'aide d'une description de service. Ces tests sont utilisés ensemble et aident à répondre à des questions telles que : dans la liste de services candidats, lesquels doivent être exposés ? Puis, lesquels doivent être financés ? Lesquels ont une valeur métier ?

D'un côté, chaque cas d'utilisation métier peut être considéré comme un service candidat. D'un autre côté, seuls quelques services sont sélectionnés pour être exposés. L'application du test Litmus de services génère généralement une réponse intermédiaire : un ensemble de services gérable que l'entreprise souhaite exposer et qui peut ultérieurement être utilisé dans des compositions.

Les services candidats qui réussissent tous les tests Litmus de services doivent alors être exposés en tant que services dans l'architecture SOA. Certains services candidats peuvent ne pas réussir le test Litmus de services et être implémentés en tant services. Le test Litmus de services est une aide permettant de déterminer quels services doivent être exposés ; si une entreprise choisit d'exposer des services candidats qui n'ont pas réussi le test Litmus de services, cela implique que les avantages associés à une architecture SOA ne seront pas réalisés.

Les services candidats qui ont échoué aux tests Litmus de services devront être implémentés selon une méthode donnée car ils doivent remplir des exigences métier. Ils peuvent être implémentés en tant que méthodes sur les composants de service et ne nécessiteront pas la génération de WSDL ou d'autres formes de définitions de service ; ils peuvent aussi être utilisés en tant qu'entités non exposables.

Considérations

L'application des tests Litmus de services est un processus itératif. Pour la première phase d'élaboration, les décisions doivent être prises sur la base des connaissances en cours. Les tests Litmus de services doivent alors être réexaminés au fur et à mesure que les informations proviennent du processus de conception.

Les tests Litmus de services, pour chaque service candidat, doivent être appliqués et révisés avec les spécialistes ou les intervenants appropriés.

L'examen des résultats des tests de Litmus de services est une façon utile de contrôler la pertinence de la granularité des critères et des services. Par exemple, si un trop grand nombre de services candidats passent un test donné, cette définition de test est peut-être trop large ou la granularité du niveau de service est peut-être inappropriée.

Un service peut échouer à un ou plusieurs tests Litmus de services mais peut malgré cela être exposé en raison de décisions spécifiques du projet (gestion ou informatique). Cela est acceptable. Une décision d'ordre architectural ou métier peut être prise pour exposer un service malgré les tests Litmus de services.

Etapes
Vérifiez que le service est aligné sur le métier

Le premier test d'un service concerne son alignement sur le métier. Si la trace du service ne remonte pas à une tâche ou un objectif métier, le service peut ne pas fournir les avantages requis pour l'implémentation SOA. Les questions suivantes, si elles obtiennent toutes une réponse positive, signifient que le service est aligné sur le métier.

  • Le service fournit-il une fonctionnalité métier obligatoire qui prend en charge les processus et les objectifs métier ? (voir Tâche : Analyse de processus métier )
  • L'entreprise souhaite-t-elle financer le service durant son cycle de vie : application des accès, gestion, gouvernance et maintenance ?
  • L'entreprise souhaite-t-elle partager le service en interne ou en externe avec des clients ou des partenaires commerciaux ? Par exemple, les implications peuvent être des coûts supplémentaires, la valeur confidentielle métier, la sécurité, etc.
  • Existe-t-il des opportunités présentes ou futures au sein de l'entreprise pour réutiliser le service ?
Vérifiez que le service est composable

La composabilité est définie comme un attribut qui permet au service de participer à une composition de service. Les applications peuvent être créées à l'aide des deux types de composition.

  • Le service remplit-il les conditions des attributs de qualité de service tels qu'elles sont définies dans les exigences non fonctionnelles de la composition ?
  • Le service est-il sans état ? (voir Instructions : Gestion des états pour les services)
  • Le service est-il auto-contenu ? Le service peut-il être déployé indépendamment afin d'atteindre un objectif métier bien qu'il puisse coopérer avec d'autres services en phase d'exécution pour exécuter des processus métier ? Il n'existe aucune dépendance implicite du service sur d'autres fonctionnalités intégrées. Tous les services dépendants sont remplaçables ou auto-contenus.
  • La technologie d'implémentation du service est-elle neutre ? Une technologie neutre signifie que le service n'impose pas le support de protocoles ou de dispositifs hors normes (et inconnus du consommateur), par exemple, le composant constitutif requiert les interventions via une interface d'application hors normes.
    Ce test s'applique uniquement lorsque le service est déployé dans l'environnement du consommateur. Par exemple : une entreprise fournit un service d'extraction des images à ses clients. Elle peut proposer cette fonction à ses clients abonnés via un service Web. L'entreprise peut également fournir à ses clients la fonction d'extraction d'images exposée en tant que service Web et une collection d'images. L'implémentation de la recherche de technologie sera alors une charge pour le client.
Vérifiez que le service possède une description externe

La première propriété d'un service est qu'il possède une description de service externalisée. La description de service externalisée peut être soit générée automatiquement à l'aide d'outils, soit manuellement.

  • Le service possède-t-il une description de service externalisée distincte de l'implémentation physique sous-jacente ? Un exemple actuel est WSDL.
  • Le service peut-il être reconnu et lié à l'aide de la description de service ?
  • La description de service contient-elle des métadonnées sur elle-même ? La description de service doit être auto-suffisante et contenir ou référencer toutes les informations nécessaires pour comprendre l'échange de messages entre le consommateur et le fournisseur d'un service.
Vérifiez que le service est réutilisable

Ce service peut-il être utilisé par l'intervenant métier dans tous les processus où sa fonction est requise ?

Vérifiez que le service est techniquement réalisable

La faisabilité technique assure que le service peut effectivement être réalisé (implémenté et déployé) conformément aux exigences fonctionnelles et non fonctionnelles à l'aide de technologies disponibles.

  • L'effort d'implémentation et de gestion pour le service est-il raisonnable et réalisable étant donné les exigences ou l'infrastructure de l'implémentation ?
    Effectué après l'exploration de faisabilité technique de la réalisation