Concernant la réutilisation de schéma :
La réutilisation de schéma, constitue en effet un objectif qui est rarement atteint (mais qui l’est, même partiellement, dans pas mal de SI).
On retombe dans les mêmes travers qui mènent à la duplication de code ou à l’écriture en N exemplaires de la même fonctionnalité. C’est le syndrome « Not Invented Here ».
Concernant les problèmes de couplage induit par la réutilisation de schémas, la mise en place de versionning sur ces schémas permet de prévenir pas mal de problèmes.

Concernant la découvrabilité :
La découvrabilité des services est en effet, dans sa partie runtime, un espoir inabouti. Il n’en reste pas moins qu’un service doit être découvrable au moment de la conception d’une application composite qui peut potentiellement en avoir l’utilité. Cette découvrabilité passe, par exemple, par la création d’un référentiel documentaire dont la première brique peut se limiter, par exemple, à la mise en place d’un wiki.
En ce qui concerne le droit à utiliser un service, on retombe dans les travers liés à la propriété des composants et au financement au projet.

Pour les autres points, nous aurons l’occasion d’y revenir dans cette série (Prochain billet prévu le 19 mars).

@Bruno
réutilisation des schémas: il s’agit de réutiliser des schémas d’échange de services, à ne pas confondre avec les schémas de l’éventuel référentiel de schémas de données de l’entreprise; les premiers sont « a minima » et extensibles, les seconds sont nécessairement exhaustifs et plus difficiles à gérer. Donc le challenge est moindre.
Du moins, c’est ce qu’on espère

Dans SOA Design patterns, dans un souci de réalisme je pense:
- il y a nombre de patterns pour les services stateful
- la découvrabilité est reléguée aux espoirs inaboutis

Idem pour la « découvrabilité » : dans une organisation multi-partite on n’utilise pas un service parce qu’il existe, mais parce qu’on en a le droit ; et ce droit est donné par un/des urbanistes qui gèrent de facto les mises en relation (note : je ne tiens pas à déclencher de polémique sur le rôle ou l’absence d’urbanistes ou d’architectes dans l’entreprise !).

Le terme « abstraction » est aussi mal choisi : ça reflète mal la qualité de l’interface d’un service (ok pour le juste nécessaire, mais ce n’est pas suffisant).

La définition de stateless est aussi ambigu : qu’un service soit sans état est un impératif : mais je ne comprend pas le devoir de minimiser la consommation de ressources [...] ?

Enfin, les contrats sont souvent des contrats clients : quid des contrats fournisseur ? Jamais abordés, et pourtant, il est indispensable qu’un fournisseur puisse connaître ses clients et maîtrise leurs consommations (parce qu’un SLA — individuel — dépend quand même souvent de la charge — globale).

Bref, il me semble donc que le propos du livre est très académique, et élude les questions difficiles. Mais je ne cherche qu’à être convaincu !

Concernant la définition des caractéristiques d’un Service, il serait bon de citer la référence de Thomas Erl (SOA Principles of Service Design), puisqu’il me semble fort qu’il s’agit de la source de ces 8 aspects que vous comptez explorer dans cette série.