Interface declarations provide a basis for specifying capabilities in open systems at varying levels of precision and formality. An interface describes only those services that other components may depend on, in terms of a set of constraints (e.g., a collection of required operation signatures[8]) on a family of components, not necessarily a complete or closed (nonextensible) description of any given component. Any implementation(s) that provide requisite functionality may be used. Subtyping regimes allow one interface to be described as an extension, refinement, or specialization of one or more superinterfaces. Conversely one interface may abstract a subset of the functionality described in one or more subinterfaces. Typically, base interfaces describe only those operations that are involved in a set of related interactions, and ``fatter'' interfaces are derived via multiple inheritance[52]. At an extreme, an interface might include only a single service operation. Interface subtyping allows systems to include multiple interoperable implementations of common services, and sets of component types that specialize on common core features.
Systems constructed according to the OMG CORBA [51] model are among the best examples of interface-based development. In CORBA, component interfaces are described in CORBA IDL, an interface description language indicating only the functional properties of provided services in terms of operation signatures. Implementations are often process-level components distributed across machines, communicating via message passing mechanisms mediated by an object request broker (ORB) that directs requests to their destinations.
Roles.
While not always phrased as such, interface-based specification
intrinsically relies upon the distinction between
roles[66,59,6,18] and the components that implement
those roles. This notion follows ordinary usage distinguishing between
a role in a particular play performance (e.g., Hamlet) and the
actor or actors playing the role (e.g., Richard Burton or
Lawrence Olivier). While the term ``role'' is sometimes applied to a
description of a role rather than its instantiation, we reserve the
term ``interface'' for descriptions, and just ``role'', or for
emphasis, ``role instance'' for instantiations. A role may be thought
of as a typed, abstract access channel[63,4]
providing a subjective view[62,25] of one or
more interaction participants[33], where each view is
described by an interface.
Interface specifications deal only with roles, not implementation objects. In fact, implementations need not be conceptualized as objects in the usual narrow sense of the term. They may also consist of finer-grained instantiations (activations) of single procedures, or coarser-grained process-level components. Role-based development methods enforce an opaque layering of roles on top of implementation-level objects, in just the same sense that common object-oriented methods in turn enforce an opaque layering of objects on top of machine-level memory cells, CPUs, etc.
In classic modular development methods, there is typically exactly one implementation type per interface type and vice versa. In most object-oriented languages, there may be multiple implementation subclasses per interface. But in general, interface-based specification admits a many-to-many relationship between roles and objects: One implementation object may support several otherwise unrelated interfaces concurrently, or different interfaces across time. Conversely, one role may be implemented by several otherwise unrelated objects connected to the same channel. Each may implement a subset of operations, or redundantly implement all of them. CORBA systems support such mappings by reifying some aspects of roles as ``interface objects'' that relay messages to implementations (see Section 11).
For example, an OfficeManager role might be implemented using a Person object, or a Robot object, or a set of job-sharing Persons, or even a mechanism causing a new SpecialtyWorker object to be constructed to handle each incoming service request. A Person object might additionally play the roles (hence ``export'' the interfaces) of Parent, Driver, Customer, etc. perhaps all at the same time. Multiple roles, each seen from a different client, may be associated with the same Person implementations; for example (using boxes for roles and ellipses for objects):
