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 coeur 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.

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.