Protocoles et composants

Protocoles de composants logiciels

Pascal André, Gilles Ardourel et Christian Attiogbé  
LINA - FRE CNRS 2729
2, rue de la Houssinière, B.P.92208, F-44322 Nantes Cedex 3, France
(Pascal.Andre,Gilles.Ardourel,Christian.Attiogbe)@univ-nantes.fr

Octobre 2006

Ce document propose un rapide tour d'horizon de la notion de protocoles dans les modèles à composants.

1  Concept

Un protocole définit un mode d'emploi de son composant. Plus précisément il définit des règles d'usage et d'enchaînement de services du composant : c'est un protocole d'utilisation. Il diffère donc quelque peu des protocoles de communication habituels qui détaillent les principes de bonne communication entre participants [AG97].

L'objectif est d'aider le client (un autre composant) à comprendre comment utiliser un ensemble de services qui l'intéressent ou inversement à éviter d'utiliser de manière hasardeuse ces services (ne pas faire “n'importe quoi”). En explicitant la dynamique de l'ensemble des services, on réduit la combinatoire d'utilisation des services. Inversement, du point de vue du fournisseur, les protocoles permettent d'alléger la description individuelle des services et dégageant des services les contraintes d'enchaînement et des conditions générales du composant. En particulier, les préconditions des services (lorsqu'elles sont définies dans le modèle à composant) deviennent plus simples à spécifier et vérifier. Autrement dit, le protocole implicite est d'utiliser n'importe quel service dans n'importe quel ordre. Les éventuelles conditions d'application se trouvent alors dans les préconditions ou les gardes des services. Un troisième objectif des protocoles est de définir un niveau de granularité plus large que celui des services et de favoriser ainsi l'abstraction, la réutilisabilité et la modularité des composants. Un quatrième objectif est de faciliter la vérification des propriétés de cohérence des composants et de conformité dans les assemblages de composants. En effet, il ne suffit pas d'appeler correctement les services pour être sûrs que l'assemblage fonctionne, on doit prendre en compte l'évolution dynamique des échanges entre composants. Rappelons que ces échanges se font, d'un point de vue abstrait, par invocation de services et envois de messages.

1.1  Exemples

Prenons quelques exemples pour illustrer la nécessité de protocoles.

Protocole en tant que session.
Supposons un composant serveur de fichiers. Pour lire ou écrire dans un fichier (ce sont des services) il faut d'abord ouvrir les fichiers et ne pas oublier de les refermer. L'écriture doit se faire en exclusion mutuelle soit au niveau de l'utilisation globale (ouverture du fichier) soit lors de l'écriture.  
Dans un guichet automatique bancaire (GAB) pour réaliser des opérations (services) de retrait, consultation, dépôt, transfert, l'usager doit au préalable s'identifier (se connecter) et établir les liaison distantes nécessaires au bon fonctionnement des services.

Protocole en tant que processus.
Dans un protocole réseau tel que TCP, les trames sont assimilables à des services et l'ordre des échanges (envois, accusés, connexions, déconnexion, renvois...) est régi par des règles d'ordonnancement bien précises.

Protocole en tant que classe.
Dans un guichet automatique bancaire (GAB), tout le monde n'a pas les mêmes droits et possibilités d'utilisation : un usager quelconque peut retirer de l'argent, un usager ayant un compte dans la banque du guichet peut en plus réaliser des opérations sur compte, un personnel de la banque peut réaliser des services de maintenance.  
Dans une architecture pair-à-pair, un noeud est serveur et client de services comme le partage de fichier, l'échange de données ou la téléphonie.

2  Petit état de l'art

La notion de protocole dans les modèles à composants n'est pas nouvelle. Elle est régulièrement associée à la notion de comportemant dynamique (behavior/protocol). Cependant elle varie d'un langage (un modèle) à l'autre et couvre des réalités différentes (processus de composant, protocole de communication entre deux composants, contexte d'adaptation de connecteurs...). Pour y voir plus clair nous proposons de comparer quelques approches représentatives.

Les deux principaux critères de comparaison sont Les autres critères de comparaison moins fondamentaux sont Néanmoins ces derniers critères sont cruciaux pour la mise d'outils de vérification des protocoles (models checking, theorem proving), de raffinement ou de génération de code.

Le tableau suivant présente une synthèse des approches. Le contenu est relatif aux actions élémentaires. Le rattachement est l'unité à laquelle on associe le protocole. Le formalisme est la catégorie de langage de la dynamique. La propriété est relative à l'approche de preuves. La colonne outil indique si un prototype est développé.

