Le long chemin vers la normalisation de l’architecture

Vincent Berdot, Alain Clapaud et Thierry Jacquot

01 Informatique

le 05/12/2007 à 07h00

envoyer
par mail

imprimer
l'article

sommaire

SOA : des architectures pas conçues pour les métiers

Imposer des outils de gouvernance

Découper et calibrer correctement les services

Le long chemin vers la normalisation de larchitecture

Des plates-formes intégrées encore jeunes

Les spécialistes de linfrastructure visent les métiers avec SOA

Les éditeurs de plates-formes cohabitent avec les spécialistes

Yves Caseau (Bouygues Télécom): éditeurs de solutions, adressez-vous mieux au métier

Voir tout sommaire  

Dans ses efforts pour structurer les technologies de services web, l’industrie a peut-être poussé le bouchon un peu loin. Les travaux de standardisation ont en effet conduit à une multiplication de protocoles spécialisés, les protocoles WS-*, surnommés ainsi par le préfixe dont la plupart sont affublés (ws-policy, ws-transaction, ws-security). Cette multiplicité de mécanismes, à laquelle s’est rajoutée une concurrence entre deux écoles “ middleware ”, l’une défendant Soap (Simple Object Access Protocol), l’autre poussant Rest (Representational State Transfer), a compliqué le panorama technologique. Du moins en ce qui concerne les mécanismes de bas niveau. Car, au niveau architectural, des efforts notables d’harmonisation ont été conduits avec l’élaboration des spécifications SCA (Service Component Architecture) et de son pendant, SDO (Service Data Objects). SDO porte sur la spécification des modèles de définition des données impliquées dans les infrastructures SCA. SCA est né d’une initiative menée par un groupe de dix-huit éditeurs. Ce modèle architectural a franchi un cap important au printemps 2007, avec la publication de ses principales spécifications en version 1 et son transfert à l’Oasis (Organization for the Advancement of Structured Information Standards), qui regroupe des acteurs tels IBM, SAP ou BEA. L’un des groupes de travail de cette organisation, Open CSA, étant désormais responsable de son évolution. SCA recouvre un ensemble de spécifications détaillées, relatives à la définition des services et à leur mode d’assemblage.

Au cœur de SCA, deux spécifications : l’une, SCA Assembling Model. Elle décrit les modes d’assemblage (d’une succession de services, par exemple). Elle porte également sur les interconnexions de domaines (des processus métier ou un assemblage de services), de services, ou de simples composants (EJB). L’autre spécification, SCA Policy Framework, formalise des contraintes techniques et des exigences, notamment en matière de qualité de service. Elle se situe donc dans une optique de gouvernance.

Des poids lourds de l’industrie soutiennent SCA

Ces deux documents descriptifs sont complétés par plusieurs spécifications liées à l’implémentation physique de SCA. Elles donnent ainsi des indications sur la manière d’adapter la modélisation effectuée en SCA à une plate-forme Java ou C++. Pour des mécanismes d’invocation de service.

SCA n’est donc pas exclusivement associé aux technologies de services web. Bien évidemment, le document “ web service binding specification ” s’intéresse à la façon d’exposer des services SCA en tant que services web s’appuyant sur Soap et WSDL. Mais d’autres spécifications de couplage avec, entre autres, Java, les EJB, C++, BPEL, sont proposées. Ce travail théorique se poursuit ; une spécification Cobol a ainsi été récemment publiée.

Quel est l’avenir pour des spécifications SCA ? Ce modèle architectural bénéficie de soutiens de poids dans l’industrie comme IBM, BEA, Tibco, SAP et Capgemini. Néanmoins, le travail d’implémentation logicielle n’en est qu’à ses débuts. Tibco est certainement le plus avancé sur ce sujet, avec un atelier d’assemblage de services, Activematrix Service Grid, compatible SCA, tandis qu’IBM et SAP travaillent encore à intégrer SCA, l’un à son serveur d’applications (Websphere), l’autre à son infrastructure logicielle middleware (Netweaver). Le chemin de SCA sera certainement parsemé d’embûches. On oppose couramment SCA à la spécification JBI (Java Business Integration). Mais JBI porte essentiellement sur la façon d’implémenter les conteneurs de services et ESB. Elle apparaît donc complémentaire de SCA.

Reste le cas Microsoft. L’éditeur n’étant pas partie prenante de l’initiative Oasis, on peut légitimement s’interroger sur l’impact de SCA dans le monde .Net propre à l’éditeur américain. Compte tenu de ces réserves, le Gartner Group fait preuve d’un optimisme prudent. Bien que SCA soit perçu comme “ une tentative ambitieuse ”, le cabinet estime que l’offre logicielle de la période 2008-2011 n’offrira qu’une conformité partielle à SCA.

Un aperçu de la hiérarchie des artéfacts SCA

agrandir la photo

Les spécifications SCA proposent un modèle de programmation d’applications composites SOA. Celles du modèle d’assemblage s’intéressent particulièrement à la définition des artefacts (“ domaines ”, “ assemblages ”, etc.) entrant dans la constitution de ces applications ainsi qu’à leurs interdépendances.