Il y a 13 ans -

Temps de lecture 5 minutes

Introduction à SCA (Service Component Architecture)

SCA (Service Componant Architecture)[1] est un ensemble de spécifications visant à simplifier la création et la composition de services (indépendamment de leur implémentation) dans le cadre d’Architectures Orientées Service (SOA).

Cette spécification était jusqu’ici portée par l’OSOA (Open Service Oriented Architecture), également à l’initiative de SDO (Service Data Objects), qui a annoncé le 21 mars dernier la version 1.0 de la spécification et sa soumission à l’OASIS pour standardisation[2].

Au-delà des guerres de clochers[3] autour de SCA, cette double annonce est l’occasion de revenir sur cette spécification.

SCA propose donc un modèle de programmation pour la construction d’applications à base de composants suivant le paradigme SOA. Ce modèle se base notamment sur l’idée qu’un service de niveau N se construit par assemblage / agrégation / orchestration de services de niveau N-1 ou N (Et ce quelque soit la hiérarchisation choisie. Par exemple : Services organisationnels, Services métiers, Services techniques).

A ce titre, SCA fournit deux niveaux de modèle :

  • Un modèle d’implémentation : Construire des composants qui fournissent et consomment des services ;
  • Un modèle d’assemblage : Construire une application métier à forte valeur ajoutée en liant entre eux un ensemble de composants.

Ainsi, SCA insiste sur une séparation forte entre l’implémentation des services et leur assemblage.Le modèle SCA se veut agnostique vis-à-vis :

  • Des technologies d’implémentation des composants de service. Il inclut entre autre les technologies d’implémentation suivantes : Java, C++, BPEL, XQuery ou SQL.
  • Des technologies d’exposition et d’invocation des composants de services (même si WSDL et les interfaces java sont mis en avant).

SCA permet de décrire des services et leur assemblage indépendamment de toutes considérations techniques d’implémentation.

Composants et services : Le modèle d’implémentation

L’élément de base de SCA est le composant qui constitue l’unité élémentaire de construction.

Un composant est une instance configurée d’implémentation où une implémentation est un code source fournissant des fonctionnalités.

Composant SCA

Ces fonctionnalités sont exposées en tant que services en vue de leur utilisation par d’autre composant. Les services sont décrits au travers d’interfaces qui constituent le contrat de service. Ces contrats sont implémentés par le composant.

Les paramètres des services sont des structures de données pour lesquelles SCA recommande fortement l’utilisation de la spécification SDO (Service Data Objects) dont il est également l’instigateur.

L’implémentation peut s’appuyer sur des services fournis par d’autres composants dont elle dépend. Ces dépendances sont appelés références. Elles sont associées à des services qui peuvent être soit exposés par d’autre composants SCA soit exposé par des systèmes tiers (Web services, connecteurs JCA, …).

L’implémentation peut être paramétrable au travers de propriétés qui influencent le comportement d’une fonctionnalité. C’est le composant qui configure l’implémentation en fournissant des valeurs à ses propriétés et en liant les références aux services fournis par d’autres composants.
Le système de références associé à celui des interfaces permet de réaliser un couplage lâche (ou faible) entre les composants : Un composant consommateur de services ne connaît des composants fournisseurs de services sur lesquelles il s’appuie que les interfaces (contrat de service) des services qu’il consomme.

Composition et domaines : Le modèle d’assemblage

Le deuxième élément définit par SCA est le composé qui est un assemblage de composants, services, références, propriétés et des liens qui existent entre ces éléments.

Un composé n’est donc rien d’autre qu’un composant de plus haut niveau que ceux qui le compose (Il fournit des services, dépends de références et a des propriétés). Un composé peut donc à son tour être référencé par d’autres composants et utilisé au sein d’autres composés.

L’utilisation première du composé peut être « détournée » pour regrouper un ensemble d’éléments non nécessairement liés mais qui constitue un ensemble fonctionnel cohérent.

Au plus haut niveau, les composés sont déployés dans des domaines SCA qui regroupe l’ensemble des services pour un système fonctionnel.

Perspectives

SCA vise l’implémentation de services de haut niveau à forte valeur ajoutée (Services métier et organisationnels). De tels mécanismes seraient en effet coûteux pour des services purement techniques (que l’on se contentera de référencer pour les utiliser dans les composants).

