Accueil > Web Services - SOA > Service à blocs

Service à blocs

Lors de ma dernière mission, j’ai été confronté à un besoin qui me semble récurrent et pour lequel nous avons trouvé une solution qu’il me semble intéressant de partager. Ce besoin était de fournir des informations « presque identiques » à des clients « presque pareils ». Le problème étant dans le « presque », évidemment.

Prenons un exemple :

Pour une commande de meuble classique, un client se balade dans le magasin, choisit ses meubles et va voir un vendeur.
Le vendeur va alors enregistrer la commande du client ainsi que les détails nécessaires à la livraison. Le client peut alors décider d’un règlement immédiat ou différé, du dépôt simple ou du montage des meubles…
Le jour prévu, le livreur vient déposer les meubles chez le client et les monter si cela est prévu. Une fois cela effectué, le livreur signale la commande comme étant terminée.

Ici, les infos « presque identiques » sont la commande, le client, la livraison.
Les clients « presque pareils » sont :

  • le logiciel de préparation des commandes : besoin du numéro de commande, son statut (prête à être préparée par exemple), la date de livraison voulue et les meubles à préparer.
  • le SI du livreur : besoin du numéro de commande, de son statut (prête à livrer), de la date de livraison, de l’adresse de livraison, du nom du client, de son numéro de téléphone, des meubles à livrer, du nom du livreur.
  • l’application de SAV : besoin du numéro de commande, de son statut, de la date de livraison, de l’adresse de livraison, du nom du client, de son numéro de téléphone, des meubles commandés, de la date d’achat, de leur disponibilité et de leur prix ainsi que des modifications effectuées sur la commande depuis sa création.…

Là, vous vous dites : « Ok, on connaît, il va nous dire comment diffuser l’information entre plusieurs applications/SI et nous sortir le webservice ! Quel génie ! Quelle originalité ! Encore un qui a réinventé la roue ! »
Presque.

Oui au service.
Mais le service à blocs.

En effet, on pourrait « juste » créer autant de services ou (mieux) autant de méthodes à un service que l’on aurait de besoins légèrement différents, soit, dans notre exemple trois méthodes : préparerCommande, livrerCommande et suivreCommande.

C’est très bien, mais qu’en est-il si demain, on décide de permettre à une application mobile (très à la mode ces trucs-là) d’afficher le statut de la commande et son prix d’après le numéro de commande et le nom du client associé ?

Il faudra soit développer une nouvelle méthode spécifique (avoirStatutCommande, par exemple), soit utiliser suivreCommande qui remonte beaucoup (trop ?) d’informations.

L’idée est plutôt de créer un unique service manipulant des blocs d’informations.

Pour notre exemple, les blocs seraient les suivants :

  • Un bloc idCommande avec le numéro de commande et son statut
  • Un bloc idClient avec le nom et le numéro de téléphone du client
  • Un bloc livraison avec l’adresse de livraison, la date de livraison voulue et le nom du livreur
  • Un bloc meubles avec les références des meubles commandés
  • Un bloc historique avec l’ensemble des actions effectuées sur la commande
  • Un bloc commercial avec le prix total de la commande et le nom du vendeur

Ainsi, on peut avoir un service uni-méthode renvoyant les blocs en fonction du profil de l’appelant.

Et quand nos amis du mobile se rappellent à nous, que se passe-t-il ?
On crée juste le profil adéquat et hop, ça marche !
Pas besoin de relivraison. Formidable non ?

Mais là où le système par blocs montre toute son utilité, c’est quand un client/partenaire a besoin d’informations supplémentaires.
Dans le cas de la livraison de meubles, si le magasin décide de passer par un sous-traitant spécialisé pour la livraison ET le montage, on peut facilement rajouter un bloc planDesMeubles au service et l’autoriser pour le profil de ce nouveau sous-traitant.
L’avantage étant alors que seul ce dernier doit prendre en compte la nouvelle version du contrat d’interface du service ainsi modifié.

Dans un monde où les legos servent à enseigner des principes d’agilité, il est normal de s’en inspirer, non ? ^^

PS : Ce système a encore plein d’autres avantages quand les données sont réparties ET dupliquées dans plusieurs sous-systèmes, nous verrons cela une prochaine fois.

  1. MULLER Charles
    17/04/2014 à 14:57 | #1

    Merci pour ce sujet,

    Fort intéressant et très bien détaillé.

    Charles

  1. Pas encore de trackbacks


un × = 8