Devoxx – Jour 2 – SOA en pratique

Les sessions dédiées à SOA étaient présentes cette année encore à Devoxx. Nicolai Josuttis a animé une présentation intitulée « SOA in practice » à l’image du titre du livre dont il est l’auteur, publié chez O’Reilly.

Passage obligé de toute présentation sur SOA, Nicolai Josuttis commence par introduire l’ensemble des concepts gravitant autour de l’architecture orientée services. Nous passerons sur ces rappels ici, car malgré quelques divergences dans les définitions, on retrouve les idées décrites dans les différents articles portant sur SOA que nous avons pu publier jusqu’alors.

Après cette introduction, Nicolai Josuttis s’est arrêté sur les débats ayant agité le petit monde des SOAistes en ce début d’année : ce modèle d’architecture est-il mort ? N’était-ce qu’une mode de passage ? Non, le concept de service garde toute sa valeur pour l’entreprise et la suite de sa présentation, sans rien cacher des défauts de SOA, montrera tout son intérêt.

La suite de la présentation s’oriente rapidement autour de la mise en pratique de ces concepts.

 

 

SOA en pratique dans l’entreprise

Entre frontends et backends

Une architecture orientée services repose en général sur un ensemble de frontends et une série de backends idéalement organisés en respectant les frontières des départements ou des business units de l’entreprise. La figure suivante représente ce type de système :

Le frontend peut prendre plusieurs formes. Il peut s’agir d’une simple interface de visualisation qui se contente alors de présenter les données formées par les services d’agrégation sous-jacents. A l’inverse, il peut permettre la modification des données, ce qui en fait une application plus intelligente. Il est alors également nécessaire de faire un choix quant à la validation des données entrantes : celle-ci peut se faire dans le frontend, dans le frontend et le backend, ou via un service dédié. Cette dernière solution simplifie l’architecture en assurant la cohérence de la validation mais entraîne une grande quantité d’invocations de services.

Versionning

Les services exposés dans une SOA subissent en général des modifications au cours de leur vie car ils mettent en œuvre des besoins en perpétuelle évolution. Les consommateurs ne pouvant alors être tous mis à jour lorsque le service évolue, plusieurs versions vont coexister.

Nicolai Josuttis préconise alors de limiter à 3 le nombre de versions d’un même service en production. Pour cela :

• Il est nécessaire que les consommateurs d’une version obsolète d’un service fassent évoluer leur application afin d’exploiter la version la plus récente.
• Le point précédent implique qu’une collaboration est nécessaire entre producteur et consommateur.
• Il implique également qu’il est vital d’être en mesure d’énumérer l’ensemble des consommateurs d’un service.

Interrogé sur le positionnement de nouveaux framework tels que Apache Thrift gérant nativement la problématique de versionning, Nicolai Josuttis explique qu’il s’agit là d’un détail d’implémentation qui ne doit pas être une justification pour contourner le nombre maximum de versions simultanément en production.

Ré-utilisabilité

La ré-utilisabilité est une des propriétés fondamentales des services dans une SOA.

Pourtant, Nicolai Josuttis a pu observer qu’en pratique cette propriété est rarement possible. En effet, il explique que ses observations ont montré que la majorité des services d’un système d’information ont au plus deux consommateurs. Certains ne sont même pas consommés.

Dans la mesure où la ré-utilisabilité va souvent à l’encontre des performances puisqu’il est alors souvent nécessaire d’invoquer plusieurs services, il est conseillé de se fixer des objectifs raisonnables quant à cette propriété.

Annuaires

Les annuaires de services permettent de recenser l’ensemble des services disponibles dans une SOA.

Nicolai Josuttis préconise de ne pas mettre en œuvre d’annuaire dès la création de l’architecture orientée services, mais d’attendre que le besoin s’en fasse naturellement ressentir.

Gouvernance

La SOA faisant interagir l’ensemble des départements de l’entreprise, des aspects humains et des problématiques de gouvernance surviennent inévitablement.

Il est suggéré de recourir à une équipe SOA dédiée, assurant le respect d’une stratégie d’architecture globale.

Lors de l’émergence de SOA dans l’entreprise, il est indispensable de procéder progressivement, en lançant des projets pilotes permettant de détecter les problématiques et d’adapter les équipes à cette nouvelle architecture. Ainsi le processus de transition peut prendre 5 ans.

SOA à l’heure du bilan

Après avoir énuméré l’ensemble de ces problématiques propres à SOA, Nicolai Josuttis pose une question simple : compte-tenu de tous ces défauts, pourquoi passer à SOA ? Il répond simplement en montrant que dans de nombreuses situations, ce modèle d’architecture n’est pas contournable pour satisfaire les besoins de communications entre les composantes de l’entreprise.

Enfin, il reconnait et dénonce le hype qui a entouré SOA, mais n’en minimise pas l’intérêt pour autant.

Conclusion

L’architecture orientée services aurait-elle atteint la maturité ? C’est en tout cas l’impression qui transparaît face à la multiplication de présentations telles que celle de Nicolai Jusuttis, imprégnées de pragmatisme et de réalisme, tout en montrant son rôle incontournable dans le remplacement des systèmes monolithiques ou organisés en silos isolés.

L’apparition d’outils et de frameworks légers tranchant avec les solutions très lourdes que SOA a connu dans ses débuts, ainsi que la percée des méthodes agiles pour leur mise en œuvre, s’ajoutent à ces nouveaux discours pour constituer le renouveau des architectures orientées services.