La vision du Développement orienté service, par-delà l’architecture

Nous voudrions dans ce billet revenir sur l’esprit, par-delà l’architecture orienté service, la vision du Développement orienté service car ce n’est pas rien, considérant que beaucoup soutiennent qu’en TI, il y a eu un avant et un après SOA !

La raison en est fort simple, avec l’architecture orienté service, les services développés se sont retrouvés au cœur de l’architecture TI, en interface à la fois avec les applications fondamentales et les données.

Bien que cela ne soit pas évident au premier coup d’œil, beaucoup de développeurs y ont tout à coup gagné une marge de manœuvre, une liberté de conception, d’aucuns diront une créativité nouvelle.

AVANT ET APRÈS SOA (TRIDENS, 2011)

En effet, les développeurs ont pu dès lors concentrer toute leur attention sur la spécificité des services à développer, étant moins restreints par les contraintes d’intégration aux applications et données; ainsi, ils ont pu plus facilement optimiser les fonctionnalités critiques à l’opération de leurs services.

Ce faisant, ils ont développé une culture du développement orienté service car en développant des services, on en vient tout naturellement à distinguer ce qui est commun à tout autre service similaire de notre domaine d’affaires. On en vient à catégoriser les fonctionnalités de nos services en types générique et spécifique.

Et on développe des fonctionnalités génériques et des fonctionnalités spécifiques, plus spécialisées, que l’on pourrait qualifier de « domain-driven »; spécifiques à un domaine d’affaires très pointu et même, spécifiques à des processus dans notre domaine d’affaires.

Un exemple très simple serait un service de reconnaissance d’imagerie générale, un service de reconnaissance d’imagerie médicale et un service de reconnaissance faciale pour la police.

On imagine facilement que tous ces services peuvent s’interfacer avec des centaines de banques d’images et qu’elles possèdent un moteur de catégorisation générale et des fonctionnalités génériques de reconnaissance de la profondeur, de la tridimensionnalité, des couleurs, des formes, des humains, des animaux, etc.

Ainsi, on comprendra aussi très bien que le service de reconnaissance d’imagerie médicale possède un algorithme spécifique de reconnaissance des organes et du squelette humain qui s’appuie sur un service de fonctionnalités génériques de reconnaissance de la profondeur, de la tridimensionnalité, des couleurs, des formes, etc.

De même, on imagine facilement que le service de reconnaissance faciale du service de police possède des fonctionnalités spécifiques d’extrapolation des visages humains à partir de photos de coupe transversale ou de visages ombragés mais qui s’appuiera d’abord sur des fonctionnalités génériques de reconnaissance de la profondeur, de la tridimensionnalité, des couleurs, des formes, etc.

Ainsi, dans la vision du Développement orienté service, on développera les fonctionnalités de nos services sur la base de cette distinction; générique et spécifique (domain-driven). Cette dichotomie est fondamentale dans l’esprit du Développement orienté service.

Un autre concept tout aussi important de la vision du Développement orienté service est l’autonomie d’un service. Ainsi, dans le cadre de son développement TI à moyen et long terme, l’entreprise développera de nombreux services. Une bonne pratique du Développement orienté service est de viser l’autonomie la plus complète des services et des fonctions qu’ils utilisent; à savoir, qu’un service puisse être appelé par d’autres services ou applications et « livrer sa marchandise » sans l’aide d’aucune autre application ou service. Pour ce faire, les fonctions développées pour le service devront être autonomes, pouvoir s’exécuter et livrer leurs extrants sans autre besoin que les intrants prévus.

Ainsi, on pourrait penser, dans l’exemple du service de reconnaissance d’imagerie, que les fonctionnalités de reconnaissance et de traitement de la tridimensionnalité font appel aux fonctions (autonomes) de reconnaissance des formes, des couleurs et de la profondeur !

Développement orienté service, avantages

Cette façon de voir le développement orienté service, de décomposer le développement en fonctionnalités spécifiques et génériques, présente un avantage non négligeable; à savoir, que les services dits génériques (et autonomes) sont, par essence, « réutilisables » par d’autres départements, d’autres divisions et d’autres services. Ainsi, ils engendreront des économies de temps et de coûts en termes de frais de développement pour l’entreprise dans l’avenir.

De plus, s’ils sont réutilisables par d’autres services, comme dans le cas des services de reconnaissance d’imagerie, ces services présenteront aussi dès lors un bon potentiel de commercialisation, de revenus.

Finalement, puisqu’il s’agit de services développés avec des fonctionnalités génériques, ils ne devraient théoriquement créer aucun obstacle en termes de mises à jour puisqu’ils n’ont pas nécessité de développement sur mesure contrairement aux fonctionnalités « domain-driven ». Cela peut représenter une économie potentielle… substantielle.

Développement orienté service, prémisse au Cloud

L’autre aspect dans la vision du Développement orienté service, l’autonomie d’un service donné (générique ou domain-driven), présente aussi des avantages.

Lorsqu’un service peut exister de lui-même et « livrer sa marchandise » sans l’aide d’aucune autre application ou service puisqu’il s’appuie essentiellement sur des fonctions autonomes alors il est considéré comme un micro-service.

Les micro-services peuvent facilement être hébergés dans le Cloud et constituent, par conséquent, le premier pas de votre entreprise vers le Cloud ou si vous préférez, une porte d’entrée vers le Cloud.

Event-driven vs Domain-driven

Finalement, dans un monde idéal, les services développés (générique ou domain-driven) sont appelés au bon moment pour les bonnes raisons mais un service ne s’appelle pas lui-même spontanément, il est appelé !

Ainsi, il faut prévoir une alerte, un « trigger », un événement déclencheur qui lancera ou appellera un ou des services; on parle alors de fonctionnalités ou applications « event-driven ».

Les applications ou fonctionnalités « event-driven » appelleront les services, elles serviront à régir les échanges (I/O) entre les services, les systèmes et les applications d’une entreprise.

Bon développement, peu importe votre orientation,

Michel Martel