Qu'est ce qu'une architecture orientée service ?

Wed, 20 Oct 2004 01:15:29 GMT

En discutant cette après midi avec des amis développeurs, je me suis rendu compte que j'écris de moins en moins d'articles techniques en Français sur ce blog. A y regarder de plus près, je suis de plus en plus amené à intervenir dans des conférences et dans du consulting dans des régions Anglophones ou partiellement anglophones, et cela me pousse à la facilité d'écrire et de parler en anglais. Si je continue à penser que nos développeurs en Afrique du nord doivent apprendre l'anglais (il suffit de faire une recherche Google sur un sujet de développement quelconque en anglais puis en français pour s'en rendre compte), je ne veux pas laisser derrière ceux qui ne parlent pas la langue de Shakespeare.

Je me propose donc de aire une série d'articles sur l'architecture orientée service (SOA), qui est le sujet le plus d'actualité aujourd'hui en terme d'approche et d'architecture pour développer nos solutions.

Qu'est ce qu'une Architecture Orientée Service ?

Si ce concept a vu le jour (sans l'appellation) avec l'apparition des Web Services et l'impératif d'intégration entre les applications, il est aujourd'hui entrain de devenir L'approche pour créer des solutions durables. L'appellation reste cependant barbare et non parlante pour beaucoup d'entre nous qui ne s'y sont pas frotté de près. Alors, Qu'est ce que c'est ?

Une réponse de faciliter pourrait consister à dire qu'une application est orientée service si elle s'expose en tant que Web Services XML...

Si cette définition peut sembler valable à première vue, elle ne l'est pas vraiment, et pour diverses raisons. On ne peut pas lier une approche de développement à une technologie particulière. Une architecture orientée service ne peut-elle pas exister en dehors des Web Services ? Sa durée de vie est elle aussi courte que celle d'une seule technologie ? Ou est-ce au contraire une évolution des techniques d'architecture d'application actuelles, qui elles mêmes sont une évolution des approches du passé ?

Revenons donc à une approche plus pragmatique, et essayons de définir le concept par étapes. D'abord, il est clair que SOA veut dire que l'on conçoit nos solutions comme un ensemble de "services". Ainsi, ajouter de la fonctionnalité revient à ajouter des services. Chaque service étant responsable de la fonctionnalité qu'il fournit, il centralise donc toute la logique nécessaire à l'accomplissement de ses tâches, et donc toute modification d'une telle logique ne toucherait que ce service.

La définition précédente nous laisse sur notre faim, car elle n'explique pas ce que sont ces fameux "services" qui constitueraient nos applications futures... Il a fallut plusieurs années depuis l'apparition de la notion de SOA (dont l'appellation revient, à ma connaissance, à Gartner), avant que l'on ne commence à voir ressortir une unanimité sur ce qui définit un service. Il y a quatre critères à satisfaire pour faire partie du club :

1. Les frontières sont explicites : Un service définit clairement ses points d'entrée. Aucune communication par effet de vases n'est permise. Un Service ne peut pas partager l'état avec un autre service (ou autre système, application, ou ce qu'on veut). Ainsi, un service ne permet pas qu'on s'intègre à lui en partageant sa base de donnée, en appelant directement ses implémentations interne (sous forme de composants métier ou autres), ou de quelque autre manière. Il définit clairement ses points d'entrées, et bloque toute tentative de pénétration par un quelconque autre accès.

2. Les échanges se font par contrat : Un service ne donne aucune indication sur la manière dont il est implémenté, de la technologie avec laquelle il est créé, ou de la plateforme sur la quelle il est déployé. Il expose simplement un contrat qui stipule se que sont les formats de données échangés, les points d'entrée, quelles informations sont acceptée en entrée pour chaque point d'entrée, et quelles informations sont données en réponse. Un service ou système qui appellerait ce service ne peut pas assumer une quelconque connaissance sur l'implémentation du service, et ne doit pas avoir de problème pour parler à un autre service qui expose le même contrat si le service est remplacé par un autre. Cela permet l'évolution. Si une règle métier change, tant que le contrat continue à être respecté, aucun autre service ou système n'est touché.

3. Autonomie: Un service doit être autonome. Si les frontières explicites forcent déjà qu'un service ne communique pas de façon transversale avec un autre service, et qu'il ne partage aucun état avec un autre service, l'autonomie va encore plus loin.

§ Un service doit "posséder" ses propres données. Cette possession est exclusive. Un service ne peut en aucun cas accéder à une base de données à laquelle un autre service peut accéder, même si cette base est en lecture seule. Par exemple, un service ne peut pas renvoyer la clé d'un enregistrement et laisser le service qui l'a appelé utiliser la clé pour récupérer l'information sur la base.

§ De même, un service ne peut pas partager d'état entre ses propres instances. Par exemple, un service ne peut pas stocker d'information dans des variables statiques. Un service ne peut pas avoir un cache utilisé par toutes les instances. Un service ne peut même pas avoir de variables persistées entre un appel et le suivant. C'est ce que l'on appelle communément ne pas avoir d'état. Il doit pourvoir à récupérer l'information sur l'appel pour savoir à quelle étape de l'exécution il doit se situer (si l'exécution comprend plusieurs appels successifs).

4. La compatibilité est négociée en fonction de stratégies: Un service se doit de définir toutes les méthodes et protocoles d'échange qu'il permet en terme de stratégies. Si le service permet des séquences d'appels successifs, ils doivent être définis dans ces stratégies. Ainsi, un autre service, en utilisant simplement les contrats et les stratégies, peut définir s'il peut appeler ce service, et quelles méthodes et protocoles d'échange utiliser.

Un Service n'est donc pas nécessairement un Web Service XML. Si très souvent, on implémente SOA à travers les Web Services XML, c'est qu'ils offrent des avantages réels en terme essentiellement d'interopérabilité. Mais on peut très bien imaginer des services non inter opérable, utilisant des protocoles propriétaires pour les échanges. Cependant, ils ne peuvent le faire que si aucune supposition quand à l'implémentation n'est faite, et donc que les échanges n'utilisent pas des objets mais des messages. Ce qui limite énormément les technologies utilisables aujourd'hui pour créer des services, et rendent les Web Services XML la principale technologie pour les réaliser, même si on peut utiliser des files d'attentes de messages tels que MSMQ ou MQSeries, l'échange de fichiers texte, de fichiers XML qui ne sont pas nécessairement encapsulés dans une enveloppe SOAP, ou même des échanges de structures à travers des technologies qui étaient faites pour les échanges d'objet...

Dans le prochain article de cette série, je parlerais de façon beaucoup plus détaillée des services et des messages.

This weblog is sponsored by newtelligence AG.

Malek's Moorish tales

Qu'est ce qu'une architecture orientée service ?