Towards Components that Plug AND Play

Component-based programming promotes a software development process where applications are built by composing reusable pieces of software, called components. This process requires a demanding form of compatibility between components, often dubbed as “Plug and Play”: Plugability refers to the syntactic compatibility between components while “playability” refers to their behavioural compatibility. In the field of distributed systems, CORBA is now established as one of the main contenders in object-oriented middleware. Beyond the definition of this standard for distributed object systems, the Object Management Group (OMG) has specified several object services (Common Object Services, COS) that can be considered as components aiming at fostering the interoperability of distributed applications. Moreover, component models dedicated to CORBA are emerging. In CORBA, “plugability” is ensured through the use of CORBA-IDL, a programming-language neutral way to describe the interface offered by components. CORBA, however, does not provide any way to ensure “playability” i.e. behavioural compatibility between components. Based on experience, the goal of this paper is to show that the OMG's style of specification of the CORBA services is not adapted to guarantee that implementers will produce interoperable and substitutable implementations. To illustrate our point, we give an account of an experiment based upon the formal specification of one COS, namely the CORBA Event Service. This formal specification highlights several ambiguities and underspecifications in the OMG document. We then test several commercial and public domain implementations of the CORBA Event Service, in order to assess how the implementers have dealt with these underspecifications. We show that the choices made by the implementers lead to incompatible implementations. Towards Components that Plug AND Play. Rémi Bastide, Ousmane Sy LIHS, Université Toulouse 1, Place Anatole France, F-31042 Toulouse CEDEX, France {bastide, sy }@univ-tlse1.fr Abstract. Component-based programming promotes a software development process where applications are built by composing reusable pieces of software, called components. This process requires a demanding form of compatibility Component-based programming promotes a software development process where applications are built by composing reusable pieces of software, called components. This process requires a demanding form of compatibility between components, often dubbed as “Plug and Play”: Plugability refers to the syntactic compatibility between components while “playability” refers to their behavioural compatibility. In the field of distributed systems, CORBA is now established as one of the main contenders in object-oriented middleware. Beyond the definition of this standard for distributed object systems, the Object Management Group (OMG) has specified several object services (Common Object Services, COS) that can be considered as components aiming at fostering the interoperability of distributed applications. Moreover, component models dedicated to CORBA are emerging. In CORBA, “plugability” is ensured through the use of CORBA-IDL, a programming-language neutral way to describe the interface offered by components. CORBA, however, does not provide any way to ensure “playability” i.e. behavioural compatibility between components. Based on experience, the goal of this paper is to show that the OMG's style of specification of the CORBA services is not adapted to guarantee that implementers will produce interoperable and substitutable implementations. To illustrate our point, we give an account of an experiment based upon the formal specification of one COS, namely the CORBA Event Service. This formal specification highlights several ambiguities and underspecifications in the OMG document. We then test several commercial and public domain implementations of the CORBA Event Service, in order to assess how the implementers have dealt with these underspecifications. We show that the choices made by the implementers lead to incompatible implementations.