Approche Critères Outils Commentaire
  Contenu Rattachement Formalisme Propriété    
Allen msga, calculs connecteur CSPb traces, TLc X  
Attie msg, calculs interface automates CTLc -  
Becker msg, calculs composant CC-FSM algo.d - substitution
Beugnard java interface - - - contrats, QoS
Canal msg interface exp. regu. π-calcul - n rôles
Inverardi opérations composants CHAM algo.   mollécules
Henziger msg interface automates equiv. - raffinement
            compositions
Kramer msg, calculs composants LTSA CRAe X Java
Moizan evts classe, BDLf LTL -  
    methodes        
Plasil msg composant exp. regu. algo. X  
    interface        
Royer méthode composant STS      
Sudölt méthode composant exp. non reg algo. - récursion
Schmidt   interface FSM - X adaptation,
            assertions
UML 2.0 msg, actions composant statecharts -   interfaces et
            ports multiples
Yellin msg interface FSM algo. - adaptation
Zimmermann opération composant gram. alg. algo. - récursion
Kmelia msg, actions composant FSM - X multi-protocole
    services       assertions
a message signifie qu'un service est considéré de manière atomique et correspond à une opération ou une méthode.
b Communicating Sequential Processes (Hoare)
c Variante de logique temporelle
d Algorithmique, preuve de théorèmes, méthodes ad-hoc
e Compositional Reacheability Analysis (LTSA, LTL)
f Behavior Description Language

Détails
Nous précisions quelques points du tableau précédent en dtaillant les approches. Pour plus de détails consulter les documents en référence.

Dans le modèle d'Allen [AG97], les protocoles sont associés aux connecteurs. L'intérêt majeur est de pouvoir utiliser directement les composants d'implantation.

Attie & Lorenz [AL03a, AL03b, ALPC06] associent les protocoles aux interfaces sachant qu'une interface correspond à une liaison entre composants (deux à deux).

Becker [BOR04] présente un cadre de comparaison de modèles à trois niveaux d'interopérabilité (signature, protocole, qualité de service) qui s'inspirent des travaux de [BJPW99]. Les protocoles sont associés aux composants. Le formalisme doit permettre de déterminer l'inclusion de protocoles (algèbres de processus, prédicats, automates à compteurs de Reussner[Reu02]).

Beugnard [BJPW99] propose quatre niveaux d'interopérabilité (signature, contrats, protocole, qualité de service). Il n'y a pas de modèle de protocoles proposé en dehors d'annotations au code Java.

Canal [CFP+03, BBC05, BCP03, Can04] enrichit les interfaces CORBA par des rôles qui régissent les enchaînements de méthodes sous forme d'expressions régulières. Les rôles sont regroupés dans le protocole de l'interface.

Inverardi [IWY00] reprend les travaux de Boudol sur CHAM. Les composants sont décrits par des mollécules (sortes de processus) et leur évolution par des règles de transformations. L'assemblage des composants se fait d'une part en insérant des variables "composants" dans la description individuelle des composants et d'autre part en instanciant ces variables par des composants dans la configuration. Les communications sont implicites sur les noms d'opérations. Les protocoles sont obtenus par dérivation des règles en considérant les comportements réels et supposés (des variables "composants"). La vérification de cohérence se fait en comparant les deux.