Comme c’est souvent le cas, la spécification est déjà implémentée depuis longtemps par les éditeurs à son origine au sein de leurs produits estampillés SOA, notamment par IBM.

Du côté de l’open source, on notera le projet Tuscany[4] de la fondation Apache qui vise à fournir un environnement d’exécution SCA. Pour ce qui est des outils de conception / développement, on retiendra le projet Eclipse STP[5] (SOA Tools Platform) qui se base sur les modèles SCA.


[1] La spécification est disponible sur le site de l’OSOA [en].
[2] Le communiqué de presse chez Oracle : Open SOA Collaboration Chooses OASIS to Advance SCA and SDO Specifications [en].
[3] SCA avait été poussé par IBM et Oracle, rapidement rejoints par BEA et d’autres, mais sans Sun. Pour en savoir plus : SCA/SDO go to OASIS [en] sur InfoQ et JBI and SCA Are Complimentary! [en] sur le blog de Bruce Snyder.
[4] ApacheTuscany Project [en].
[5] SOA Tools Platform Project [en].

Commentaire

11 réponses pour " Introduction à SCA (Service Component Architecture) "

  1. Publié par , Il y a 13 ans

    excllent article, cependant j’ai du mal à mesurer l’ampleur de cette technologie quant à son utilisation dans des projets de grande envergure.

  2. Publié par , Il y a 13 ans

    1- How abstract assembly of component described ?

    2- Assembly of components is it supervised, and how ?

    3- The deployment domain is it modeled and the deployment plan is it
    automatically generated ?

    4- Package activation/deactivation and installation/Deinstallation are they
    automatic ?

  3. Publié par , Il y a 12 ans

    (Mieux vaut tard que jamais)

    Très bon article, je pense qu’il résume simplement et efficacement ce qu’est SCA.

    Je tiens juste à rajouter un item à la liste des implémentations SCA: FraSCAti est un runtime SCA développé dans le cadre du projet de recherche public SCorWare. Plus d’infos à ce sujet sur le site http://www.scorware.org.

    Au passage, j’en profite pour signaler qu’à l’heure actuelle, SCA semble être la technologie la plus conforme et la plus adaptée pour le développement d’applications dans un contexte SOA.
    Seule manque à SCA pour l’instant une success story qui prouverait que malgré sa simplicité, elle est un vecteur de succès dans un système d’information bâti sur SOA.

    Cordialement,
    Mickael Istria

  4. Publié par , Il y a 12 ans

    SCA est un très bon modèle d’integration pour les composantes bussiness .
    Cette techno est très récente.
    Ce qui manque :
    – c’est de la bonne documentation
    – le manque des implémentations open source de SCA est l’un des facteurs qui l’empêche de prendre la place qu’elle mérite en tant que modéle.

    Les implémentations Open Source ( Fabric3 , Tuscany , newton) sont dans leurs premières versions stable vue que la spécification est très récente.

  5. Publié par , Il y a 12 ans

    Excellent article,

    L’année précedente a était marquée par OSGi coté serveur, avec GlassFish V3 de Sun et le TC Server de Spring.
    J’espère que cette année on aura de bonnes nouvelles cote Spring : non pas un serveur léger mais un serveur SCA avec du Spring remoting (httpinvoke).
    Je crois de la piste est ouverte pour passer en SCA en production pour 2009.

  6. Publié par , Il y a 12 ans

    excellant article!mais je suis débutante dans ce domaine donc j’arriva pas à voir la différence entre SOA,SCA et SDO.je serais tres reconnaisante si vous repondiez à ma question.
    merci d’avance.

  7. Publié par , Il y a 11 ans

    Eccellent article,

    il n’y a pas une différence entre SOA,SCA et SDO car par exemple SCA propose « un modèle de composants » permettant de construire une architecture SOA

  8. Publié par , Il y a 11 ans

    SOA est un modèle architectural (PAS une technologie)
    SCA est une technologie qui permet d’implémenté des services au sens SOA. Il y a d’autres techno pour implémenter les services au sens SOA comme JBI

Les commentaires sont fermés.

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.