That is, a client depends upon a module to provide a service in a certain way, and the module depends upon the client to access and use these services in a certain way. It is partly in recognition of this that the idea of interface contract has become prominent in component-based research literature. To be sure, the idea of interface contract predates software component technology, but, as will be seen, it has taken on new life in this new context. For example Contracts are between two or more parties. Parties often negotiate the details of a contract before becoming signatories.
Contracts prescribe normative and measurable behaviors on all signatories.
Contracts can not be changed unless the changes are agreed to by all signatories. The third bullet has implications for component certification, and the last bullet on stable standards for building markets for components. There are no doubt other connotations as well, but these serve to motivate what contracts are about. The following discussion focuses on the first bullet, and in particular on the idea of specifying reciprocal obligations among the parties of an interaction. For example, a client depends upon the component to provide a service, and perhaps depends upon a number of extra-functional properties as well.