Exemple de réutilisation de service

Imaginons un contexte

Nous sommes un Groupe, dans le commerce en ligne, composé de 3 enseignes : Azalea, Camellia et Melica.

Les applications métier

Il a été décidé par la Direction que les données des clients de chaque enseigne ne soient pas mélangées dans une seule et même base de données mais bien dans trois bases de données différentes, pour des raisons de cloisonnement de données, d’indépendance, etc.
Cependant, chacun de ces référentiels de données Client est issu d’une même souche gérée au niveau Groupe et nommée « refClient ». Le code est ainsi centralisé dans un seul et unique projet. Le projet est dit « mutualisé ».
Le projet « refClient » maintient la structure du référentiel et expose un Web Service de type « CRUD » qui, comme son acronyme l’indique, permet de consulter, créer, modifier et supprimer des lignes du référentiel.
« refClient » est ensuite déployé autant de fois qu’il y a d’enseignes, à chaque fois avec un paramétrage et sur un serveur d’application propre à l’enseigne. Dans notre exemple, il existe donc trois instances de « refClient » appelées « refClientAzalea », « refClientCamellia » et « refClientMelica ».
Chaque instance expose donc le Web Service « CRUD » sur le serveur d’application sur lequel elle est déployée :

• http://srv-azalea/refClientAzalea/ws/crud
• http://srv-camellia/refClientCamellia/ws/crud
• http://srv-melica/refClientMelica/ws/crud

L’intégration inter-applicative

Le Groupe a mis en place une solution d’intégration inter-applicative (que nous appellerons par la suite « la plateforme d’échanges »). Inutile de préciser laquelle, elle pourrait être de n’importe quelle nature : un bus de service d’entreprise (ESB), une plateforme SOA, une solution d’API Management ou encore une solution IaaS.
Le choix a été fait par la Direction de placer la plateforme d’échanges au niveau Groupe, c’est-à-dire qu’il n’en existe qu’une seule et qu’elle centralise les échanges de toutes les enseignes. On dira que la plateforme d’échanges est « transverse ».
Concrètement, même si chaque enseigne dispose de ses propres applications, les échanges de chaque enseigne circulent à travers la même plateforme d’échanges.
Certaines de ces applications sont dites « dédiées », c’est-à-dire qu’elles sont spécifiques à l’enseigne sur laquelle elles sont déployées (CRM, progiciel de facturation, etc). D’autres applications, comme le référentiel Client défini au-dessus, sont dites « mutualisées », c’est-à-dire qu’elles exposent la même interface quelle que soit l’enseigne sur laquelle elles sont déployées.
C’est de ces applications « mutualisées » dont on parle ici, celles qui sont déployées pour plusieurs enseignes tout en exposant une seule et même interface. Il peut s’agir d’applications de type référentiel comme l’exemple de « refClient » ; il peut s’agir d’applications transverses telles que des applications de statistiques métier ou techniques, des applications d’export de données, etc.

« API-sation » du service

Gardons l’exemple de notre référentiel Client qui est donc dans notre Groupe une application « mutualisée ». Elle est déployée à trois endroits différents mais expose à chaque fois la même interface. Seule l’URL d’accès à chacune de ces trois instances est différente.
Dans une idée de réutilisation de service, nous souhaitons virtualiser le service « CRUD » de mise à jour du référentiel Client. Nous souhaitons créer un point d’entrée unique vers chacune des trois instances, quelle que soit l’enseigne. Sur internet, vous trouverez parfois le terme de « API-sation ».
« API-ser », une application qui offre de nombreux avantages :

• accélère les développements et donc l’innovation
• facilite l’ouverture des données, la connexion aux partenaires
• centralise la sécurité
• …

Décidons d’appeler « crudClient » la version virtualisée de notre service « CRUD » de mise à jour du référentiel Client. Il sera déployé sur la plateforme d’échanges transverse à toutes les enseignes.

Le contrat de « crudClient »

