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.
|