Permettre à une application de consommer un composant exposé par une autre application. Tel est le rôle du Service Gateway Pattern. Décryptage de cette notion centrale pour la SOA, et exemple d'implémentation.
|
|
Mourad Lafer (EDIS Consulting) |
|
|
|
|
|
De plus en plus pour venir à bout de la complexité des applications et maximiser la réactivité aux changements, celles-ci sont architecturé en services réutilisables.
C'est notamment l'esprit de l'approche SOA qui définie un modèle de conception et d'interaction applicative mettant en uvre des connexions en couplage lâche entre divers composants logiciels associés à des contrats de service définissant précisément leurs modalités d'interaction. Ici, on entend par "service" une action exécutée par un composant "fournisseur" à l'attention d'un composant "consommateur", basé éventuellement sur un autre système.
Rendre un service disponible c'est définir le contrat (API) à respecter afin d'accéder au service. Le contrat définit également les protocoles de communications, la structure des messages échangés et l'URI ou point d'entrée/d'accès.
Consommer un service dans une application peut être un processus complexe. Tout objet désirant accéder à cette ressource doit transiter par une passerelle qui se charge de traduire tout appel de méthode simple en appels API appropriés.
Nous présentons dans cet article le Service Gateway Design Pattern, qui constitue une méthode d'abstraction de la communication avec une ressource externe via un point d'accès unique.
