Mois : décembre 2006

Rappelons que les Architectures Orientées Service (SOA) proposent que les applications du SI soient conçues dans l’idée de :

• Présenter leurs fonctions sous une forme facilement invocable par les autres applications du SI ;
• Donner un accès à leur référentiel de données ;
• Permettre d’appeler leurs traitements en respectant leur découpage métier, et donc faciliter leur intégration dans des processus métiers ;
• Permettre de combiner plusieurs fonctions, issues de plusieurs blocs applicatifs afin de créer des « applications composites ».

Pour en savoir plus, je vous recommande la lecture de « SOA, le guide de l’architecte ».

Dans le monde informatique, comme dans le monde réel, mettre des services à disposition de tiers sous entend un engagement sur la qualité de ces services.
Ainsi, en architecture SOA, il sera nécessaire d’offrir :

• Un mode d’emploi pour l’invocation du service, ou contrat d’intégration. Ce contrat se concrétisera par la publication dans un registre UDDI d’un fichier WSDL ;
• Les contraintes qu’impose ce service pour assurer le respect de sa politique de sécurité. Ces contraintes seront décrites dans le registre UDDI par un fichier WS-SecurityPolicy ;
• Les engagements que prend ce service en matière de disponibilité (on parle souvent pour cela de SLA, Service Level Agreement). Ces engagements seront décrits dans le registre UDDI par un fichier WS-Policy. Ils pourront être complétés par une description de leurs performances réelles : cette dernière pourra être remontée par des outils comme ceux d’Amberpoint, qui scrutent les services et peuvent faire du reporting sur leur disponibilité.
• Les engagements que prend ce service en matière de confidentialité des données : Ces engagements seront décrits dans le registre UDDI par un fichier WS-Privacy (cette norme est encore très immature).

Cette énumération montre qu’un contrat de service prend de multiples aspects, que l’on peine à adresser aujourd’hui de manière exhaustive. En effet, les normes et pratiques sont encore assez immatures. En particulier, il n’existe pas de pratique pour assurer la réversibilité d’un service, c’est-à-dire la capacité à le remplacer par un autre équivalent sans trop de difficulté (cf. ce billet).

Il est clair, à mon sens, que ces normes et pratiques devront mûrir pour faciliter :

• Le recours à des services hébergés chez des partenaires, comme le suggère la vague Web 2.0 ;
• Des accords rigoureux entre maîtrise d’œuvre et maîtrise d’ouvrage autour des services d’entreprise.

Par ailleurs, une évolution des registres UDDI est souhaitable afin de permettre la consultation de leurs contenus sous une forme accessible à des maîtrises d’ouvrage.