Semaine 8.2 Flashcards
Qu’est-ce que SCA?
Service Component Architecture (SCA) : un standard de OASIS
- Créé en 2007 par Mark Edwards
- Dernière mise à jour en 2011
Service Component Architecture (SCA) est un ensemble de spécifications qui décrivent un modèle pour la construction d’applications et de systèmes à l’aide d’une architecture orientée vers le service (SOA)
SCA étend et complète les approches antérieures à la mise en oeuvre des services, et s’appuie sur des normes ouvertes telles que les services Web
SCA est basé sur l’idée que les fonctions d’une entreprise peuvent être livrées comme une série de services, qui sont assemblés pour créer des solutions qui servent un besoin particulier d’entreprise. Ces solutions sont appelées applications composites.
Ces applications composites peuvent contenir à la fois de nouveaux services créés spécifiquement pour l’application et aussi d’autres services d’applications existants, réutilisés dans le cadre de la composition.
SCA fournit un modèle pour :
- La composition des services
- La création de composants de services, y compris la réutilisation de la fonction d’application existante dans les compositions SCA
- SCA vise à englober un large éventail de technologies pour les composants de service et pour les méthodes d’accès qui sont utilisées pour les connecter
Selon SCA :
- Toutes les ressources d’une entreprise - services Web, système d’information d’entreprise (EIS), flux de travail, bases de données, etc. - sont présentées de façon axée sur le service, avec une interface de service
Qu’est-ce qu’un “service component”?
“A service component configures a service implementation. A service component is presented in a standard block diagram. A component consists of an implementation and one or more interfaces, which defines its inputs, outputs, and faults, and also its references, if applicable.”
Les composants sont sujets de “wiring” ensemble pour former une application compositeé
- Basé sur interface de service et leurs dépendances
Le déploiement des composites groupés est plus facile et plus efficace que ne le serait le déploiement de chaque composant individuel
SCA ne fournit pas de interopérabilité d’applications composites entre les conteneurs SCA. (par exemple pour migrer Oracle SOA - Apache Toscany ou WebSphere)
- SCA => interopérabilité améliorée mais pas garantie
Quel est le but principal de SCA?
SCA vise à séparer la logique d’intégration de l’entreprise de l’implémentation :
- Développeur d’intégration se concentre sur l’assemblage d’une application composite intégrant des composants
- Les spécialistes créent les composants de services en utilisant, par exemple, BPEL, Java ou Business Rules ou n’importe quelle technologie de composant est le mieux adapté pour le travail
Qu’est-ce que SCA en bref?
Service Component Architecture (SCA) : est une norme qui prescrit une approche structurée pour composer des applications à partir de composants de services
Les applications composites (service composite) sont les unités fonctionnelles réutilisables qui fournissent des fonctionnalités d’entreprise significatives, sous forme de services
Les composants de services (service component) : des éléments de logique d’entreprise qui forment les éléments consitutifs des applications composites
Qu’est-ce que l’assemblage des composants selon SCA?
Une spécification selon la norme SCA décrit :
- Composants, leur assemblage en applications composites, et leurs dépendances mutuelles et leur interaction
– Par une série de fichiers XML, créés au moment de la conception et interprétés par le conteneur SCA au moment de l’exécution
Quels sont les éléments de base de SCA?
Service : comment l’application composite est exposée (interface, protocole binding)
References : autres services desquels depend l’application composite
Composants : un composant fournit l’implémentation de service(s) (interface, binding and endpoint)
Wires : comment les composants communiquent entres eux et aux interfaces des services externes
Qu’est-ce que le fichier Composite.xml?
Le fichier composite.xml :
- Décrit l’application composite dans son ensemble, en termes de ces éléments
- Il référence les autres fichiers directement ou indirectement
- Un conteneur SCA, comme la suite SOA de WebLogic/JDeveloper, interprétera d’abord ce fichier au moment du déploiement
Chaque composant est décrit dans le fichier composite.xml fournissant :
- La définition de composant contient un élément componentType qui spécifie le service(s) exposé(s) par le composant, par le biais de références à “interface” dans les documents WSDL ou alternativement avec des références aux interfaces Java.
- Un nom + une implémentation qui fait référence :
– À un moteur de composant de service tel que BPEL (ou médiateur)
– À un fichier d’implémentation ou au programme qui devrait être exécuté par le moteur
Quel est le lien entre service et application composite?
Les composants ne peuvent pas exister isolés dans l’environnement d’exécution SCA
- Ils doivent faire partie d’un composite de service (application) parce que c’est l’unité de déploiement et d’invocation
- Habituellement, un composite contiendra un ou plusieurs composants
- Les composites sont décrits à travers le fichier composite.xml selon la norme SCA, qui est rendu dans JDeveloper dans l’éditeur composite visuel. Ce fichier composite.xml comprend les entrées pour les composants service et les “wires” entre ces composants
Une application composite expose habituellement au moins un service, avec une interface publique pour les consommateurs du composite
Notez qu’une application composite pourrait avoir comme seule “interface” un composant qui consomme un événement
- Pas d’interface de service public explicite que les consommateurs externes devraient invoquer
Nomme des précisions concernant SCA.
Plusieurs services contenant plusieurs opérations peuvent être publiés par une seule application composite
Un service public exposé par une application composite est un service publié par l’un des composants de service à l’intérieur du composite qui a été promu au niveau composite
Les services d’adaptateur entrant forment un cas spécifique de la suite SOA
- Les adaptateurs fournissent des points d’entrée dans les applications composites SOA (exemple adaptateur Restful - WSDL)
Quelle est la différence entre SCA et ESB (bus de service)?
ESB permet principalement :
- Validation-contrat, SLA, contrôle d’accès aux services
- Transformer (XSLT ou XQuery) des messages pour permettre un échange plus flexible entre services à différentes technologies d’implémentation
- Contrôle sur le déploiement, l’usage et la maintenance
SCA vs ESB :
- Bien d’éléments communs
- ESB offre plus :
– De performance pour un flux rapide de message, plus fiable pour la maintenance et déploiement
– Validation de contrat et accès
- SCA offre plus pour :
– Requêtes asynchrones et transaction de longue durée (human tasks)
– Expressivité plus riche d’actions avec le duo SCA et BPEL
Une pratique promue pour le meilleur des deux mondes :
- Toutes les applications composites décrites selon SCA enregistrées à, et accessible via, un ESB