Autour de SOA, je vous propose un résumé aujourd’hui de la spécification SCA (Service Component Architecture) ainsi que quelques liens vers des projets intéressants autour de SCA et SDO…
SCA signifie Service Component Architecture. Il s’agit d’une spécification (en ligne ici) qui vise à promouvoir un système découplant l’implémentation de l’assemblage des services. SCA est indépendant du langage. Une architecture de service basée sur des composants permet de fournir un service définit par un ensemble d’interfaces. Des proprietés de données permettent aussi de définir des attributs globaux pour plusieurs services. Par exemple la langue ou la monnaie de l’utilisateur. Un composant SCA est une brique logicielle qui est assemblée dynamiquement par un moteur. Elle utilise un service en entrée et fait appel via des références à d’autres services. Des attributs (les properties ) permettent de configurer le contexte du SCA globalelement. Imaginez un component de type GestionCompte. Celui-ci configure une implémentation GestionCompteImpl, branche des références vers les services CompteDataService et CotationDevisesService. De plus une proprieté « Monnaie » est mise à EURO pour que le compte soit géré en euro.
Un composant SCA est un assemblage dynamique de plusieurs services autour d’un code de base, l’implémentation de références. En s’inspirant de l’injection de contrôle type Spring, SCA permet à un moteur externe de brancher les références des services dynamiquement. Il n’est donc pas de la responsabilité du programmeur qui écrit le component de se lancer dans l’écriture de ServicesLocator par exemple. L’injection s’applique aussi aux properties (la monnaie « EURO »).
Concernant la couche de transport, celle-ci est invisible pour le component SCA. Ce qui permet donc d’utiliser des web-services pour discuter avec d’autres services, mais aussi JMS, Corba ou des appels locaux. C’est un gain de souplesse et d’évolutivité.
Par rapport à Java, SCA supportera des objets simples (POJO). Une implémentation basée sur des EJB sera aussi possible ainsi qu’une implémenation BPEL (OASIS WS-BPEL standard).
Les components SCA sont déployés au sein de ce que la spéc appelle des « Module Assembly ». Les « Entry Points » sont les portes d’entrées du module qui contient un ou plusieurs composants SCA. Lorsque les composants SCA nécessitent des services externes, ceux-ci sont appelés « ExternalServices ». Plusieurs Modules sont regroupés par sous-système pour former une Application.
Le Binding est le système qui permet de brancher et d’assurer la couche transport d’une architecture SCA. Un des postulats de départ est de séparer la partie business logic de la partie transport. SCA supporte les Web Services, JMS, StatelessSession Bean ou encore des procédures stoquées en base. Par rapport aux échanges entre service, l’architecture SCA permet des échanges asynchrones de type « one-way » comme pour envoyer un message, de type callback et de type conversational. La gestion d’une conversation est par exemple une demande de crédit pour notre service bancaire. Plusieurs étapes dans l’échange de message seront nécessaire pour obtenir un résultat.
Pour résumer, les caractéristiques de SCA sont les suivantes:
- la logique d’une application est divisée en composant implémentant des services métiers
- un composant dispose d’intérface orientées métiers et services. Il n’a pas d’intérfaces
liés au middle-ware - les composants peuvent être branchés entre eux pour les réutiliser. Cette capacité d’assemblage d’une architecture SCA permet de créer un réseau de services réutilisables
- SCA force une séparation entre les besoins de la personne qui implémente un composant de celle qui assure l’assemblage système des composants.
- SCA peut être implémenté par dessus un grand nombre d’environement middleware.
- Les composants sont implémentés et utilisés de la même manière quelque soit le language ou la technologie utilisée.
- SCA permet une qualité de service en s’assurant que le support des transactions, de la securité et des messages asynchrones est appliqué de manière déclarative et dynamique sans que la programmation
d’un service force l’écriture ou l’implémentation de briques systèmes. C’est un principe aussi repris par les EJB3. - Que le composant soit déployé localement ou à distance, il est accedé via ses interfaces métiers. L’assemblage de composants peut s’effectuer à différents niveaux pour permettre une plus grande flexibilité et une meilleure visibilité des composants.
- Une varieté de ressources comme les Web Services, les EJB’s ou les EIS peuvent être modélisés comme des composants distants et utilisés sans avoir connaissance de l’implémentation ou de la couche transport. Cependant certains types de transport restreignent les possibilités de qualité de service supportées.
- SCA supporte différentes technologies pour exprimer les interfaces métiers des composants, que ce soit WSDL ou des interfaces Java.
- Des composants sans interface métiers peuvent être utilisé pour permettre l’accès aux données, en séparant le problème de la persistence des données de la logique métier. Cela facilite aussi le portage de composants entre différents runtimes.
- Les capacités d’infrastructure comme la sécurité et les transactions sont appliqués sur les interactions entre les components (ProxyPattern) plutôt que d’utiliser du code dans le composant. C’est une idée que l’architecture JEMS de JBoss a mis en place avec succès depuis 2 ans déjà. Cela permet de bien séparer la partie métier de la partie infrastructure.
- Les composants applicatifs peuvent être reprogrammés à la volée en déleguant à des composants de type « StrategyPattern » certains traitements. C’est un pas vers les moteurs de Workflow ou les rules engines.
- SCA définit un modèle abstrait pour l’implémentation et un modèle pour l’accès au composant. Le modèle est découplé en différentes implémentations concretes dans une grande varieté de language comme JAVA, C++, BPEL ou des scripts XSLT. SCA essaye d’être intrusif au minimum avec seulement quelques APIs. L’injection des dépendances permet à un composant SCA de ne pas dépendre d’API externe pour retrouver d’autres composants.
- Les objets échangés entre différents composants via des interfaces métiers distantes est définit dans la spécification Service Data Object (SDO)
Sur apache.org le projet Tuscany a été créé pour regrouper 5 projets destinés à fournir une architecture type SOA:
- 1. SCA Runtime for Java (service component architecture)
- 2. SDO 2.0 Runtime for Java
- 3. Data Access Service for Java
- 4. SCA Runtime for C++
- 5. SDO 2.0 Runtime for C+
Tuscany(en français la Toscane en italie) est vraiment au tout début. Pour récuperer l’implémentation de référence il faut la charger via Subversion.
Un exemple commenté d’application basée sur SCA est disponible: http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-sca/SCA_BuildingYourFirstApplication_V09.pdf
La sortie des EJB3 pour Java va permettre une intégration facile de cette architecture. La gestion de la persistence et l’injection de dépendances sont 2 mécanismes puissants dors et déjà disponible avec
la spécification des EJB3 pour Java. Les Sessions Beans simplifiés des EJB3 peuvent servir naturellement de composant (les components dont j’ai parlé au début) comme brique de base. Il est possible
d’injecter des dépendances simplement grâce aux annotations dans un EJB3. Tout ceci fait que SCA + EJB3 semble naturel et plus facile à mettre en place.
En conclusion, SCA est donc une spécification d’architecture qui vise à faciliter l’écriture de composants métiers pour les intégrer dans un containeur global.
Pour terminer, lors de la lecture de la spéc, je suis tombé sur un nouveau barbarisme. Après POJO (plain old java object) j’ai vu dans la section 5.6.1 le mot POX qui signifie Plain Old XML… on arrête pas le progrès.
0 no like
