Selección de banda y poleas

Integration vs. composition

Components are for composition. As such, practitioners have to use a composition language to specify how they want components to be composed. Such a language should provide the syntax and semantics to specify the composition details.

Component integration is the process of “wiring” components so that the needs of a component are satisfied by other components in the integration and vice-versa [Stafford 01a]. The integration often includes not only selecting suitable components, but also defining adapters, so that components which have provided and required interfaces that do not match directly can nevertheless be connected. Although the po- tential incompatibilities between components are at least partially avoided through the adoption of a component model, which defines standards to support communication between components, mismatches can nevertheless occur. For instance, component producers may have different assumptions concerning how data should be exchanged among components. If the mismatches occur during integration, we call them integra-

tion mismatches.

Component compositionadds to the notion of integration the concern on predict- ing the behavior of the component assembly, based on the properties of the assembled components. We can think of component integration as the result of using the two inner levels of Beugnard’s contracts (syntactic and semantic contracts, including the interfaces, invariants, pre and post conditions), discussed in section 2.2.1. Composi- tion is concerned about the remaining levels of the contracts: synchronization, and the definition of extra-functional properties. For instance, it may be possible to plug (integrate) a set of components in such a way that although there are no integration mismatches, behavioral mismatches may still occur. An example of such mismatch is an integration of two components that can provoke a deadlock condition, when inter- acting together. Another example is an excessive response time of the assembly.

Part of the difficulty with component composition is to select which properties we want to be able to reason about, define techniques for that compositional rea- soning, and enacting the specification, measurement and certification of those prop- erties [Stafford 01a]. None of these problems has been thoroughly solved by research in CBSE, yet.

Component integration categories

An orthogonal way of addressing component integration is to discuss the phases of the component life cycle during which integration occurs. Lau and Wang proposed an idealized component life cycle with three phases [Lau 05b, Lau 05a, Lau 07]:

• Design. In this phase, components are designed, defined and/or implemented, and, if possible, compiled into binaries.

• Deployment. In this phase, components are deployed into the target execution environment, where the component-based system under construction will run. • Runtime. In this phase, component binaries are instantiated with data, and these

instances are used within the running component-based system.

Figure 2.4 represents the three phases of the idealized component life cycle, adapted from [Lau 07]. Our adaptation considers component integration, rather than composi- tion, as we regard the latter as too restrictive for the state of the art of current compo- nent models, as we will discuss in section 2.4.

Figure 2.4: Component Life Cycle

The design phase is split into Builder and Repository, to convey the notion that while some components will be created from scratch and stored in a component repos- itory, other components already exist and can be retrieved from a component reposi- tory. The integration of two components results in a new component, in the repository (component BC, in this example). The builder corresponds to the set of tools used in developing a component. The repository is a registry, or a directory, that allows stor- ing, cataloging, searching and retrieving the components.

In the deployment phase, the component assembler tool retrieves the components from the repository, transforms them into binary code, and integrates them into a com- ponent assembly.

The component assembly is then instantiated with data in the runtime environ- ment, where the component-based system can be executed.

Depending on the adopted component model, the support to each of these phases may exist, or not. There are four typical combinations of integration mechanisms:

• design with deposit-only repository, • design with repository, or

• deployment with repository.

The design without repository category, shown in figure 2.5, corresponds to ADLs where it is possible to integrate the components in the design phase, but there is no repository for storing components, and, conversely, for retrieving them (e.g. Acme [Garlan 00b]).

Figure 2.5: Design without repository

The design with deposit-only repository category, shown in figure 2.6, applies to component models where it is possible to design components and store them into a repository, as well as to integrate components at a design stage, although it is impossi- ble to retrieve components from that repository in design time (e.g. CORBA [OMG 02a] components). In this category, it is also impossible to deposit composite components in the repository.

Figure 2.6: Design with deposit-only repository

The design with repository category, shown in figure 2.7 allows for components and composite components to be stored in and retrieved from the component repository (e.g. Koala [Ommering 04] components). As with the other categories, composition cannot be made after deployment and is only available at the design phase.

The deployment with repository category, shown in figure 2.8 includes components which can be deposited at design time in component repositories, but are only inte- grated in the deployment phase, when components are retrieved from the component repository and their instances are integrated (e.g. JavaBeans).

Figure 2.8: Deployment with repository

It should be noted that the component life cycle presented in figure 2.4 would allow other categories here (the ideal one being a component model that allows integrating components in design and deployment, as well as being able to store and retrieve com- ponents from the component repository, as discussed in [Lau 07].