This tutorial was writen to aid your start with component software. It does not provide complete description of component world, but it provides basic pointers for your further study of software components. In the first part I describe the basic concepts which can be found in every component system. In next three parts (2, 3, 4) you can find practical tutorials with components technologies. The last part concludes knowledge gained during practical examples a discusses what software component really is.
In the last ten years, software components gained a significant role in the software development process. Although several different specifications (usually referred to as component models) of what a software component actually is were introduced, the basic idea behind the scene is more or less the same. The main idea of the component-oriented approach is splitting the code of an application into several, well-formed pieces (usually called components), with well-defined functionality (usually called specification) and with unified access points (usually called interfaces). These terms are fundamental and we will describe them deeply in the next subsection.
Imagination of basic terms. From Bachman00
An individual component is software package or module, that encapsulates a set of related functions. Each component has its own interface, which is visible for surrounding world. Everything, what is not part of interface (objects, functions and data used for implementation) should be hidden. We call this principle the black-box model. Although black-box model of components is only ideal pattern, which is unreachable in the real world, this term is widely used. Definition of software component is not stable, but this general compliance exists:
Software component is:
* an opaque implementation of functionality * third-party composition * conformant with a component model
Component interface is part (layer) of component, which is visible from other world. It describes, what component can and what it needs for. Interface can be described either by programming language or by IDL -- Interface definition language. On the basis of interfaces of two components deployed in one environment, a contract can be established.
A component model is the set of component types, their interfaces, and, additionally, a specification of the allowable patterns of interaction among component types.
Component framework is an implementation of a component model. One framework is able to implement more models than only one. A component framework provides a variety of runtime services to support and enforce the component model(s). In many respects component frameworks are like special-purpose operating systems, although they operate at much higher levels of abstraction.
Component Development Process
In the traditional component-oriented development process, as it is usually described, we can identify multiple distinct stages on the path from an idea to a running application. Depending on a concrete component model, some of these stages can be more or less extensive or missing.
At first, in the design stage, the application is split into multiple components with well-described functionality in order to decrease the complexity. For each component, there are defined services that component provides and it will require from the surrounding environment.
This approach is repeated recursively, until the designed components are either simple and therefore can be easily implemented using a programming language (primitive components), or are already existing elsewhere and therefore can be reused. The design usually made in a Unified Modeling Language (UML) tool. Based on the created model, the component description is written. For this purpose, a variety of different description languages are used. The most of them are mutations or extensions of the Interface Description Language (IDL).
Using the description languages, interfaces are defined as sets of callable methods with parameters. Some of the description languages can also be used to define properties, constants, structures, and exceptions. The Component Description Language (CDL) can furthermore define frames and architectures. A frame is a group of multiple interfaces, where each of them is used either as a provision or as a requirement. An architecture is a "gray-box description of a component", declaring either the fact that the component is primitive or defining how the component is composed of subcomponents at the first level, considering the subcomponents only as frames.
The second stage is the development stage. In this stage, source codes for the primitive components are developed. Most of the component models can generate some source code from the component description to start-up with, either in the form of base classes that may be subclassed, or the a form of classes with empty method bodies. The compiled source code, along with a description file, constitutes a primitive component.
In the assembly stage, the primitive and the reused components are assembled into an assembly tree. The root of the tree represents the entire component (application), while the children of each node represent subcomponents of a composed component represented by the parent node. The leaves of the tree represent either primitive components or existing components that are reused.
The information that can be represented by the inner leaves is how to interconnect the interfaces of the component with the interfaces of the subcomponents. Depending on the component model, this information is created during the development stage using an architecture element, or it is created during the assembly stage.
Also, the property values can be set during this stage to provide the component with default configuration data. The information created during the assembly stage has a form of an XML file, called the assembly descriptor.
The last stage on the way to a running application is the deployment stage. In this stage, the configuration values in the assembly descriptor are customized according to the individual needs and the deployments units are configured. A deployment unit is a set of components with the same value of the location parameter, defining a reference to a server where the component will be run. The information entered during the assembly stage is again written in a form of an XML file, called the deployment descriptor.
Isolation of Components
The basic principle of CBSE is Isolation of components, it should be also named as black-box model. Implementation of component is hidden behind its interface. There is no possibility to call a functionality not present in interface.
Inversion of Control is the most typical design pattern for component systems. The basic concept of the IoC (sometimes also known as dependecy injection) is that you do not create your objects but you specify what kind of objects are you handling and somebody else will create this objects for you.
Now it is right time to start to practice with next part.