According to Parnas [], an interface is an abstraction of piece of software (a software entity) which should contain a sufficient amount of information for a caller to understand and finally request the realised functionality from any entity claiming to offer the specified functionality. Note that this implies, that the specification of the interface also has to contain a sufficient amount of information for the implementer to actually implement the interface. Due to the inherent need of an interface to abstract the behaviour of the software entity not in all cases there is sufficient information provided to use or implement an interface in an unambiquious way.
This definition has several consequences. First of all, interfaces can exist on their own, i.e., without any entity requesting or implementing the specified functionality. In industrial practice, this is actually often used. For example, Sun defined for the Java programming language several sets of Java interfaces which deal with a specific sets of generic functionality without actually providing an implementation. Part of these domain-standards are the Java Messaging Standard dealing with different types of message-based communication or the Java Persistence API concerned with persisting objects in relational databases.
Second, two roles can be identified a software entity can take relative to an interface. Any entity can either claim to implement the functionality specified in an interface or to request that functionality. This is reflected in the Palladio Component Model by a set of abstract meta-classes giving a conceptual view on interfaces, entities and their relationships (see figure ). The abstract meta-class InterfaceProvidingEntity is inherited by all entities which can potentially offer interface implementations. Similarly, the meta-class InterfaceRequieringEntity is inherited by all entities which are allowed to request functionality offer by entities providing this functionality.