Vers une meilleure compréhension de la différence - LIRIS
Contents
1. Vers une meilleure compr hension de la diff rence th orique entre un composant et un service Anthony Hock koon Mourad Oussalah Laboratoire LINA CNRS UMR 6241 Universit de Nantes B t 11 2 rue de la Houssini re B P 92208 44322 Nantes Cedex 03 anthony hock koon univ nantes fr mourad oussalah univ nantes fr RESUME Une distinction claire et suffisamment consensuelle entre objet et composant fut longue a se dessiner Ainsi l apparition du paradigme service a amen naturellement la communaut de l ing nierie logicielle s interroger sur ses limites En effet service et composant partagent de nombreux points communs et la fronti re entre leurs sp cificit s et leurs apports respectifs restent assez flou Dans cet article nous essayons de faire un premier travail de s paration en proposant un cadre de comparaison bas sur un triptyque produit processus et qualit ABSTRACT The distinction between Objects and Components is well known but the distinction between Components and Services is much less clear Therefore we define the Product Process Quality framework which intends to provide a clear understanding of the differences between Component based software engineering CBSE and Service Oriented software engineering SOSE Moreover this framework handles the Object orientation OO to provide a global point of view of these three styles of software engineering MOTS CL S Objet Composant Serv2. adaptabilit et l agilit alors que le CBSE a une vocation plus g n rale Dans CRN 06 les auteurs d finissent le CBSE par les mots cl s composabilit et r utilisabilit Nous d finissons le SOSE par la composabilit la r utilisabilit et la dynamicit 3 Les aspects quantitatifs Cette section classifie les l ments structurels et les m canismes qui caract risent le CBSE et le SOSE Nous ne cherchons pas tre exhaustifs mais plut t mettre en vidence leurs diff rences par une liste pertinente des concepts centraux Ces concepts sont r pertori s dans les cat gories produits et processus 3 1 Produits et processus Un produit est une entit logicielle ou conceptuelle qui est le r sultat d une action ou d un processus Un processus est une action ou une succession d actions qui est utilis e pour cr er ou modifier un produit et ainsi obtenir un produit en r sultat Les produits sont r partis en deux sous cat gories l ments architecturaux simples les briques l mentaires de construction d un paradigme l ments architecturaux composites les produits complexes construits partir d l ments architecturaux existants Leur structure identifie clairement les l ments architecturaux r utilis s et leurs relations Chaque sous cat gorie est son tour divis e en deux groupes suivant les deux niveaux d abstraction le design time et le runtime La cat gorie d
3. tre capable de g rer de multiples con nexions parall les Ce principe n est pas n cessaire un composant En effet bien que pouvant appartenir de multiples compositions au niveau de l ex cution diff rentes instances du composant sont cr es et chacune d elles sous la responsabilit d un client Ainsi CBSE et SOSE ont des points de vue diff rents sur les relations entre client et fournisseur qui agissent sur d autres aspects de distinction la gestion des h t ro g n it s l importance de automatisation et le couplage L objectif du service est l ind pendance avec les technologies d impl mentation Un service doit tre accessible et utilisable sans aucune hypoth ses sur son impl men tation sur les utilisateurs potentiels ou sur la fa on d utiliser ce service Cette probl matique est bien connue en CBSE mais ne repr sente pas un enjeu aussi critique En effet il existe un tr s grand nombre de mod les de composant CRN 07 Un archi tecte doit choisir un mod le particulier et n utiliser que des composants respectant ce mod le car la collaboration entre mod les diff rents est tr s difficile CRN 06 par exemple les ponts entre COM et CORBA Le SOSE pr ne un unique mod le homo g ne de services ERI 08 qui doit tre standardis et utilis par tous Une autre distinction est l importance accord e l automatisation qui a particip la d finition m me du SOSE
4. Instanciation Provisioning niveaux Instanciation de sch ma abstraction de composition Processus For reuse Processus de Processus de de cycle d veloppement d veloppement de vie de composant de service By reuse Cycle de vie Cycle de vie Cycle de vie de syst me de syst me de syst me bas objets bas composants bas services proposent une analyse plus fine des diff rents produits et processus afin d am liorer le degr s d expressivit du SOSE en g rant de fa on explicite les deux niveaux d abs traction Ces propositions sont repr sent es dans le tableau 1 par les l ments en catio Dans CAV 09 les auteurs introduisent le concept de service abstrait Le pro cessus de service provisioning utilise ce service abstrait pour s lectionner le service concret qui correspond aux besoins Le service concret est le service que le syst me va r ellement utiliser et invoquer au runtime Cependant les services abstraits et concrets sont d finis comme des instances de services ce qui implique une confusion entre les niveaux d abstraction et les notions de types et instances Ainsi nous proposons HOC 10a une autre approche du service abstrait qui est vu comme un type de ser vice Le processus qui fait le lien entre le type et l instance est le service provisio ning Ainsi la m thode d instanciation par provisioning du SOSE est diff rente des approches OO et CBSE Le service abstrait est un produit du design ti
5. es chang es etc Pouvoir expressif repr sente la capacit du paradigme 4 proposer un grand nombre de concepts et de processus permettant de sp cifier et de manipuler ses pro duits Abstraction de communication la capacit du paradigme 4 abstraire la couche de communication qui dirige l ex cution de application Architecture explicite la capacit du paradigme a fournir une vue architecturale claire de l application Pouvoir volutif la capacit du paradigme proposer un ensemble de concepts et de processus pour faire voluer ses l ments architecturaux Responsabilit propri taire correspond la r partition des responsabilit s entre fournisseur et consommateur d un bloc logiciel r utilis objet composant service Ces responsabilit s sont le d veloppement la qualit de service la maintenance le d ploiement l ex cution et la gestion Ce crit re exprime le degr s de libert accord au client par le fournisseur sur son produit Ces six caract ristiques ont des impacts forts et entrem l s sur nos trois crit res de qualit cependant nous cherchons toujours qualifier l essentiel de chaque l ment afin de fournir un cadre de comparaison simple mais explicite Ainsi la figure 3 montre Dynamicit Coefficient d impact Couplage faible Pouvoir volutif a Abstraction de communication Responsabilit propri taire 4 B Architecture explicite Pouvoir exp
6. les auteurs listent les concepts et les vocabulaires li s aux notions de com posant et service et cherchent expliciter les termes ambigus Notre approche est diff rente mais compl mentaire En effet leur travail a une approche plus fine sur les aspects produits mais aborde tr s peu les aspects processus et qualit D autres com paraisons peuvent tre trouv es ATT 09 NIT 08 et qui nous ont aid a forger notre d marche mais elles n abordent cette probl matique que de fa on parcellaire Cet ar ticle veut tre un compl ment aux recherches existantes sur la diff rence entre objet et composant SZY 02 OUS 05 en y incluant le service Nous proposons donc un cadre de comparaison global de trois paradigmes principaux du g nie logiciel L aspect quantitatif a mis en vidence certaines carences du SOSE sur la gestion des niveaux d abstraction dont nous avons fourni quelque pistes de solutions L as pect qualitatif apporte une meilleure compr hension des principes de r utilisabilit composabilit et dynamicit en soulignant les caract ristiques fondamentales de cha cun d eux et peut ainsi servir de guide aux architectes Par exemple dans HOC 10b nous cherchons d finir un m ta mod le de service composite qui supporte les com positions dynamiques Notre service composite repose sur une architecture claire qui identifie les r les de chacun des services constituants et les communications De plus il utilise des
7. similaires ou sp cialis s qui sont souvent mis en juxtaposition avec des confusions de vocabulaire Les applications modernes qui combinent composants et services ajoutent cette confusion ambiante et la compr hension globale devient plus difficile Notre objectif est de clarifier les fronti res entre CBSE et SOSE Dans cet ar ticle nous proposons un premier cadre de comparaison bas sur un triptyque produit processus et qualit Ce triptyque organise les caract ristiques de chacun afin d offrir aux architectes une meilleure compr hension des implications et des cons quences du choix de l un ou l autre des paradigmes De plus ce cadre de comparaison prend en compte l orient objet OO afin d apporter une vision globale de l volution des pr occupations du g nie logiciel entre objet composant et service La section suivante va pr senter les diff rences th oriques que nous identifions entre CBSE et SOSE Dans la section 3 nous pr sentons l aspect quantitatif de notre cadre de comparaison qui regroupe les notions de produit et de processus La section 4 va en aborder l aspect qualitatif La section 5 discute des contributions de notre travail et les limitations des autres tentatives de comparaisons existantes Enfin la section 6 conclut cet article 2 Diff rences th oriques entre CBSE et SOSE CBSE et SOSE ont une approche tr s similaire et partagent les activit s d identi fication des entit s logiciell
8. En effet la grande majorit des travaux cherche auto matiser les m canismes du SOSE tels que la publication de services les d couvertes et s lections la composition etc Ce principe d automatisation est pouss son ex tr me par le concept d auto adaptation NIT 08 qui cherche coordonner l ensemble des m canismes li s au service afin d assurer des adaptations contextuelles r actives ou proactives Bien que l automatisation est un l ment cl de la recherche en CBSE elle ne fait pas partie de la d finition d un mod le de composant CRN 07 Gestion des h t rog n it s et automatisation participent une autre distinction entre CBSE et SOSE le couplage HOC 10a Le SOSE pr ne un couplage faible tous les niveaux du d veloppement l ex cution D une part un architecte ne doit pas conna tre au moment de la sp cification de son application les services qui seront r ellement utilis s Ce couplage faible entre l expression des besoins et les services concrets disponibles est support par les principes de d couvertes et s lections dyna miques D autre part le SOSE va chercher r duire au maximum les d pendances entre services concrets en collaboration pour faciliter l auto adaptation NIT 08 Toutes les distinctions que nous avons identifi es sont li es la notion de dyna micit Le SOSE vient de besoins fonctionnels d applications sp cifiques en terme d exigences sur l
9. m canismes de m diation pour r duire le couplage Ainsi notre m ta mod le se focalise sur trois caract ristiques qui se trouvent au plus haut niveau de la dynamicit et de la composabilit composition dynamique le couplage faible l architecture explicite l abstraction de communication Figure 3 6 Conclusion Dans cet article nous proposons une compr hension claire des diff rences th o riques entre les notions de composant et de service Ce travail repose sur un cadre de comparaison bas sur un triptyque produit processus et qualit De plus notre com paraison inclut l orient objet afin d offrir un point de vue global sur l volution des pr occupations du g nie logiciel 7 Bibliographie ATT 09 ATTIOGB C Can Component Service Based Systems Be Proved Correct SOFSEM 2009 p 3 18 BRE 07 BREIVOLD H P LARSSON M Component Based and Service Oriented Soft ware Engineering Key Concepts and Principles EUROMICRO SEAA 2007 p 13 20 CAV 09 CAVALLARO L NITTO E D PRADELLA M An Automatic Approach to En able Replacement of Conversational Services 1CSOC ServiceWave 2009 p 159 174 CRN 06 CRNKOVIC I CHAUDRON M R V LARSSON S Component Based Develop ment Process and Component Lifecycle ICSEA 2006 page 44 CRN 07 CRNKOVIC I CHAUDRON M SENTILLES S VULGARAKIS A A Classifica tion Framework for Component Models Proceedings of the 7th
10. Conference on Software Engineering and Practice in Sweden 2007 ERI 08 ERICKSON J SIAU K Web Services Service Oriented Computing and Service Oriented Architecture Separating Hype from Reality J Database Manag vol 19 n 3 2008 p 42 54 GAR 97 GARLAN D MONROE R T WILE D Acme an architecture description inter change language CASCON 1997 page 7 GAR 09 GARLAN D BARNES J M SCHMERL B R CELIKU O Evolution styles Foundations and tool support for software architecture evolution WICSA ECSA 2009 p 131 140 GOA 08 GOAER O L TAMZALIT D OUSSALAH M SERIAI A Evolution Shelf Reu sing Evolution Expertise within Component Based Software Architectures COMPSAC 2008 p 311 318 HEI 01 HEINEMAN G COUNCILL W Component based software engineering putting the pieces together Addison Wesley Professionalt 2001 HOC 10a HOCK KOON A OUSSALAH M Defining Metrics for Loose Coupling Evalua tion in Service Composition IEEE SCC 2010 p 362 369 HOC 10b HOCK KOON A OUSSALAH M Expliciting a Composite Service by a Meta Modeling Approach RCIS 2010 MED 00 MEDVIDOVIC N TAYLOR R N A Classification and Comparison Framework for Software Architecture Description Languages IEEE Trans Software Eng vol 26 n 1 2000 p 70 93 NIT 08 NITTO E D GHEZZI C METZGER A PAPAZOGLOU M P POHL K A jour ney to highly dynamic self ad
11. OSE ciblent une r duction de ce couplage Le couplage faible est un enjeu cl de ces deux paradigmes L entrela cement des solutions propos es et leurs influences mutuelles ne permettent pas de les diff rencier de mani re claire Cependant notre tude du couplage HOC 10a permet d identifier une marge de progression possible Pouvoir expressif OO manipule un grand nombre de concepts tels que l h ri tage les niveaux d abstraction les niveaux de description la granularit la r flexion etc Le CBSE s est largement inspir de ce travail mais il n a pas encore atteint le m me niveau de maturit sur les concepts comme l h ritage la r flexion etc Enfin le SOSE poss de le plus faible pouvoir expressif car il combine les m me lacunes que le composant auxquelles s ajoutent des impr cisions sur les niveaux d abstraction soulign s par notre analyse quantitative Abstraction de communication le SOSE fournit la meilleure abstraction de communication bas e sur l encapsulation apport e par les services et l isolation des communications dans un sch ma de composition Le comportement global est plus facilement localisable compr hensible et manipulable De plus cet aspect est renforc par la nature multitenant du service et sa capacit g rer des ex cutions parall les En CBSE les communications sont localis es l int rieur des diff rents connecteurs qui partagent le comportement global Les flots
12. aits et pourra les instancier de fa on ad quate en fonction des clients qui se connectent La partie quantitative de notre cadre de comparaison met aussi en vidence une autre lacune du SOSE sur la notion de description de service composite La descrip tion de service est un l ment cl de la dynamicit en service cependant il n existe pas encore d tude approfondie sur la d finition d une description de service com posite et sur un processus de composition de description de services qui permettrait d automatiser la mise disposition d un composite sur le march Dynamicit see Service Composant Objet a R utilisabilit Composabilit Figure 2 Qualit globale 4 Les aspects qualitatifs Les travaux existants sur la qualit logicielle introduisent un grand nombre de cri t res bas s sur diff rents points de vue d veloppeur utilisateur etc Notre analyse qualitative ne cherche pas faire une liste exhaustive de ces crit res mais plut t ex traire l essence des paradigmes de d veloppement logiciel afin de pouvoir les compa rer Ainsi notre approche peut se diviser en trois tapes Dans un premier temps nous cherchons abstraire les qualit s primordiales d un paradigme Puis nous identifions les principales caract ristiques d un paradigme qui impactent sur ces qualit s Enfin ces caract ristiques sont utilis es pour classifier OO CBSE et SOSE et les c
13. amicit accrue Cependant son approche trop g n rique pose des contraintes sur ces solutions qu une partie de la communaut a voulu contourner en proposant la notion de service Ainsi le d veloppement du SOSE est exclusivement centr sur la dynamicit mais repose sur le socle pos par les autres paradigmes Dans cette section nous cherchons raffiner cette vision r sum e tr s haut niveau Nous identifions six caract ristiques principales des paradigmes de d veloppement logiciel qui impactent sur la r utilisabilit la composabilit et la dynamicit Couplage Faible le couplage mesure les d pendances entre entit s en collabora tion et affaiblir ce couplage s est tendre vers leur ind pendance Dans HOC 10a nous avons tudi la notion de couplage faible que nous d finissons comme une combinai son de trois couplages distincts s mantique syntaxique et physique Le couplage s mantique se focalise sur l expertise du designer sur le domaine d application de son syst me Il lui permet d en tablir la criticit des aspects fonctionnels Le couplage syntaxique tudie les relations entre ces aspects fonctionnels et leurs repr sentations physiques dans le syst me Enfin le couplage physique mesure les d pendances entre ces repr sentations physiques Cette d finition du couplage se base sur de nombreux l ments tels que la gestion des h t rog n it s les processus de communication la complexit des donn
14. aptive service based applications Autom Softw Eng vol 15 n 3 4 2008 p 313 341 OAS 08 OASIS Reference Architecture for Service Oriented Architecture 1 0 2008 http docs oasis open org soa rm soa ra v 1 0 soa ra pr O1 pdf OUS 05 OUSSALAH M ALL Ing nierie des composants Concepts techniques et Outils Vuibert 2005 STO 05 STOJANOVIC Z DAHANAYAKE A Service oriented Software System Engineering Challenges And Practices IGI Publishing Hershey PA USA 2005 SZY 02 SZYPERSKI C Component Software Beyond Object Oriented Programming Addison Wesley Professional 2002 THE 08 THESECSETEAM Service Centric System Engineering EU Integrated Project 2008 http www secse project eu
15. de travail sont moins explicites La granularit tr s fine du OO accentue cet handicap Architecture explicite contrairement l 00O CBSE et SOSE reposent directe ment sur le concept d architecture logicielle Pouvoir volutif le pouvoir volutif est directement li la notion d architecture explicite Une architecture logicielle d finit clairement des entit s et les relations entre ces entit s On peut la repr senter par un graphe bas sur des noeuds et des arcs Les processus d volutions peuvent tre regroup s suivant leur cible le noeud l arc ou le graphe Typiquement 1 OO ne propose pas cette notion d architecture explicite et donc de graphe Les processus d volution de l OO se focalisent uniquement sur les noeuds et les arcs Au contraire CBSE et SOSE manipulent une architecture explicite et donc offrent des processus d volutions sur les trois cibles Cependant la maturit plus importante du CBSE et sa gestion explicite des niveaux d abstraction ont permis sa communaut d aller encore plus loin et de proposer des processus d volutions aux niveaux meta et meta meta architecture GOA 08 GAR 09 Responsabilit propri taire le SOSE pousse la responsabilit propri taire 4 son extr me o le fournisseur de service est responsable du d veloppement de la qualit de service de la maintenance du d ploiement de l ex cution et de la gestion Au contraire le CBSE partage les
16. es composant ou service qui r pondent aux besoins puis de combinaison de ces entit s pour r aliser l application globale Ils reposent sur les m me notions de composition et de composite qui garantissent une approche homo g ne o toute entit est un composant ou un service Cependant bien que CBSE et SOSE aient le m me objectif global les th ories derri re les composants et les ser vices sont diff rentes Un composant est dit off the shelf sur l tag re NIT 08 CRN 06 HEI 01 par adoption d une pi ce technologique le composant qui est disponible pour les d ve loppeurs Un service est centr sur l utilisation d une fonction fournie par un tiers STO 05 OAS 08 THE 08 Ces deux visions sont tr s proches et notre travail veut raffiner leur d finition Pour illustrer notre premi re distinction nous prenons un exemple de l industrie du jeux vid o sur PC Cette industrie repose sur deux mod les de distribution de contenus Le premier mod le classique correspond un joueur qui ach te une copie de son jeu Le joueur est ensuite responsable du d ploiement de cette copie sur sa propre machine Ce mod le correspond une approche composant Typiquement le jeu composant vient avec un manuel d instructions documentation sur la configuration syst me mi nimale requise pour tre capable d ex cuter ce jeu puis sur les op rations n ces saires pour l installer et enfin sur comment y jouer Tous ce
17. es processus se focalise sur le principe de r utilisation c est dire comment r utiliser des entit s logicielles les constituants pour en construire de nou velles les composites un constituant pouvant tre un l ment architectural simple ou composite Ces notions de constituants et composites d finissent deux niveaux de description Ainsi les processus sont regroup s suivant les niveaux d abstraction et de description Dans un niveau d abstraction regroupe les processus qui ciblent et produisent des produits d un m me niveau d abstraction Figure 1 fl ches blanches Cette cat gorie est divis e en design time et runtime Entre niveaux de description regroupe les processus qui ciblent des produits de deux niveaux de description diff rents Figure 1 fl ches hachur es Cette cat gorie est divis e en design time et runtime Entre niveaux d abstraction regroupe les processus qui assurent le passage des produits entre design time et runtime Figure 1 fl ches noires processus de cycle de vie regroupe les processus charg s des diff rentes activi t s du cycle de vie de l id e de la conception d une application son d veloppement et son utilisation et jusqu sa fin de vie Cette sous cat gorie est divis e en deux suivant les notions de for reuse et by reuse li es la construction en constituants et composites La cat gorie for reuse se focalise sur le processus de d
18. ice Cadre de Comparaison Conceptuel KEYWORDS Object Component Service Conceptual Comparison Framework 1 Introduction Ling nierie logicielle base de composants Component based software enginee ring CBSE HEI 01 et l ing nierie logicielle orient e services Service oriented software engineering SOSE STO 05 THE 08 sont deux domaines tablis du g nie logiciel Le CBSE s inspire des autres disciplines de l ing nierie telles que lin g nierie m canique ou lectrique Il repose sur l id e de construire des syst mes partir de composants Le SOSE se base sur le mod le de mondialisation des entre prises modernes Le principe est de sous traiter les fonctions faible valeur ajout e ou chappant au domaine de comp tence de l entreprise afin de se concentrer sur les aspects innovants du syst me Ainsi CBSE et SOSE ont la r utilisation d entit s logicielles existantes compo sants ou services comme socle commun Tous deux reposent sur le concept d archi tecture logicielle MED 00 dans lequel un syst me est vu comme une structure claire d entit s et de relations entre ces entit s Le SOSE est un paradigme plus r cent dont l approche est influenc e par le CBSE d une fa on similaire l incidence que l objet a eu sur le composant De plus ces derni res ann es ont vu CBSE et SOSE coexister tout en ayant un d veloppement parall le ce qui a entra n l apparition de concepts
19. ien entre constituants et composites Runtime les processus de communication entre constituants et composites sont l essence de cette cat gorie OO et CBSE reposent sur diff rents processus d appels En CBSE ces appels sont parfois nomm s comme le processus de d l gation En SOSE la coordination des processus d invocations de services entre composite et constituants est appel e l orchestration Entre niveaux d abstraction Tableau 1 Objet et composant reposent sur le pro cessus d instanciation pour lier type et instance Le SOSE se focalisant sur le runtime cette cat gorie ne le concerne pas Processus de cycle de vie la principale diff rence avec l 00 vient d une s pa ration entre le d veloppement for reuse et by reuse Le for reuse est le processus de d veloppement d un composant ou d un service en vue d tre r utilis Le by reuse est le processus de d veloppement d un syst me en r utilisant des composants ou des services existants CBSE et SOSE vont se diff rencier principalement sur la notion de d couverte et s lection dynamique de services et sur l absence de d ploiement des services constituants s lectionn s Un certain nombre d activit s du cycle de vie sont modifi es ainsi que la fronti re entre le design time et runtime Nous ne d taillons pas cet aspect dans l article due la limitation du nombres de pages 3 3 Analyse des aspects quantitatifs Le tableau 1 r su
20. l ments architecturaux simples Tableau 1 Les l ments architecturaux sim ples de l orient objet sont la classe au design time et son instance l objet au runtime La m me distinction est faite pour le CBSE entre les produits fype de composant et type de connecteur GAR 97 et leurs instances composant et connecteur En SOSE la fronti re entre les niveaux d abstraction est beaucoup moins claire et la plupart des travaux existants se r f rent un service comme un entit du runtime STO 05 THE 08 Chaque service est associ une description de service OAS 08 qui est la cible des nombreux processus runtime lements architecturaux complexes Tableau 1 Les trois paradigmes partagent la notion de composite L orient objet repose sur les notions de classe composite et d objet composite Le CBSE repose au design time sur les notions de type de confi guration et type de composant composite et au runtime sur leurs instances configura tions et composants composites Le SOSE est principalement au runtime Ainsi une composition de services d pend des notions de sch mas de composition et de service composite Ces notions sont associ es 4 deux patrons de coordination de services la chor graphie et V orchestration OAS 08 Ces patrons sont typiquement produits et ex cut s au runtime 3 2 2 Processus L objectif de cette partie n est pas de fournir une liste exhaustive des processus existants mais de s lection
21. me Le service concret un produit du runtime Le service provisioning est un processus de la cat gorie du design time au runtime D une fa on homog ne nous proposons les concepts de sch ma de composition abstrait et de service composite abstrait et leur instance respective sch ma de com position concret et service composite concret Le service provisioning est nouveau le processus qui fait le lien entre service composite abstrait et concret cependant nous introduisons un processus d instanciation de sch mas de composition En effet un service composite repose sur un sch ma de composition orchestration ou chor gra phie pour coordonner ces services constituants Ce composite est multitenant et doit donc g rer de nombreux clients en parall le A nsi partir du sch ma de composition abstrait qui exprime le comportement du service composite le processus d instancia tion va cr er un sch ma de composition concret pour chaque client et ainsi isoler les ex cutions De plus l introduction de la notion de sch ma de composition abstrait et concret va permettre la d finition de processus inspir s de l objet et du composant Un proces sus d h ritage sur ce sch ma peut faciliter la r utilisation Le fournisseur de service composite pourra facilement d velopper des comportements sp cialis s d finis apr s n gociation avec certains clients Le service composite maintiendra les diff rents sch mas de composition abstr
22. me la partie quantitative de notre cadre de comparaison Comme nous l avons remarqu pr c demment les d finitions couramment admises du SOSE se focalisent sur la partie runtime Cependant certains travaux CAV 09 HOC 10a Tableau 1 Produit Processus Comparaison Objet Composant et Service Produit OBJET COMPOSANT SERVICE El ment Design Classe Type composant Service abstrait architectural time Type connecteur simple Runtime Objet Composant Service Connecteur Concret Description l ment Design Classe Type de Sch ma de composition abstrait architectural time composite configuration abstrait composite Type composant Service composite abstrait composite Runtime Objet Configuration Sch ma de composite Composant composition composite Concret Patron de chor graphie orchestration Service composite Concret Description service composite Dans un Design Association Composition Choreograph niveau time H ritage horizontale H ritage de sch ma d abstraction Versionnement de composition Raffinage Runtime Appel de Appel de fonction Chor graphie m thode Provisioning Invocation Publication Entre Design Composition Composition Orchestration niveaux de time verticale Description de description Composition de services Runtime Appel de Appel de fonction Orchestration m thode D l gation Invocation Entre Instanciation
23. ner les plus pertinents et largement accept s afin de mettre en perspective les diff rences entre objet composant et service Dans un niveau d abstraction Tableau 1 Le SOSE tant principalement d finit au runtime la premi re sous cat gorie suivante ne le concerne pas Design time l orient objet repose principalement sur les processus d association et d h ritage Le CBSE repose sur la composition horizontale entre l ment architecturaux de m me niveau de description Mais on peut galement citer les processus de versionnement ou de raffinage Runtime les processus de communication entre l ments architecturaux sont la pr occupation principale de cette cat gorie OO et CBSE reposent principalement sur diff rents processus d appels alors que le SOSE inclut obligatoirement des pro cessus additionnels Typiquement les services constituants doivent tre d couverts et s lectionn s dynamiquement processus de service provisioning Ensuite ces services constituants coordonnent leurs actions par un processus de chor graphie qui d finit les successions d invocations de service De plus un processus de publication de services est n cessaire pour mettre un service disposition des clients potentiels Entre niveaux de description Tableau 1 Design time OO repose sur le processus de composition pour produire des l ments composites Le CBSE repose sur la composition verticale qui fait le l
24. omparer en fonction des qualit s 4 1 Crit res de qualit Notre premi re contribution d crite dans la section 2 identifie nos qualit s primor diales r utilisabilit composabilit et dynamicit R utilisabilit la probabilit qu un produit ou un processus soit r utilis avec peu ou pas de modifications Composabilit la facilit d un paradigme de d veloppement logiciel combi ner de fa on s re ses l ments architecturaux dans le but de construire de nouveaux syst mes ou l ments composites Dynamicit se base sur la facilit d un paradigme de d veloppement logiciel construire et modifier une application et le niveau d automatisation li aux processus associ s Ces trois crit res ont des impacts intuitivement compr hensibles sur des propri t s telles que la flexibilit l agilit la productivit la robustesse l extensibilit etc La figure 2 montre le positionnement suivant nos crit res des paradigmes objet composant et service qui sont l origine de leur d finition La r utilisation est l enjeu central de OO mais il ne propose que tr s peu de solutions pour am liorer la com posabilit et la dynamicit En effet ces pr occupations ne sont devenues capitales que bien plus tard en particulier la composabilit a pouss l apparition du composant Ainsi le CBSE a apport un grand nombre d innovations et permet de poser les bases d une dyn
25. responsabilit s au niveau du d ploiement o le client devient responsable de l instanciation du composant dans son application de son ex cution et de sa gestion En OO la classe est en boite blanche o le client est libre de la manipuler sa guise partir de cette classification Figure 4 nous utilisons les formules d valuation pr c dentes pour mesurer la r utilisabilit la composabilit et la dynamicit de chaque paradigme Chaque niveau d importance haut moyen faible est associ une valeur resp 3 2 1 Objet Dynamicite a 3 B 2 y 3 Composabilite a 2 B 2 4 Reutilisabilite a 4 8 3 7 1 4 Composant Dynamicite a 7 B 4 y 2 Composabilite a 5 B 4 y 4 a 5 8 6 2 5 Reutilisabilite Service Dynamicite a 7 B 5 y 1 Composabilite a 5 B 4 y 4 Reutilisabilite a 3 B 7 3 6 Ainsi on peut remarquer que CBSE et SOSE sont tr s proches avec une meilleure dynamicit pour le service face une meilleure r utilisation pour le composant Cette similarit illustre l origine de la confusion entre ces deux paradigmes Cependant cet article met en vidence les diff rences sur les causes qui am nent ce r sultat 5 Contributions Malgr son importance peu de travaux se focalisent sur la distinction entre com posants et services Nous identifions une seule autre tude de cette comparaison Dans BRE 07
26. ressif 7 Figure 3 Hi rarchie caract ristique et qualit les relations entre les caract ristiques et les crit res de qualit identifi s Ces caract ristiques sont organis es du groupe y qui a l impact le moins important au groupe a qui l impact le plus important A partir de cette classification nous d finissons un ensemble de formule Dynamicite a x Cplg Evol AbstrCom B x Resp ArchiEzpl 7 Expr 1 Composabilite a x Evol AbstrCom B Cplg ArchiExpl 7 Resp Expr 2 Reutilisabilite a x Evol Expr B x AbstrCom ArchiExpl Cplg y Resp 3 a gt B gt 7 Nous ne d taillons pas la d finition de cette organisation hi rarchique afin de nous focaliser sur son utilisation pour la comparaison entre objet composant et service a i faible Responsabilit Pouvoir propri taire haut a 4 77 expressif Composant Objet ae Abstraction Architecture Z de explicite 4 communication Pouvoir volutif Figure 4 Comparaison objet composant et service 4 2 Comparaison entre objet composant et service La figure 4 montre notre classification entre OO CBSE et SOSE en fonction de nos six caract ristiques suivant trois niveaux d importance haut moyen faible accord s sur chacun d eux Couplage Faible typiquement les syst mes base d objets font intervenir un en semble de classes fortement coupl es tandis que CBSE et S
27. s l ments d finissent des contraintes du c t client Le second mod le appel Cloud gaming illustre la notion de service Le joueur paie le droit de jouer un jeu qui est ex cut sur une plate forme distance sous la responsabilit du fournisseur Il a uniquement besoin d une inter face et d une connexion pour acc der cette plate forme Il n est plus responsable du d ploiement du jeu sur sa machine Les seules informations qui lui sont n cessaires sont comment acc der cette plate forme et comment jouer au jeu Ainsi le joueur n a plus s occuper des contraintes du syst me pour ex cuter le jeu qui conserve une qualit constante Au contraire du premier mod le o il peut tre amen am liorer la configuration de sa machine pour obtenir une certaine exp rience du jeu qui va varier d un syst me un autre Ainsi l orient service pousse la responsabilit du propri taire son extr me En effet l approche off the shelf de CBSE implique que seul le d veloppement la qualit de service et la maintenance sont sous la responsabilit du fournisseur tandis qu en SOSE le fournisseur est aussi responsable du d ploiement de l ex cution et la gestion du service La localisation physique du service et ses volutions sont transparentes pour l utilisateur Ce concept de responsabilit implique aussi la nature multitenant du service c est dire que le service ex cut distance doit
28. veloppement d un constituant dans le but d tre r utilis La cat gorie by reuse se focalise sur le proces sus de d veloppement d un composite par r utilisation de constituants existants La figure 1 montre la r partition des produits et processus sur un exemple Un com posite C est construit partir de deux constituants un l ment architectural simple constituant A et un l ment architectural composite constituant B Ces trois pro duits ont leurs repr sentations au design time et au runtime Les fl ches repr sentent les processus qui sont tudi s Les fl ches blanches sont les processus li s un m me niveau d abstraction design time ou runtime Les fl ches hachur es sont les processus qui font le lien entre niveaux de description et qui ont leurs repr sentations au design NIVEAU DE DESCRIPTION PRODUIT Ciena Compare El ment architecturalEl ment architectural zes Simple Composite A 2222222777 EC ms Design p Q bem Type time Instance NIVEAU ABS a i PROCESSUS A gt Dans un niveau d abstraction Runtime ZZZ Entre niveaux de description gt Entre niveaux d abstraction Figure 1 Niveaux d abstraction et de description time et au runtime Les fl ches noires sont les processus qui font le lien entre niveaux d abstraction 3 2 Comparaison entre objet composant et service 3 2 1 Produit
Download Pdf Manuals
Related Search