Information Technology Reference
In-Depth Information
implementations, i.e., the dedicated set of executed software entities that are
required to support the execution of any component that conforms to said com-
ponent model.
There are numerous component models currently available. The main com-
peting component models today are OMG's CORBA Component Model (CCM),
Microsoft's (D)COM/COM family, and SUN Microsystems JavaBeans and
Enterprise JavaBeans. We need generally accepted component models to create a
global component market-place. It is not necessary to agree on one standard, but at
the same time there should not be too many standards. The market share of a
particular standard has to be large enough to make the development of compliant
components worthwhile. In this chapter we comment on important elements
constituting a component model (Weber et al.
2000
).
In the global software component marketplace, components are independently
deployed and subject to third-party composition. This marketplace requires stan-
dards. Standards for communication and data exchange among components from
different component producers are obvious. Such an interoperability standard,
sometimes called a wiring or connection standard, is a central element in a compo-
nent model. Other basic elements of a component model are standards for interfaces,
naming, meta data, customization, composition, evolution, and deployment.
A component model can also have specialized standards for describing domain
specific features required for certain applications. For example, the composition of
components in domains with concurrent activities requires appropriate standard-
ized threading models and synchronization mechanisms. An open distributed
processing system requires standards for remote method invocation and security.
7.4.4 The Component Concept
Although the goal of reusing elements of one system in other systems has long
been associated with the object-oriented paradigm, it really has a much longer
history. Actual reuse through object-orientation would appear to be quite difficult
to achieve. At the 'system facilities' level there are some successful examples such
as Java's Abstract Windowing Toolkit (AWT). For this type of example, reuse is
motivated both by the need to avoid rewriting major low-level elements of soft-
ware, and also by the influence of human factors, since users generally like to see a
consistent presentational style for the images on a screen, regardless of the
application producing them.
For other domains in which design is an important process, the idea of com-
ponent reuse is fairly well established, although systematic practices to support
such reuse are relatively informal. One motivation for reuse of components is that
it reduces the manufacturing costs of the final product, something that of course
does not have any parallel for software development and distribution. Indeed,
although the concept of 'product lines' appears to have become established by the
early 1900s, the adoption of manufacturing (and hence design) reuse on an
