Présentation de l'architecture SCA 

ACME/ ACME Studio

ADL wright et CSP

Introduction

• Les systèmes informatiques ont connu une croissance 

exponentielle.

• Des architectures logicielles plus complexes à gérer.

       L'industrie du logiciel est passé par plusieurs architectures informatique.

       Cependant, la solution complète continue être insaisissable.

       

Solution : les architectures orientées services (SOA)

SOA : Pourquoi?

La croissance des systèmes informatiques a causé des problèmes que les architectures traditionnelles n'ont pas résolu. 

• Problème 1: Complexité

• Problème 2: Redondance et programmation non réutilisables

• Problème 3: Interfaces multiples

Problème 1: Complexité

• Plusieurs contraintes impose la réutilisation des systèmes existants plutôt que de les remplacer.
• Les solutions point à point agrandisse le problème, et ne pouvant jamais prendre le défi car toute information, organisations, applications et infrastructures doivent être intégrés.
• Donc la nécessité de développer des systèmes qui intègrent l'hétérogénéité comme une partie fondamentale de l'environnement informatique, de sorte qu'ils peuvent accueillir une variété infinie de matériel, systèmes d'exploitation, middleware, langages de programmations et des outils de stockages de données. 

        Un accès universel et peut coûteux à l'Internet a créé la possibilité de toute nouveaux
modèles d'affaires.

Problème 2: Redondance

et programmation non réutilisables

• Le nombre d'applications peuvent avoir augmenté en raison des fusions et acquisitions.
• Par conséquent, on peut avoir affaire à des applications redondante ou des applications avec des fonction qui ne peuvent pas facilement être réutilisés.
• Cette redondance augmente le coût et le temps pour le marché de deployment de nouveaux produits ou services, a cause des changements à effectuer dans chaque application ou dans un système affecté. Ce manque de réutilisation exige finalement plus de ressources - et souvent plus de temps - pour offrir de nouvelles applications.

Problème 3: Interfaces multiples

Solution !

•  SOA(Service oriented architecture) est un principe d'architecture pour permettre logicielles d'être exposées en tant que services.
• Avantages : réutilisation, facilité de gestion et adaptabilité
• Ne décrit pas la façon dont les services seront emballés ou assemblés
•  SCA peut accélérer l'adoption de SOA en utilisant le modèle SCA  pour définir comment les services peuvent être déclarer, mis en oeuvre et reliés les uns aux autres.
• Le bloc de construction de base pour SCA est un composant SCA,

      qui peut être utilisé pour décrire les services exposés, et
      déclarer la dépendance à d'autres services en tant que                         références.

 

Services component architecture

SCA a commencé comme une collaboration entre plusieurs fournisseurs sous la direction de Open SOA group.

SCA a maintenant déménagé au corps de OASIS

