-
Le contrat standardisé (suite)
Le contrat standardisé, standardiser pour faciliter la communication
- Le contrat de service est donc une notion complexe qui ne se limite pas à la (simple) définition d’interfaces.
- Un contrat de service est constitué de nombreux éléments (techniques ou non) qui forment un fond documentaire pour lequel il est préférable (voire indispensable) de respecter un formalisme commun.
- L’utilisation de ce formalisme commun est le meilleur moyen de construire un modèle cohérent et donc facile à comprendre et à partager.
- La notion de contrat de service standardisé ramène à celle de contrat first qui est, comme nous l’évoquions dans notre billet sur l’interopérabilité des Web Services (sans, une fois de plus, limiter la notion de service à ceux-ci), la meilleure approche de conception de services (voire la seule valable ?).
- Dans cette approche, les contrats font l’objet de développements spécifiques en amont de l’implémentation de la logique du service.
- Le développement de ces contrats doit se faire suivant des règles de standardisation établies pour l’ensemble des services d’un même Système Technique.
- Centraliser pour encourager la réutilisation
- En plus de cadrer la définition des contrats (et donc de faciliter la communication), l’utilisation d’un formalisme commun et de règles de standardisations facilite la centralisation des éléments constituant les contrats. Cette centralisation encourage la réutilisation. Parmi les constituants des contrats de services, deux sont de particulièrement bons candidats à la réutilisation :
- Les règles d’utilisation (policies) :
- Les contraintes de sécurité, d’encodage, de versioning sont souvent communes à l’ensemble (ou à un sous-ensemble) des services d’un domaine. De la même façon, les règles métiers sont rarement applicables à un seul service.
- Les formats de données (XSDs) :
- Il est évident que les types et formats de données sont utilisés par plusieurs services. Ces derniers ont même vocation à être utilisés au-delà des services : les types et formats de données sont souvent les mêmes pour les invocations synchrones de service et pour les échanges asynchrones, par exemple au travers d’un bus.
- Pour rendre possible leur réutilisation, il est indispensable de séparer les différents éléments du contrat de service. Plusieurs WSDL pourront ainsi appliquer les mêmes règles (policies) et manipuler les mêmes types de données (XSDs).
-
L’isolation des différents constituants du contrat de service en vue de leur réalisation est une bonne pratique qui tient du bon sens.
-
Il n’est pourtant pas rare de voir des déclarations de type (XSDs) au sein d’une WSDL plutôt qu’un import.
-
Cette approche est aussi aberrante que la re-déclaration en inner class de l’ensemble des types de données manipulés par un Bean (Cette pratique doit être restreinte à des cas bien spécifiques et constituer une exception).
-
La standardisation des contrats de service est donc un élément fondamental de la mise en œuvre d’architectures orientées services (SOA). En effet, la mise en place des bonnes pratiques évoquées dans ce billet offre des gains importants sur deux axes clés :
- Faciliter la communication et le partage de la connaissance :
- La définition d’un ensemble de principes communs de conception des contrats (ex. : conventions de nommage claires pour les entités, les attributs et les relations) permet d’aboutir à un modèle plus cohérent et donc plus facile à comprendre, partager, (ré)utiliser.
- Encourager la réutilisation :
- L’isolation et la centralisation des différents constituants des contrats de services facilitent indéniablement leur réutilisation.
-
Il ne faut pas perdre de vue que la définition de certains de ces éléments dépasse le simple cadre des contrats de service.
-
Il est par exemple souhaitable que les types et formats de données manipulés par les services soient également utilisés au sein des flux d’intégration.
-
Cette pratique, même si la définition d’un Modèle de Données Canonique reste un exercice difficile, est un gage sur le long terme de maintenabilité, de stabilité et de pérennité.
"Si tu veux être heureux pendant une heure, fais une sieste. Si tu veux être heureux pendant une journée, va à la pêche. Si tu veux être heureux toute ta vie, aide ton prochain."
Voir aussi : http://urbanisation-si.blog4ever.net/
http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Tags : urbanisation des SI, urbanisation si, urba si, urbanisme si, gouvernance si, SOA, processus métier, règle métier, BPM, BRMS
-
Commentaires