Fghfg

Component Interface Pattern

Abstract
Component-oriented development establishes the building of software artifacts by means of connection of a collection of components, independently produced. The success of applying this development approach depends of the compatibility between connected component interfaces. That compatibility includes interface structural and behavioral features. ComponentInterface Pattern establishes a structure for building component interfaces that allows to evaluate and to assure the structural and behavioral compatibility between components to be connected.

Motivation
Component-oriented development is being stimulated by the availability of devices allowing component interoperability, regardless of programming language, running platform and executinglocation. However, the lack of efficient standards for specifying components difficulties the search and selection, functionality understanding and adaptation of components. In component-oriented development approach an application is produced joining a set of components. “A component is a unit of composition with contractually specified interfaces and explicit context dependencies” [SZY 96]. Acomponent can be implemented using various technologies. So any software artifact with an interface provided can be considered a component. An interface is “a collection of service access points, each of them including a semantic specification” [BOS 97]. A problem related to component-oriented development approach is how to define the external visibility of a component, that is, how to specify itsinterface. On the other hand, component users need to understand a component by means of this kind of description. So, the absence of standards to describe efficiently what a component does and how to interact with it is an obstacle for that approach. Usually, interface specification is used to describe a component. Approaches like interface description languages (IDLs) describe the services providedby a component. This is suitable for components made to supply services. Often, function signatures are enough to establish how a client accesses the functionality. A class from a library that implements a list is an example of a component that can be adequately described by means of its provided services.

Figure 1 – a software artifact built by means of component connection

Components thatjust provide services are not the general case in componentoriented development. If an application is built only with components, as shown in figure 1, one component will require the services from other components. So, it is not reasonable a component description including only provided services. Required services need to be specified too. So, in general case, component interaction isbidirectional [OLA 96].

The CORBA Component Model, CCM, part of the CORBA 3.0 specification [OMG 99], introduces an evolution to IDL view. It establishes an interface definition more complex than the traditional view, in that not only provided services are specified, but required services too, as well as required and supplied asynchronous events. Ports define the interface of a component, including:

•Facets: interface views provided by the component for client interaction; • Receptacles: connection points to required services, supplied by some external
provider; • Event sources: connection points that emit events to one or more interested event consumers, or to an event channel, in an Observer [GAM 94] approach; • Event sinks: connection points where events may be pushed, in an Observerapproach. Another component feature to describe is that a component can present more then one view. CORBA 3.0 facets show that a component can provide more than one view for external devices. This suggests more than one service access point. The service access point of a component interface is called communication channel (or just channel). figure 1 shows components with one and more than one channels...