(http: //www.oasis-opencsa.org/sca) qui a maintenant repris son future développement.

A component consists of a configured instance of a piece of code providing business functions.

It offers its functions through service-oriented interfaces and may require functions offered by other components through service-oriented interfaces as well.

Independent of whatever technology is used, every component relies on a common set of abstractions including services, references, properties and bindings.

4 Concepts clé

Service

Composant

Domaine

Composite

SCA

Service : les applications sont organisées en un ensemble de services qui effectuent des tâches particulières telles que l'acceptation d'une demande de prêt, d'effectuer une vérification de crédit, ou l'exécution d'une recherche d'inventaire.
Dans SCA, un service a deux caractéristiques principales: un contrat et une adresse.

Un contrat de service spécifie l'ensemble des opérations disponibles à un client, les exigences pour les entrées et les garanties pour les sorties.

Les adresses de services sont essentiels à la réutilisation: Ils fournissent un moyen pour les clients pour identifier de manière unique et se connecter à la logique applicative.

Composant : Dans SCA, un composant est  un code configuré  qui fournit un ou plusieurs service. Un client se connecte à un service via une adresse et invoque
un ou plusieurs opérations.

• Les propriétés : définissent les manières dont un composant peut être configuré.
• Une référence : est une dépendance de

      d'un autre service, où le composant se             connecte lors de son exécution.

• Implementation : représente des caractéristiques de la mise en œuvre, les intentions et les politiques particulières.

Un composite est utilisé pour assembler des éléments SCA dans des regroupements logiques. Il est l'unité de base de la composition au sein d'un domaine SCA. Un composite SCA contient un ensemble de composants, services, références et les wires qui les relient, en plus un ensemble de propriétés qui peuvent être utilisées pour configurer les composants.

Un wire est un canal de communication entre le composant client

et le service cible.

Dans le cas où des composants sont alloués, le domaine doit connecter les wires entre eux. Lorsque deux des composants sont distant, le domaine doit établir un canal de communication entre ces deux.

Dans SCA, les bindings sont utilisées pour configurer les communications dans et en dehors d'un domaine. Les liaisons sont affectés aux services et références d'un composant dans un fichier composite. Par exemple, pour exposer un service à des clients externes, le binding est utilisé.

Domain : Un domaine SCA représente une configuration d'exécution complet, éventuellement répartis sur une série de noeuds interconnectés. Un seul domaine SCA définit la limite de visibilité pour tous les mécanismes de SCA.

En général, les clients externes d'un service qui est développé et déployé en utilisant SCA ne sont pas en mesure de dire que SCA est utilisé pour mettre en œuvre le service - il est un détail d'implimentation.

Notion de contract

• Formaliser les relations conceptuelles fortes (client et héritage) entre les classes, Bertrand Meyer a introduit le paradigme de la conception par contrat (Design by Contract)
• Le développement de la notion de composant logiciel a offert une opportunité d’appliquer cette vision contractuelle afin de vérifier la cohérence d’un assemblage de composants.

Les contrats syntaxiques

Les contrats syntaxiques permettent de vérifier la conformité entre les signatures des opérations des interfaces. La signature d’une opération peut comporter les éléments suivants :

• nature de l’opération : opération de construction, consultation ou modification
• paramètres formels : pour chaque paramètre, trois informations à prendre en considération à savoir son type, sa position et sa nature logique (in, out et in/out)
• exceptions

Les contrats sémantiques

La sémantique d’une opération offerte/requise figurant au sein d’une interface offerte/requise peut être décrite en utilisant la conception par contrat : précondition, postcondition et invariant.

Les contrats de synchronisation

Les contrats de synchronisation s’intéressent à l’enchaînement des opérations acceptées et/ou demandées. Ces contrats peuvent être décrits en utilisant des formalismes à base d’algèbres de processus, IOLTS (Input Output Labeled Transition Systems) et PSM (Protocol State Machine).

Les contrats de qualité de services

Les contrats de qualité de services permettent de décrire les propriétés non fonctionnelles souhaitées ou offertes par une opération, une interface ou un composant. Sachant qu’une
propriété non fonctionnelle (PNF) d’une entité logicielle est une contrainte liée à l’implémentation et la présentation de ses fonctionnalités [Taylor, 2009]. Parmi les PNF, nous citons : performance, sûreté, disponibilité, fiabilité, complexité,

ré-utilisabilité,extensibilité, etc.

Acme

• Le projet Acme a commencé au début de 1995
• But : fournir un langage commun qui pourrait être utilisé pour Soutenir l'échange de descriptions architecturales entre une variété d'outils de conception.

      Nouvelles conception et analyse des architectures logicielles peuvent être construit sans la nécessité de reconstruire l'infrastructure standard.

Acme : vue globale 

Acme est construit sur une ontologie de sept types d'entités représentant l'architecture: composants, connecteurs, systèmes, ports, rôles, représentations et "rep-maps". Sur les sept types, les éléments les plus fondamentaux de la description architecturale sont les composants, les connecteurs et les systèmes.

 

Composants : Les composants sont les blocs de construction de base dans une description Acme. Ils représentent les centres de calcul: les éléments d'un système chargés de faire le «travail» dans un système. Les composants peuvent être utilisés pour modéliser le matériel et le logiciel ou fournir une abstraction qui peut être mappé sur un matériel, un logiciel ou une combinaison.

Connecteurs : les connecteurs capture la nature de l'interaction entre les composants. Comme les composants, les connecteurs peuvent être utilisés pour modéliser une variété de différents types d'interactions. Un connecteur typique pourrait définir un modèle de synchronisation pour la communication, un protocole de communication, un modèle de verrouillage, ou les caractéristiques d'un canal de communication comme la bande passante.

 

Systèmes : Une description d'un système Acme est assemblé à partir d'un ensemble de composants et connecteurs, décrivant les éléments du système et comment ils interagissent.

ACME Studio

AcmeStudio est un environnement d'édition personnalisable et un outil de visualisation pour les logiciels de conceptions d'architecture basé sur le langage de description d'architecture Acme (ADL).

Avec Acme Studio, vous pouvez définir de nouvelles familles Acme et personnaliser l'environnement de travailler avec ces familles en définissant des styles de diagramme.

AcmeStudio est adaptable et peut être utilisé dans une variété d'applications de modélisation et d'analyse.

AcmeStudio est implémenté comme un plug-in pour l'environnement Eclipse.

The Wright Architecture Description Language

• Wright aborde cette question en fournissant une base formelle pour la description architecturale. En tant que langage de description d'architecture, Wright peut être utilisé pour fournir une signification abstraite à une spécification d'architecture et d'analyser à la fois l'architecture de systèmes logiciels individuels et des familles de systèmes.

 

• Wright sert également pour l'exploration de la nature des abstractions architecturales elles-mêmes. En particulier, le travail sur Wright a mis l'accent sur le concept de types de connecteurs explicites, sur l'utilisation de la vérification automatique des propriétés architecturales, et sur la formalisation des styles architecturaux.

La structure de l'ADL WRIGHT

Comme un langage de description architecturale, WRIGHT est construit autour de l'architecture de base abstractions des composants, des connecteurs et des configurations.

WRIGHT fournit des notations explicite pour chacun de ces éléments, formalisant les notions générales du composant et du connecteur comme modèle d'interaction.

       Instances

       Attachments

       Hierarchy

Au niveau supérieur, le système se compose de deux éléments, un client et un serveur. Le serveur est réalisé par un sous-architecture composée de trois éléments: un coordinateur, qui fournit l'interface de service, un gestionnaire de sécurité, et une base de données.

Spécification du Comportement

Wright permet de spécifier la structure d'une architecture, décrire une famille de structures similaires. Mais comment on peut specifier le comportement des éléments.

Le comportement et la coordination des composants est spécifié dans WRIGHT en utilisant une notation basé sur CSP [Hoa85]. CSP est une notation pour spécifier des modèles de comportement et d'interaction.

Communicating Sequential Processes CSP

Events : L'unité de base d'une spécification comportementale CSP est un événement. Un événement représente une action importante. Par exemple, l'événement "write" représente la fourniture de données par la source. Le même événement peut se produire plusieurs fois dans un comportement complet. Par exemple, la source peut écrire (événement write) des données à plusieurs reprises.

Processes : Tenant en compte l'élément de base du comportement, l'événement, il est possible de construire des modèles de comportement ou de processus. Les processus sont décrits par combinaison d'événements et d'autres processus plus simples. Le processus le plus simple est STOP, le processus qui ne fait rien. 

[1] Migrating to a service-oriented architecture by Kishore Channabasavaiah and Kerrie Holley, IBM Global Services, and Edward         M.Tuggle, Jr., IBM Software Group, April 2004

[2] Encyclopedia of Database Systems, Ling Liu, M. Tamer O ̈zsu (Eds.) volume 1, A - Da

[3] GENERIC MONITORING AND RECONFIGURATION FOR SERVICE-BASED APPLICATIONS IN THE CLOUD, PHD THESIS, 7 Novembre       2014 These de doctorat de Institut Mines-Telecom, Telecom Sud Paris dans le cadre de l’école doctorale S&I en co-accreditation                 avec l’Universite d’ Evry-Val d’Essonne(specialite informatique) par Mohamed Mohamed

[4] Service Component Architecture Assembly Model Specification Version 1.1 Committee Draft 03 / Public Review Draft 01 10 March       2009

[5] Understanding SCA (Service Component Architecture), Jim Marino, Michael Rowley, July 2009

[6] Vérification des propriétés structurelles et non fonctionnelles d’assemblages de composants UML2.0 Mourad Kmimech,                   Mohamed Tahar Bhiri, Mohamed Graiet, Philippe Aniorté

[7] Vérification d’assemblages de composants logiciels : Application aux modèles de composants UML2.0 et Ugatze, Mourad Kmimech

[8] Modeling a System with Acme, Andrew Kompanek, ABLE Group, School of Computer Science, Carnegie Mellon University

[9] http://acme.able.cs.cmu.edu/docs/language_overview, Last Published: Wed Mar 21 16:57:26 EDT 2007

[10] A Formal Approach to Software Architecture, Robert J. Allen, May 1997, CMU-CS-97-144, School of Computer Science, Carnegie           Mellon University, Pittsburgh, PA 15213