Les travaux de Henziger [dAH01a, dAH01b, dAH01c, BCH05] visent à doter les interfaces de protocoles sous forme d'automates. La composition d'interfaces synchronise les émissions et réceptions, elle produit des protocoles adaptés (élimination d'état et de transitions illégals). Des règles de raffinement ont été proposées, qui comme pour la composition, s'inspirent de la bisimulation. Ces travaux ont été appliqués aux services Web [BCH05].

Les protocoles de Kramer [GKC99, MKG97, MKG99] s'appuient sur les travaux des auteurs sur les automates et la concurrence (le formalisme LTSA) et notamment l'analyse de l'atteignabilité compositionnelle. La composition est un élément clé dans la définition des assemblages, elle permet la définition de propriété de sûreté et de vivacité. L'ensemble est supporté par l'outil Tracta.

L'approche de Moizan [MRR03a, MRR03b] vise à doter les composants d'UML de mécanisme de spécification de la dynamique et de vérification. Les protocoles sont définis pour les composants (et dans une moindre mesure pour les opérations). Le langage de description de comportements est basé sur les automates hiérarchiques inspirés des statecharts. Ce langage supporte des mécanismes de composition et de raffinement de comportements. Les propriétés sont spécifiées en logique temporelle.

Les protocoles de comportement de Plasil [PV02, PP] sont des agents définis par des expressions régulières. Cette sémantique facilite la définition d'opérateur de composition et la substitution d'agents. Les communications entre agents sont synchrones sur des canaux typés en interface requise ou offerte. Les auteurs distinguent trois niveaux de protocoles : les protocoles associés aux interfaces décrivent les enchaînements licites dans une interface offerte ou requis ; les protocoles associés aux composants (appelés frames) décrivent les enchaînements licites sur plusieurs interfaces ; les protocoles associés aux architectures décrivent les enchaînements licites dans une composition de composants (c'est un cas particulier de protocole de composant). Il y a risque de redondance et de confusion entre ces différents niveaux.

Dans la proposition de Royer [PNPR05b, PNPR05a] le protocole est un système de transition symbolique associé aux composants qui enchaîne les services (méthodes) du composants. Bien que plusieurs interfaces soient possibles, le nommage dans le protocole n'en tient pas compte. Pour assembler les composants, il doit y avoir correspondance dans les interfaces. Les auteurs ont étudié l'implantation en Java.

Sudölt [FG03, Süd05] et [Pun99] s'est intéressé aux protocoles utilisant les langages algébriques et non les expressions régulières pour modéliser la dynamique. Un des intérêts est de pouvoir spécifier des appels récursifs de services tout en étudiant les équivalences et le sous-typage.

Les travaux de Schmidt [Sch03, Sch01] portent sur les composants fiables incluant les contrats, les protocoles et les propriétés non-fonctionnelles ainsi que sur l'adaptation. Les protocoles sont définis par des automates au niveau des passerelles, assimilables à des interfaces [SR02].

Dans UML [OMG05], composants et classes sont assimilés (un composant est une classe). De ce fait le protocole est associé aux composants sous forme d'un statechart. Un composant UML dispose de ports sur lesquels il propose des interfaces offertes ou requises de services (opérations, méthodes). Le modèle est suffisamment “large”pour accepter différentes interprétations des concepts du modèle.

Les protocoles de Yellin [YS97] sont des automates associés aux interfaces de telle sorte que pour chaque composant collaborant, une interface est proposée. Une collaboration met donc en oeuvre deux parties. Une notion de sous-typage des protocoles est définie qui facilite l'expression de l'adaptation. L'étude de l'implantation est aussi abordée.

Zimmerman [ZS06] étudie les protocoles autorisant des interfaces dépendantes et des appels récursifs. Ces protocoles sont spécifiés avec des langages algébriques. Une technique model checking permet de vérifier le conformité de protocole.

3  Bilan et remarques

Les critères précédents ne permettent pas de classer les approches en catégories strictement distinctes. En effet il existe des dépendances entre critères et certaines combinaisons sont incohérentes. On peut classer sommairement les approches en trois catégories selon leur rattachement :
  1. Celles dont le protocole définit le “cycle de vie ”du composant (Becker, Inveradi, Kramer, Moizan, Royer, Sudölt, UML, Zimmermann). Un unique protocole est associé au composant (ou à son unique interface, ce qui est équivalent). Dans ces approches, le composant est un processus et les services sont soit atomiques (messages) soit définis par un comportement spécifique (Moizan, UML).
  2. Celles dont le protocole définit le “cycle de vie ”d'une vue du composant (Allen, Attie, Beugnard, Canal, Henziger, Plasil, Schmidt, Yellin). Un protocole est associé à une interface et plusieurs interfaces coexistent. Les interfaces peuvent être limitées à un seul composant cible (assimilable à un connecteur) ou pas.
  3. Celles dont le protocole définit un usage du composant (Kmelia). Plusieurs protocoles coexistent au sein du composant.
La différence entre les approches n'est pas radicale en terme de puissance d'expression dans la mesure ou le multi-protocole s'obtient aussi par composition de composants ou multiplication des interfaces. Mais elle l'est en terme d'expressivité car c'est au concepteur d'architectures d'encapsuler les protocoles dans des composants composites ou de gérer la cohérence des interfaces (proches des problèmes d'héritage en objet) ; il en résulte une lourdeur des modélisations. Les approches de la catégorie 1 (et une partie de celles de la catégorie 2) interprètent les protocoles comme contrainte d'utilisation et non comme mode d'emploi.

De façon orthogonale, les protocoles peuvent s'inscrire dans une démarche contractuelle en s'associant avec des assertions (Becker, Beugnard, Kmelia, Schmidt, UML-OCL, Schmidt) et des contraintes non-fonctionnelles comme la qualité de service (Becker, Beugnard). Certaines approches traitent de la récursion (Sudölt, Zimmerman), de l'adaptation (Allen, Becker, Canal, Kmelia, Schmidt, Yellin), du sous-typage de protocoles (Becker, Plasil, Yellin) ou du raffinement (Henziger, Moizan). D'autres relient les protocoles à des implantations de composant (Allen, Kramer, Royer) ou proche de modèles comme CORBA (Canal), ce qui leur donne à la fois une certaine crédibilité mais aussi des structures moins abstraites.

Références

[AG97]
Robert Allen and David Garlan. A Formal Basis for Architectural Connection. ACM Transactions on Software Engineering and Methodology, 6(3):213–249, July 1997.

[AL03a]
P. Attie and D. H. Lorenz. Correctness of Model-based Component Composition without State Explosion. In ECOOP 2003 Workshop on Correctness of Model-based Software Composition, 2003.

[AL03b]
P. C. Attie and D. H. Lorenz. Establishing Behavioral Compatibility of Software Components without State Explosion. Technical Report NU-CCIS-03-02, College of Computer and Information Science, Northeastern University, 2003.

[ALPC06]
Paul C. Attie, David H. Lorenz, Aleksandra Portnova, and Hana Chockler. Behavioral compatibility without state explosion: Design and verification of a component-based elevator control system. In Ian Gorton, George T. Heineman, Ivica Crnkovic, Heinz W. Schmidt, Judith A. Stafford, Clemens A. Szyperski, and Kurt C. Wallnau, editors, CBSE, volume 4063 of Lecture Notes in Computer Science, pages 33–49. Springer, 2006.

[BBC05]
Andrea Bracciali, Antonio Brogi, and Carlos Canal. A formal approach to component adaptation. Journal of Systems and Software, 74(1):45–54, 2005.

[BCH05]
Dirk Beyer, Arindam Chakrabarti, and Thomas A. Henzinger. Web service interfaces. In WWW '05: Proceedings of the 14th international conference on World Wide Web, pages 148–159, New York, NY, USA, 2005. ACM Press.

[BCP03]
A. Brogi, C. Canal, and E. Pimentel. On the specification of software adaptation, 2003. In FOCLASA'03, ENTCS, 90 (in press).

[BJPW99]
Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, and Damien Watkins. Making Components Contract Aware. Computer, 32(7):38–45, 1999.

[BOR04]
Steffen Becker, Sven Overhage, and Ralf Reussner. Classifying Software Component Interoperability Errors to Support Component Adaption. In Ivica Crnkovic, Judith A. Stafford, Heinz W. Schmidt, and Kurt C. Wallnau, editors, Component-Based Software Engineering, 7th International Symposium, CBSE 2004, Edinburgh, UK, May 24-25, 2004, Proceedings, volume 3054 of Lecture Notes in Computer Science, pages 68–83. Springer, 2004.

[Can04]
Carlos Canal. On the dynamic adaptation of component behaviour. In Carlos Canal, Juan Manuel Murillo, and Pascal Poizat, editors, WCAT'04, pages 81–88, Available online at http://wcat04.unex.es, 2004.

[CFP+03]
Carlos Canal, Lidia Fuentes, Ernesto Pimentel, José M. Troya, and Antonio Vallecillo. Adding Roles to CORBA Objects. IEEE Trans. Softw. Eng., 29(3):242–260, 2003.

[dAH01a]
L. de Alfaro and T. A. Henzinger. Interface Automata. In Proceedings of the Ninth Annual Symposium on Foundations of Software Engineering (FSE), pages 109–120. ACM Press, 2001.

[dAH01b]
Luca de Alfaro and Thomas A. Henzinger. Interface automata. In ESEC/FSE-9: Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering, pages 109–120, New York, NY, USA, 2001. ACM Press.

[dAH01c]
Luca de Alfaro and Thomas A. Henzinger. Interface theories for component-based design. In EMSOFT '01: Proceedings of the First International Workshop on Embedded Software, pages 148–165, London, UK, 2001. Springer-Verlag.

[FG03]
Andrés Farías and Yann-Gaël Guéhéneuc. On the coherence of component protocols. Electronic Notes in Theoretical Computer Science, 82(5), April 2003.

[GAN05]
T. Gschwind, U. Aßmann, and O. Nierstrasz, editors. Software Composition, 4th Int. Workshop, SC 2005, Edinburgh, UK, volume 3628 of Lecture Notes in Computer Science. Springer, 2005.

[GKC99]
Dimitra Giannakopoulou, Jeff Kramer, and Shing-Chi Cheung. Behaviour Analysis of Distributed Systems Using the Tracta Approach. ASE, 6(1):7–35, 1999.

[IWY00]
Paola Inverardi, Alexander L. Wolf, and Daniel Yankelevich. Static checking of system behaviors using derived component assumptions. ACM Trans. Softw. Eng. Methodol., 9(3):239–272, 2000.

[MKG97]
Jeff Magee, Jeff Kramer, and Dimitra Giannakopoulou. Analysing the behaviour of distributed software architectures: a case study. In FTDCS '97: Proceedings of the 6th IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS '97), page 240, Washington, DC, USA, 1997. IEEE Computer Society.

[MKG99]
Jeff Magee, Jeff Kramer, and Dimitra Giannakopoulou. Behaviour analysis of software architectures. In Proceedings of the TC2 First Working IFIP Conference on Software Architecture (WICSA1), pages 35–50, Deventer, The Netherlands, 1999. Kluwer, B.V.

[MRR03a]
S. Moisan, A. Ressouche, and J. Rigault. A Behavioral Model of Component Frameworks. Technical Report RR-5065, INRIA, December 2003.

[MRR03b]
S. Moisan, A. Ressouche, and J. Rigault. Behavioral substitutability in component frameworks: A formal approach, 2003.

[OMG05]
OMG. The OMG Unified Modeling Language Specification, version 2.0 rfp. Technical report, Object Management Group, UML 2.0 Superstructure Specification available at http://www.omg.org/docs/ptc/05-07-04.pdf, UML 2.0 Infrastructure Specification available at http://www.omg.org/docs/ptc/03-09-15.pdf, August 2005.

[PNPR05a]
S. Pavel, J. Noyé, P. Poizat, and J.C. Royer. A Java Implementation of a Component Model with Explicit Symbolic Protocols. In Gschwind et al. [GAN05], pages 115–124.

[PNPR05b]
Sebastian Pavel, Jacques Noye, Pascal Poizat, and Jean-Claude Royer. Java Implementation of a Component Model with Explicit Symbolic Protocols. In 4th International Symposium on Software Composition, SC'05, volume 3628 of LNCS. Springer, 2005.

[PP]
Radek Pospisil and Frantisek Plasil. Describing the Functionality of EJB using the Behavior Protocols.

[Pun99]
Franz Puntigam. Non-regular process types. In P. Amestoy et al., editors, Proceedings of the 5th European Conference on Parallel Processing (Euro-Par'99), number 1685 in LNCS, Toulouse, France, September 1999. Springer-Verlag.

[PV02]
F. Plasil and S. Visnovsky. Behavior protocols for software components, 2002. IEEE Transactions on SW Engineering, 28 (9), 2002.

[Reu02]
Ralf Reussner. Counter-Constrained Finite State Machines: A New Model for Component Protocols with Resource-Dependencies. In SOFSEM '02: Proceedings of the 29th Conference on Current Trends in Theory and Practice of Informatics, pages 20–40, London, UK, 2002. Springer-Verlag.

[Sch01]
Heinz Schmidt. Trusted components: Towards automated assembly with predictable properties, 2001.

[Sch03]
Heinz Schmidt. Trustworthy components-compositionality and prediction. J. Syst. Softw., 65(3):215–225, 2003.

[SR02]
Heinz W. Schmidt and Ralf H. Reussner. Generating adapters for concurrent component protocol synchronisation. In Proceedings of the Fifth IFIP International conference on Formal Methods for Open Object-based Distributed Systems, 3 2002.

[Süd05]
M. Südholt. A Model of Components with Non-regular Protocols. In Gschwind et al. [GAN05], pages 99–113.

[YS97]
D.M. Yellin and R.E. Strom. Protocol Specifications and Component Adaptors. ACM Transactions on Programming Languages and Systems, 19(2):292–333, 1997.

[ZS06]
Wolf Zimmermann and Michael Schaarschmidt. Checking of Component Protocols in Component-Based Systems. In 5th International Symposium on Software Composition, SC'06, volume 4089 of LNCS. Springer, 2006.
Voir aussi quelques références webographiques

http://www.objs.com/survey/ComponentwareGlossary.htm#ComponentProtocol
http://www.csc.ncsu.edu/faculty/xie/sequencing.htm

LINA - COLOSS - Nantes, PA version 2006
Ce document a été traduit de LATEX par HEVEA