component model

Components enable a structuring of complex software systems. A software component is understood to be a part of a software that presents a coherent functionality via interfaces and that offers a certain independence by encapsulating its implementation. The extensive use of components has economic effects as well as effects on the applied development processes. Possible advantages include lower costs due to faster development, higher quality or better extensibility and adaptability of a software.

A component model defines a framework for the development and execution of components. In connection with the component model, the terms component environment and component architecture are still distinguished. Some well-known component models are: JavaBeans, CORBA, ActiveX/(D) COM, Enterprise JavaBeans, . NET or the component model specified by OSGi. The following explanations consider the view of a singular software component and a higher- level component model.

The term software component is often given different meanings in the literature depending on the context. For this reason, a software component is understood here in a general sense as a composite unit with contractually specified interfaces in its respective context. In this context, a software component can always be used independently of third parties and in turn can also be a component of other components. Software components have a coherent functionality and through their encapsulation in an implementation, components possess an authentic autonomy that is bound to their environment with a loose coupling. The following is a summary of the characteristics of components:

Composition Thematizes the inner structure of a component. Thereby a component can always consist of further components, which is also called containment. Since this principle can also be applied recursively top-down, it is also called containment trees.

Interfaces Here, the interaction between components and further software elements - which in turn can be components - is described. The syntax of component interfaces is often described using the Interface Definition Language ( IDL).

Connections These determine which components communicate with each other. A distinction is made here between interface adapters for adapting interfaces, asynchronous as well as push and pull connections.

Communication mechanisms are necessary for the communication between components. For example, the Javalanguage supports Remote Method Invocation ( RMI), a mechanism for communication between external components or software elements. Communication mechanisms are an important aspect in the context of components, since they influence the ability of components to be integrated into software systems. Particularly due to the Internet, the integration of applications and thus the development of communication technologies continues to advance - examples are .NET or Simple Object Access Protocol ( SOAP).

Context dependencies A component should always have a context description. This is a set of assumptions about the context in which the component will be used. These assumptions always limit the number of environments in which the component can be used. Typical assumptions can be: the use of variables and parameters, special interface types or specifications of the communication mechanism.

A term often used in connection with components is the so-called granularity. From the point of view of components, a distinction is generally made between:

• Fine-grained granularity for more passive components.
• Medium-grained granularity for active components that enable interactions and the reuse of more complex functions.
• Coarse-grained granularity for active components whose functions can be directly reused, but have complex interfaces and a complex parameterization. Also, coarse-grained components are mostly equipped with controlling or monitoring functions.

Component models define the framework for component development and execution. Through the model are determined:

• The composition and linkage of components.
• The communication and interaction of components.
• What mechanisms and services - for example, for distribution, persistence, or security - a component is provided by its infrastructure.

Accordingly, a component model must take into account the following aspects with regard to the development and use of components:

Interfaces Define the properties as well as the behavior of components and are often based on interface specification languages (IDL).

Names Unambiguous names for components, variables, interfaces, and others are agreed upon in the global environment.

Meta-data. Define services for accessing information about components and interfaces.

InteroperabilityDocument communication and data exchange between components in the heterogeneous environment of different manufacturers.

Configuration This defines the options for customization and configuration of components.

Composition Specifications for combining components into larger structures.

Evolution Rules for updating components.

Deployment Consideration of all information necessary for the distribution, installation and configuration.

A few well-known component models will be discussed in more detail here:Java Beans

• These are so-called visual manipulable Java components, whereby a Bean is implemented in each case by a class.
• The interface is designed according to the specifications.
• Mainly for GUI elements of medium granularity.
• Distribution as well as compound documents are not directly supported.

CORBA

• Common Object Request BrokerArchitecture is part of the Object Management Architecture ( OMA), was specified by the Object Management Group ( OMG) and is used in distributed, heterogeneous systems.
• Object model and Object Request Broker ( ORB) of the infrastructure are implemented( middleware).
• Interface description is defined independently of a specific programming language in CORBA-IDL (Interface Definition Language).

Enterprise JavaBeans

• Is a server-based component model that is platform-independent and intended for distributed systems.
• Is Java-specific and heterogeneous components are also possible via CORBA.
• The specification defines basic services for persistence, security and communication, among others.