Achieving software reuse to a significant extent has been an important goal for decades. However, as new techniques and methodologies are developed they seem invariably to fall short of' expectations. Recently, component-based software construction has been promoted as an outstanding approach in terms of software reuse. Building applications by composing software components much in the same way as we put together Lego bricks seems appealing, indeed. Unfortunately, this is not as simple as the metaphor might suggest. This paper builds on our experience in building software components for financial institutions. Most of the components have been developed in C++ and rely on Microsoft OLE/COM mechanisms for inter-component communication and interaction. OLE/COM with their extensive support for programming language independence and standard inter-component communication mechanisms go a long way in promoting componentware as a practical discipline. OLE/COM is based on a component model wherein a component appears essentially as a collection of interfaces. The interfaces expose the services provided by a component. As such they represent the essential resource for reuse. lnterface-centered reuse has been the prevailing approach since the advent of object-oriented systems. The prominent role played by the components' interfaces leads naturally to the standardization of interfaces as a way of expressing common functionality among a set of components. In this paper we explore another direction where the major role for reuse is played by protocols. A protocol is a mechanism that allows for the specification of patterns of interaction among components. Protocols have a state of execution and define the sequence of operations performed on the participating components. In order to be eligible to participate in activities governed by a protocol, components must expose interfaces that comply with the protocol's requirements. ln protocol-based systems, protocols become the unit of reuse. In fact, protocols express the dynamics of components interactions while interfaces represent components' services. So by standardizing protocols instead of interfaces we set the focus on the reuse of interaction patterns rather than the reuse of services.