Si le service métier « CRUD » existe trois fois à trois endroits différents, notre service virtualisé « crudClient », lui, existe une seule fois sur notre plateforme d’échanges.
Le service « crudClient » réexposera la même interface que son sous-jacent – le service métier.
Si chaque enseigne dispose de son propre outil de CRM, alors chaque CRM appellera l’unique service « crudClient » pour mettre à jour son référentiel.
L’intelligence sera placée dans « crudClient » au niveau de la plateforme d’échanges, qui détectera de quel CRM vient la requête et par conséquent vers quelle instance de référentiel elle doit la rediriger.

Possibilités

Toutes les requêtes de toutes les enseignes passant désormais par « crudClient », un seul développement permet de faire évoluer trois flux. Ajouter une fonctionnalité pour le référentiel Client de Azalea l’ajoute automatiquement à Camellia et Melica.
Un service « CRUD » devrait rester assez générique pour qu’il n’y ait normalement pas de besoin spécifique à une enseigne. Si tel était le cas, une plateforme d’échanges est tout à fait capable d’exposer plusieurs versions d’un même service. Exposer « plusieurs versions d’un même service » reste bien différent et bien plus agile que d’exposer « plusieurs services différents ».

Implémentation

Réaliser un service tel que « crudClient » nécessite d’utiliser le routage dynamique (« Dynamic Routing »).
Le Dynamic Routing existe dans toute bonne solution d’intégration inter-applicative.
Par exemple, dans l’Oracle Service Bus, un service tel que « crudClient » contiendrait typiquement un Proxy Service et trois Business Services (un par enseigne). Le Proxy Service jouerait ici le rôle de porte d’entrée unique, exposant une URL accessible par toutes les enseignes. Chacun des trois Business Services garderait la configuration (technique) spécifique à chaque enseigne (timeout différent, sécurité différente, etc).
Le Proxy Service, en tant que porte d’entrée unique, porterait l’URL d’accès unique qui pourrait être la suivante :

• http://esb-groupe/refClient/ws/crud

Le Dynamic Routing serait donc situé au niveau du Proxy Service et appliquerait par exemple une des règles suivantes :
Si le nom de serveur du client commence par « aza » alors rediriger la requête vers « refClientAzalea » (http://srv-azalea/refClientAzalea/ws/crud).
Si la requête contient un en-tête HTTP dont la clé est « enseigne » et que la valeur est « camellia » alors rediriger la requête vers « refClientCamellia » (http://srv-camellia/refClientCamellia/ws/crud).
…
Bien entendu, il s’agit de règles données rapidement en exemple, mais elles se doivent absolument d’être fiables dans le temps. Car le plus gros risque d’un tel service est de rediriger une requête vers le mauvais serveur… Si aucune des règles n’est respectée alors ne redirigez par la requête vers un référentiel par défaut, levez par exemple un message d’erreur qui indiquera au client que la requête ne permet pas d’identifier le serveur à contacter.

Conclusion

Ce qui est décrit ci-dessus n’est qu’un exemple, l’important est que chaque service puisse être facilement et rapidement réutilisable pour une autre enseigne du groupe, un autre partenaire d’une enseigne, etc.
Tant que vous le pouvez, mutualisez vos projets. Cela vous permettra de créer votre propre écosystème, de centraliser la sécurité de vos services et donc de vos données. Cela permettra d’accélérer les développements et donc l’innovation et l’ouverture aux partenaires.
Si des progiciels différents sont utilisés pour le CRM de chaque enseigne, pourquoi ne pas créer un « wrapper » qui rassemblerait les fonctionnalités principales derrière une interface unique. La virtualisation de ce « wrapper » sur la plateforme d’échanges serait alors plus facile.
L’idée de fond est de toujours penser « API », toujours penser que vos services seront réutilisés, de l’intérieur de votre réseau mais peut-être aussi de l’extérieur par des partenaires. Développez toujours vos services dans cette idée là.