Réussir votre SOA : Un guide pratique en 10 questions (2/3)

... la suite du billet précédent Un guide pratique en 10 questions (1/3)

3) Qu’est-ce qui caractérise un service réussi ?

Idéalement un service devrait satisfaire les conditions suivantes:

- Réutilisable : Avoir plusieurs clients pour un même service - Évolutif : Les besoins évoluent dans le temps. Il est important que le service soit conçu de telle manière à supporter, du moins, les modifications mineures - Autoportant /explicite, nécessitant peu de documentation pour qu'il soit réutilisable - Facilement testable par le client : autonomie du client à tester - Respectant les contraintes requises de performance et de montée en charge

Des services respectant ces caractéristiques permettent à la DSI de disposer de services à forte valeur ajoutée permettant notamment à l’entreprise de : - Réduire les coûts d’échanges inter-applications - Accélérer la mise à disposition de nouvelles fonctionnalités aux utilisateurs

4) Quelles sont les meilleures pratiques pour bien architecturer une plateforme de services ? Afin de garantir une bonne qualité de service, les principes architecturaux suivants sont à prendre en considération:

Réduire le nombre d'étages inclus dans la composition de service Idéalement, il faut tabler sur 2 niveaux de composition de services (Maximum trois niveaux si on a des processus à gérer). Cela permet d'éviter le problème de dépendance en termes de qualité de service à travers les différents niveaux de composition et de réduire la complexité de gestion des versions des services impliqués dans la composition du service (cf. [Versioning des services: principes et éléments d’architecture…](Versioning des services: principes et éléments d’architecture…)).

Bien cibler le porteur de la composition La composition de service peut être portée soit par le consommateur du service, soit par le fournisseur de service pour proposer un service de plus forte valeur ajoutée: - Si les consommateurs présentent des besoins différents : c’est à la charge de chaque consommateur de composer le service dont il a besoin. - Si les consommateurs partagent les mêmes besoins : dans ce cas, la composition est à implémenter par le fournisseur de service

Pouvoir absorber la montée en charge en termes de sollicitation d'un service Un service/une plateforme de services qui n'implémente pas les bonnes pratiques pour gérer les montées en charge peut avoir un lourd impact sur la bonne exécution et la réutilisation du service à terme. Techniquement, des leviers architecturaux et des bonnes pratiques de conception doivent être prévus. Par exemple, la mise en place d’une couche de "Queuing" entre le fournisseur et le consommateur de service pour persister les requêtes des clients et lisser la charge pour le fournisseur de service. Une bonne pratique serait par exemple de débloquer les "threads" de traitement au niveau fournisseur en gérant des « time-out » quand aucune réponse ne peut être renvoyée à temps, etc.

5) Comment bien concevoir un service?

Qualifier un service

Ci-dessous une liste préalable de questions pour qualifier un service : - Quels sont les bénéficiaires potentiels du service (interne, partenaire, grand public)?

L'identification des types de bénéficiaires potentiels permet de cibler la bonne politique de gouvernance autour de la gestion du/des service(s): - Pour des bénéficiaires internes à l'entreprise: la gouvernance du service est totalement interne à l'entreprise. - Pour les partenaires externes, la gouvernance du service est partagée avec le partenaire. Dans ce cas, en tant que fournisseur de service, il faudra limiter les impacts et garantir au maximum une compatibilité ascendante des versions de service

Par ailleurs, la connaissance des bénéficiaires permet aussi de fixer le niveau de sécurisation des services et le choix de la politique qui convient le mieux

- Combien de clients potentiels seraient intéressés par le service?

Avoir une estimation du nombre de consommateurs à gérer permettra de positionner le curseur vis-à-vis de la généricité des contrats de service. Faut-il s'orienter vers un service le plus générique possible, ou bien proposer une offre de services pour répondre à des besoins bien particuliers ?

- Quelle qualité de service requise ?

La connaissance des contraintes de volumétrie, de performance et de disponibilité permet de prendre en considération, dans la conception du service, des bonnes orientations techniques et architecturales permettant d'atteindre la qualité de service requise.

Spécifier le service

Une fois la qualification faite, les points suivants sont à prendre en compte au moment de la spécification du service: - Étudier la granularité du service pour disposer d’un meilleur compromis entre performance et modularité - Couvrir un domaine métier donné de telle façon à proposer une cohérence entre les services, et éviter le recouvrement des fonctionnalités qu’ils proposent.

En d'autres termes, il faut éviter les services « couteau suisse », c'est à dire le service dont le contrat est tellement générique, que les objets qu'il traite n'ont aucune signification fonctionnelle.

La solution pourrait être de développer une « offre de services » autour d’un service principal qui traite un objet métier bien identifié. De point de vue pratique, les éléments ci-dessous orientent la bonne conception des services : - Éviter le service qui manipule plusieurs objets métiers, c’est-à-dire la signification de l’objet dépend des paramètres renseignés dans la requête ou la réponse.

- Éviter les champs paramètres/valeurs. Typer plutôt les champs du service. Cette orientation permet à celui qui va l’utiliser d’être bien guidé sans se sentir obligé de parcourir les centaines de pages de spécifications.

- Si le protocole SOAP est choisi, décomposer le service en "operations" de telle façon que cela constitue un module homogène autour de l’objet métier manipulé.

- Penser à la distribution/diffusion du WSDL et son partage avec d'autres interlocuteurs qui auront à utiliser le service en question. Avoir plus de flexibilité dans la diffusion des services ainsi que leur maintenance.

- Distinguer le volet contractuel des formats de messages du contrat de service du volet transport (HTTP, JMS, SMTP, etc.)

- Prévoir des services stateless. Aucune context-session ne doit être gérée.

On distingue 2 types de services. Des services "applicatifs" constituant un émissaire applicatifs et correspondant plus ou moins à des services CRUD (Create, Read, Update, Delete) et des services de type "Processus".

1) Services applicatifs Ce sont des services qui portent sur des objets métier unitaires et qui permettent d'exécuter des actions de création, de suppression, de recherche et de vérification. Autour d'un service principal, l’idée serait de définir une offre de services pour couvrir un périmètre/domaine particulier.

Exemple de règle de nommage: Une règle de nommage pour le service principal pourrait être : Une [action] + [objet métier]; avec [action] = put, set, update, create, delete, etc. Exemple d'un service Principal : GetStock

Néanmoins, la granularité d’un objet métier est aussi importante, plusieurs variantes d’un objet peuvent en découler pour définir une offre de services:

Exemple d'offre de services: Si on considère que le service principal "GetStock" couvre 80% des cas d'utilisation, une offre de services peut se traduire comme suit:

1. En considérant une granularité plus fine de l'objet métier. Exemple: - GetStockRetourClient: l'objet métier "StockRetourClient" est un sous-objet métier de stock - Etc.

2. En appliquant un filtre sur le service principal. Exemple: - GetStockByReference - Etc.

2) Services de type processus Cette typologie de service englobe les services de plus grosse granularité, issus généralement de la composition de services de l’offre de services applicatifs. - gererTournee - gererPurchaseOrder - Etc.