IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO.

10, OCTOBER 2007 709

Software Component Models

Kung-Kiu Lau and Zheng Wang

AbstractComponent-based development (CBD) is an important emerging topic in software engineering, promising long-sought-after
benefits like increased reuse, reduced time to market, and, hence, reduced software production cost. The cornerstone of a CBD
technology is its underlying software component model, which defines components and their composition mechanisms. Current
models use objects or architectural units as components. These are not ideal for component reuse or systematic composition. In this
paper, we survey and analyze current component models and classify them into a taxonomy based on commonly accepted desiderata
for CBD. For each category in the taxonomy, we describe its key characteristics and evaluate them with respect to these desiderata.

Index TermsSoftware components, software component models, component life cycle, component syntax, component semantics,
component composition.

1 INTRODUCTION
Our analysis is based on an idealized component life
I Nsoftware engineering, component-based development
(CBD) [1], [2], [3] is an important emerging topic. CBD
aims to compose systems from prebuilt software units or
cycle [4], [5] such that, if components were constructed and
composed in the manner defined in the life cycle, then we
components. A system is developed as a composite of should be able to meet the success criteria for CBD. The
subparts rather than a monolithic entity. Such an approach definition of the idealized component life cycle is based on
reduces production cost by composing a system from the widely accepted desiderata for CBDs success [2], [3],
existing components instead of building it from scratch. It [13], [14]. These are given as follows: First, components
also enables software reuse since components can be reused should be preexisting reusable software units which
in many systems. Thus, CBD promises the benefits of developers can reuse to compose software for different
increased reuse, reduced production cost, and shorter time applications more quickly than writing all of the code from
to market, which have long been sought after by the scratch for each application. Second, components should be
software industry. To realize these benefits, it is crucial to produced and used by independent parties. That is,
have components that are easy to reuse and composition component developers need not be the same people as
mechanisms that can be applied systematically. For
component customers, such as system developers. This is
systematic composition, composites, as well as their
important for ensuring that components are truly reusable
composition, must be well defined.
The cornerstone of any CBD methodology is its under- by third parties. Third, it should be possible to copy and
lying software component model [4], [5], which defines what instantiate components so that their reuse can be max-
components are, how they can be constructed, how they can imized, both in terms of code reuse and in terms of the
be composed or assembled, and how they can be deployed, components scope of deployment. Fourth, components
as well as, ideally, how we can reason about all these should be composable into composite components which,
operations on components so that quality certification may in turn, can be composed with (composite) components into
be tractable. Current component models can largely be even larger composites (or subsystems), and so on.
divided into two categories [4], [5]: 1) models where Composition means not only reuse but also a systematic
components are objects, as in object-oriented programming, approach to system construction.
and 2) models where components are architectural units, as However, to achieve these desiderata, it would be crucial
in software architectures [6], [7]. Exemplars of these to identify the key prerequisites for component models. We
categories are Enterprise JavaBeans (EJB) [8], [9] and believe that a good starting point for this endeavor is a
architecture description languages (ADLs) [10], [11], re- study of current component models. In this paper, we
spectively. In general, current models are not ideal for present such a study. In the study, we survey the 13 major
fulfilling CBDs promise [4], [12] because they use compo- current component models, analyze them, and classify them
nents that are not easy to reuse and/or composition into a taxonomy with four categories. For each category, we
mechanisms that are not well defined and/or are hard to describe the key characteristics of the models and evaluate
apply systematically. In this paper, we will show why this is them with respect to the desiderata for CBD by the
so by analyzing these models.
idealized component life cycle. This paper thus distills
and presents a comprehensive knowledge and analysis of
. The authors are with the School of Computer Science, University of current software component models.
Manchester, Manchester M13 9PL, UK. This paper is organized as follows: In Section 2, we
E-mail: {kung-kiu, zw}@cs.man.ac.uk. define and explain the elements of software component
Manuscript received 4 Aug. 2006; revised 27 May 2007; accepted 26 June models in general and define the idealized component life
2007; published online 12 July 2007. cycle. In Section 3, we survey and categorize the 13 current
Recommended for acceptance by R. Taylor.
For information on obtaining reprints of this article, please send e-mail to:
major component models according to these elements. In
tse@computer.org, and reference IEEECS Log Number TSE-0186-0806. Section 4, we present a taxonomy based on the idealized
Digital Object Identifier no. 10.1109/TSE.2007.70726. component life cycle.
0098-5589/07/$25.00 ! 2007 IEEE Published by the IEEE Computer Society
710 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

2 SOFTWARE COMPONENT MODELS

In this section, we present a reference framework for
software component models.
Currently, there is no universally accepted terminology Fig. 1. A software component.
for CBD [13]. In particular, there are no standard criteria for
what constitutes a software component and current major 2.1 The Semantics of Software Components
component technologies do not all use the same kind of A generally accepted view of a software component is that
components. However, at present, the more widely adopted it is a software unit with provided services and required
definitions of components tend to be given without soft- services (Fig. 1). The provided services are operations
ware component models. performed by the component. The required services are
For example, the widely accepted definition by Szyperski the services needed by the component to produce the
et al. [3]: A software component is a unit of composition with provided services. The interface of a component consists of
contractually specified interfaces and explicit context depen- the specifications of its provided and required services. It
dencies only. A software component can be deployed should specify any dependencies between its provided and
independently and is subject to composition by third required services. To specify these dependencies precisely,
it is necessary to match the required services to the
parties, is not given in the context of a component model,
corresponding provided services.
and neither is the following definition by Meyer [14]: Note that, in the literature, a component can often have
A component is a software element (modular unit)
multiple interfaces, with each interface being a different set
satisfying the following conditions: of services. Here, we have used a single interface as a
1.It can be used by other software elements, its collective entity for all such interfaces.
clients. In current component models where components are
objects in the sense of object-oriented programming, the
2. It possesses an official usage description, which is
methods of these objects are the provided services. Because
sufficient for a client author to use it.
they cannot specify their required services, these objects are
3. It is not tied to any fixed set of clients. usually hosted in an environment, for example, a container,
At the same time, standard component models like EJB, which handles access to and interactions between compo-
COM [15], and CCM (Corba Component Model) [16] adopt nents. As a result, the semantics of these components is an
slightly different component definitions from standard enhanced version of that of the corresponding objects. In
ones like Szyperski et al.s and from each other. particular, they can interact with one another via mechan-
For uniformity, in this section, we present a reference isms provided by the environment.
framework for component models which defines and For example, in JavaBeans and EJB, although, syntacti-
explains terms of reference that we will use throughout cally, they are both Java classes, JavaBeans and EJB are
this paper. The definitions are general and should therefore different semantically. Semantically, a JavaBean is a Java
be universally applicable. Furthermore, by and large, they class that is hosted by a container such as BeanBox [33].
follow (what we perceive as) consensus views and therefore JavaBeans interact with one another via adapter classes
should not be contentious or controversial. generated by the container. Adapter classes link beans via
A software component model is a definition of events. An EJB, on the other hand, is a Java class that is
hosted and managed by an EJB container provided by a
. the semantics of components, that is, what compo- Java 2 Enterprise Edition (J2EE) server [34] via two
nents are meant to be, interfaces, the home interface and the remote interface, for
. the syntax of components, that is, how they are the enterprise bean. Enterprise beans interact directly via
defined, constructed, and represented, and method delegation within the EJB container and, through
. the composition of components, that is, how they are their remote and home interfaces, with remote clients, also
composed or assembled. via method delegation.
In current component models where components are
This is exemplified by Heineman and Councills defini-
architectural units, services are represented as ports. Ports on
tion of a component [2]: different units can be linked by connectors and, in a linked
A [component is a] software element that conforms to a pair of ports of connected units, the port of one unit represents
component model and can be independently deployed and not only the provided service of that unit but also the required
composed without modification according to a composition service of the other unit and vice versa. In some models, for
standard. example, UML2.0 and CCM, ports for provided services are
In this paper, we will examine the elements of 13 soft- distinguished from those for required services.
ware component models: JavaBeans [17], EJB, COM, .NET
2.2 The Syntax of Software Components
[18], CCM, Web Services [19], Koala [20], [21], KobrA [22],
Once the semantics of components has been fixed in a
SOFA [23], [24], Acme-like ADLs [10], UML 2.0 [25], [26],
component model, components can be defined and
PECOS [27], [28], and Fractal [29], [30], [31], [32]. By constructed. The definition of components requires a
necessity, we have to omit other models, but we believe that component definition language which may be distinct from
the chosen set is representative of the main categories of the implementation language, that is, programming lan-
current models. An important criterion for inclusion is that guage, for components. Clearly, for a given definition
a model should have reached a mature stage of develop- language, components can be implemented in different
ment, with sufficient documentation available. Also, by programming languages. Therefore, we refer to the syntax
necessity, we have to focus on representative models of the of components as the syntax of the component definition
categories rather than all of the models. language. In a component model, this language must be
LAU AND WANG: SOFTWARE COMPONENT MODELS 711

specified, whereas the implementation language(s) may be

left open.
In current component models where components are
classes, the definition language for components coincides
with the implementation language. For example, in both
JavaBeans and EJB, a component (respectively, a bean and
an enterprise bean) is defined as a Java class. In current
models where components are objects, the definition
language is a programming language with interface defini-
tion language (IDL) mappings. For example, COM uses
Microsoft IDL [15] and CCM uses Object Management
Group (OMG) IDL [35].
On the other hand, in component models where
components are architectural units, the definition language
is an ADL or an ADL-like language. In models with pure
ADLs being definition languages, no implementation
language is specified. Examples are Acme [36] and
UML2.0. In models with ADL-like languages being defini- Fig. 2. An idealized component life cycle.
tion languages, the implementation language is different
from the definition language. For example, in Koala, the Of course, it is possible to consider a different system
definition language is CDL and the implementation construction process, in particular one where the system
language is C. In PECOS, the definition language is CoCo can be dynamically constructed or reconfigured at runtime,
and the implementation language is C++ or Java. for example, [43]. We choose not to follow this process,
primarily because it demands binary-level composition for
2.3 The Composition of Software Components component instances, for which it is hard to define
In CBD, composition is a central issue since components are meaningful composition operators other than glue code.
supposed to be used as building blocks from a repository Ideally, composition should be possible in both the
and assembled or plugged together into larger blocks or design and the deployment phases of the component life
systems. Typically, components are hosted by servers and, cycle while the system is being constructed. Composition
so, composition takes place on the server side. Client means component reuse and, therefore, composition in both
applications are built from server-side components, as phases will maximize reuse. It also means design flexibility
exemplified by Web service orchestration [37]. in the sense that the deployed components, in particular
In order to define composition, we need a composition composite components, can be designed, by composition, in
language, for example, [38]. The composition language either phase.
should have suitable semantics and syntax that are compa- Accordingly, we have defined an idealized component
tible with those of components in the component model. In life cycle [5], [12] and the kind of composition that is
most of the current component models, there is no composi- possible and meaningful in both phases.
tion language. JavaBeans, EJB, COM, .NET, and CCM have no
composition languages. Web Services are composed by 2.3.1 An Idealized Component Life Cycle
orchestration, typically using a workflow language like The idealized life cycle is depicted in Fig. 2. This is based on
Business Process Execution Language (BPEL) [39]. Koala the commonly accepted desiderata of CBD [2], [3], [13], [14],
uses connectors as glue code for composition. KobrA and as described in Section 1. That components should be
UML2.0 use the UML notation. ADLs are, of course, formal preexisting reusable software units necessitates the use of a
composition languages [40] and PECOS has an ADL-like repository in the design phase. That components should be
composition language CoCo (which doubles as the CDL). produced and used by independent parties requires the use
In order to reason about composition, we need a of builder and assembler tools that can interact with a
composition theory (see the discussion in [41]). Such a repository in the design and deployment phases, respec-
theory allows us to calculate and, thus, predict the result of tively. That it should be possible to copy and instantiate
applying a composition operator to components. Current components means that components should be distin-
component models tend not to have composition theories, guished from their instances and, therefore, we distinguish
even those with a composition language. the design and deployment phases from the runtime phase.
Composition can take place during different stages of That it should be possible to compose components into
the life cycle of components [42], namely, 1) the design composite components, which, in turn, can be composed
phase, during which components are designed, defined, with (composite) components into even larger composites
and constructed in the source code, and possibly compiled (or subsystems), and so on, requires that composites can be
into binaries, 2) the deployment phase, during which deposited in and retrieved from a repository, just like any
binaries of components are deployed into the target components. All current component models attempt to
execution environment for the system under construction, meet these criteria, with varying degrees of success, as we
and 3) the runtime phase, during which component binaries will show later.
are instantiated with data and these instances are executed
in the running system. 2.3.2 Composition in the Design Phase
This life cycle is distinct from but embedded in the system In the design phase, components have to be constructed,
construction process that we have assumed. By the deploy- cataloged, and stored in a repository. The main requirement
ment phase of the component life cycle, we assume that the for a repository is that it should provide storage and
system has already been constructed in a component-based management for depositing and retrieving the components.
manner, with placeholders for the selected components. A repository could be a registry or a directory, but it must
712 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

Fig. 3. Categories based on composition.

store and catalog the deposited components with suitable assemblies. With reference to Fig. 2, a container may be a
identities and provide a search facility for retrieving these repository (in the design phase) and a runtime environ-
components. ment, for example, the EJB container. Alternatively, it may
In the idealized life cycle, components in the repository be an assembler and a runtime environment, for example,
are in source code or they may have been compiled into the BeanBox in JavaBeans.
binary. They can be retrieved and composed into a
composite that is, in turn, deposited into the repository. A
new composite has a unique identity which enables the 3 CURRENT SOFTWARE COMPONENT MODELS
composite to be retrieved subsequently. In this section, we survey existing software component
A builder tool (Fig. 2) can be used to 1) construct new models. Rather than discussing them in some random
components and then deposit them in the repository, for sequential order, we survey the models in meaningful
example, A in Fig. 2, and 2) retrieve components from the groups. Clearly, we can group the models according to
repository, compose them, and deposit them back in the component semantics, syntax, or composition. However,
repository. For example, in Fig. 2, B and C are composed since composition is a key issue in CBD, we focus on
into a composite BC that is deposited in the repository. groupings based on composition. We present four such
For example, in JavaBeans, the container provides a categories that cover the 13 models and, for each category,
repository for beans, for example, ToolBox in the BDK we explain a representative model in detail, with an
(Beans Development Kit) [33], [44], which are stored as JAR example, but only outline the other models (in the
files. However, no composition is possible in the design Appendix) for completeness.
phase and, therefore, no composite beans can be formed. To define categories based on composition, we consider
composition in an ideal life cycle, as described in Section 2.3
2.3.3 Composition in the Deployment Phase (Fig. 2), that provides a basis for comparing and classifying
In the deployment phase, components have to be retrieved composition in existing component models. For instance,
from the repository and compiled to binary code. These some component models do not have composition in the
binary components can be composed into a system that will be design phase, whereas some models do. Some have composi-
executable once the binaries have been instantiated with data. tion in the deployment, whereas some do not. Thus, many
An assembler tool (Fig. 2) can be used to retrieve categories are possible. Fig. 3 gives four categories that cover
components from a repository and, if necessary, compile all 13 major existing component models.
them into binary code, then assemble them into a system. In Category 1, in the design phase, there is no repository.
For example, in Fig. 2, binaries of A, B, D, and BC are Therefore, components are all constructed from scratch.
created and composed into a system. In the runtime phase, Composition is possible. In the deployment phase, no new
the system is executable in the runtime environment once composition is possible: The composition of the component
the binaries of A, B, D, and BC are instantiated with data. instances (in the runtime phase) is the same as that of the
The result of the deployment phase composition is a components in the design phase. All simple Acme-like
whole system in binary code; thus, this is the end result of ADLs belong to this category, as do models such as
system design and implementation and, therefore, systems UML2.0, PECOS, and Fractal, which are based on Acme-
should not be stored in the repository. like ADLs. This category can be described as Design
For example, in JavaBeans, in the deployment phase, without Repository.
bean instances are created from beans in the repository and In Category 2, in the design phase, new components can
these can be composed (linked) graphically by using the be deposited in a repository but cannot be retrieved from it.
builder tool. Composition is possible, that is, composites can be formed,
Finally, it is worth pointing out that, although they do not but composites cannot be retrieved from the repository
figure explicitly in Fig. 2, containers play an important part in because they do not have identities of their own. In the
the component life cycle. Indeed, they are considered to be deployment phase, no new composition is possible: The
implementations of component models in that they provide composition of the component instances (in the runtime
an execution environment for components and their phase) is the same as that of the components in the design
LAU AND WANG: SOFTWARE COMPONENT MODELS 713

Fig. 4. An Acme component.

phase. This category includes EJB, COM, .NET, CCM, and

Web Services. It can be described as Design with Deposit-
only Repository.
In Category 3, in the design phase, new components can
be deposited in a repository but cannot be retrieved from it.
Composition is not possible in the design phase, that is, no
composites can be formed and, so, no composites can be
deposited in the repository. In the deployment phase,
components can be retrieved from the repository and their Fig. 5. Examples of Acme components.
binaries can be formed and composed. The sole member of
this category is JavaBeans. This category can be described as
Deployment with Repository.
In Category 4, in the design phase, new components can
be deposited in a repository and components can be
retrieved from the repository. Composition is possible and
composites can be deposited in the repository. In the
deployment phase, no new composition is possible: The Fig. 6. Acme connectors.
composition of the component instances (in the runtime
phase) is the same as that of the components in the design
phase. Koala, SOFA, and KobrA belong to this category.
This category can be described as Design with Repository.

3.1 Category 1: Design without Repository Fig. 7. Architecture of bank system in Acme.
This category includes all simple Acme-like ADLs, UML2.0,
PECOS, and Fractal. Acme is the representative example in created by connecting the components, possibly using a
this category since all the of other models are based on visual builder tool, for example, AcmeStudio [45] for Acme.
Acme-like ADLs. For example, in Acme, the architecture for the bank system
In Acme, as in any ADL [10], [11], a component is an is defined graphically in Fig. 7, where BC stands for
architectural unit (a box) that represents a primary computa- BankConsortium and B1 and B2 stand for Bank1 and
tional element and data store of a system (Fig. 4). The Bank2, respectively. The components are those specified in
interface of a component is defined by a set of ports, Fig. 5 and the connectors are specified in Fig. 8. The
through which the components functionalities are exposed. specification for the architecture is defined in Fig. 9. The
Each port identifies a point of interaction between the connections are defined by a set of attachments. Each
component and its environment. A port can have different attachment represents an interaction between a port (of a
roles, such as sink (receive) and source (send). connector) and some role of a connector.
Components and their ports can have different types. In ADLs, in general, after the design phase comes the
These types can be defined in a family of type definitions runtime phase, that is, there is no deployment phase
which define the design vocabulary of a system. Both
(Fig. 3). However, the implementation of components and
functional and extrafunctional attributes of a component
connectors is not always specified. Therefore, the imple-
can be specified by property types defined in that component.
mentation of the architecture is a separate activity from its
Consider a simple bank system which has just one ATM
design and has to be done manually somehow in some
that serves one bank consortium with two bank branches,
Bank1 and Bank2. In Acme [36], the bank system can be programming language. The implementation is then exe-
implemented using the ATM, BankConsortium, Bank1, and cuted in the runtime environment for the chosen program-
Bank2 components, as shown in Fig. 5. Components ATM, ming language.
BankConsortium, Bank1, and Bank2 specify their ports and In Acme, system specifications constructed in the design
Bank1 and Bank2 specify their bank identity properties. phase can be compiled to a system in a programming
In Acme, again, as in any ADL, components are language directly, provided that the code for the compo-
composed of connectors (lines) that mediate the commu- nents and connectors is available in that language. For
nication and coordination activities among components example, in Acme, architectures can be specified in
(boxes; see Fig. 6). A connector can connect two or more ArchJava [46], [47] and can be compiled into Java, provided
components. Similarly to components, connector interfaces that the Java code for the components and the connectors is
are defined by sets of roles. Each role defines a participant available [48]. The compiled system is then run on the Java
of the interaction represented by the connector. A connector Virtual Machine.
may have multiple interfaces by using different types of The other models in this category, UML2.0, PECOS, and
roles. The types of connectors and their roles may be Fractal, are outlined in Appendix A.1. In these models, the
defined as a family. Both connector and role attributes can builder is a programming environment which is often a
be specified by property types defined in that connector. visual builder tool like AcmeStudio for the Acme ADL,
In Acme, there is no repository for components. In the whereas the runtime environment is usually that for the
design phase, components and connectors have to be implementation language, for example, the Java Virtual
constructed from scratch. The system architecture is then Machine for Fractal.
714 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

Fig. 8. Examples of Acme connectors.

Fig. 10. Example of entity bean.

As an example, consider a bookstore that wishes to

maintain a database of its book stock. Suppose books can be
purchased and have their details added to the database by
any shop assistant. Then, the bookstore can use a set of
enterprise beans to implement a system that allows multiple
clients to access and update the database.
An entity bean, like the one in Fig. 10, can represent the
table of books in a database. This entity bean consists of one
class and two interfaces: 1) BookBean is the Java class that
defines the methods of the entity bean, 2) BookHome is the
home interface of the entity bean, and 3) Book is the remote
Fig. 9. Example of component composition in Acme. interface of the entity bean. Each instance of this entity bean
represents a row of the table of books in a database.
Methods defined in the home interface BookHome are life-
3.2 Category 2: Design with Deposit-Only cycle methods: create and findByPrimaryKey. Thus, the
Repository home interface helps create an instance of this entity bean
This category includes EJB, COM, .NET, CCM, and Web and locate an instance of BookBean by its primary key
Services. The representative example is EJB. (isbn). Methods in BookBean correspond to methods
In EJB [49], [50], a component is an enterprise bean, which defined in both the home interface BookHome and the
is a Java class that is hosted and managed by an EJB remote interface Book.
container provided by a J2EE server. An EJB container A session bean, like the one in Fig. 11, can be used to add
manages the execution of enterprise beans and handles details of a set of books into the table of books in the
security, transaction management, Java Naming and Direc- database. This session bean consists of the class Book-
tory Interface (JNDI) lookups, and remote connectivity. StoreBean, the home interface BookStoreHome, and the
The Java class for an enterprise bean defines the methods remote interface BookStore (and its helper class Books). The
of the bean. It must be accompanied by code for two only method defined in the home interface BookStoreHome
interfaces, the home interface and the remote interface, that the of BookStoreBean is a life-cycle method: create. The only
EJB container uses to manage and run the bean. These method defined in the remote interface BookStore of
interfaces expose the capabilities of the bean and provide all BookStoreBean is a task performed to add details of a set
of the methods needed for client applications to access the of books into the database: addBook. As in an entity bean,
bean. The home interface represents the life-cycle methods methods in a session bean correspond to methods in its
of the bean, such as create, destroy, and locate a bean instance, home and remote interfaces.
whereas the remote interface represents the tasks per- In general, enterprise beans are Java classes and
formed by the bean.
interfaces and bean composition is by delegation of method
There are three different kinds of enterprise beans [49]:
entity beans, session beans, and message-driven beans. Entity calls. In the design phase, enterprise beans can be
beans model business data: An entity bean represents a constructed in a Java programming environment such as
persistent business object whose data is stored in a Eclipse [51] and their JAR files containing the enterprise
database. Session beans model business processes: A bean implementation class, the home and remote interfaces,
session bean represents a business process or an agent that and the deployment descriptor are deposited in an EJB
performs a service. Message-driven beans model message- container on a J2EE server that is the repository of
related business processes: A message-driven bean repre- enterprise beans.
sents a business process that can only be triggered by The EJB container in Fig. 12 shows an example of the design
receiving messages from other beans. phase composition of two session beans, SessionBeanA and
LAU AND WANG: SOFTWARE COMPONENT MODELS 715

Fig. 13. Example of EJB composition.

the BookStoreBean. Then, the BookStoreClient calls the

addBook method defined in the remote interface Book-
Fig. 11. Example of session bean. Store of the BookStoreBean. Within this call, the Book-
StoreBean adds books by iteratively calling the method
create defined in the home interface BookHome of the
BookBean, which returns instances of the remote interface
Book of the BookBean. Then, the BookStoreBean calls the
set methods defined in the remote interface Book of the
BookBean to set BookName, Author, Publisher, and Price of
these books iteratively, resulting in rows of books inserted
into the table books.
The other models in this category, COM, .NET, CCM,
and Web Services, are outlined in Appendix A.2. In these
models, the builder is usually a programming environment,
like Eclipse for EJB, the deposit-only repository is either a
container, like the EJB container and the CCM container, or
a server, like the COM server, the Windows server for .NET,
Fig. 12. Composition of Enterprise JavaBeans. and Web servers for Web Services.

SessionBeanB, and one entity bean, EntityBean. Session- 3.3 Category 3: Deployment with Repository
BeanA takes client calls, and EntityBean writes to the This category contains only JavaBeans.
database. In JavaBeans [17], a component is a bean, which is just
In the design phase, although bean composition can any Java class that has methods, events, and properties. A bean
produce composite beans on the fly in the EJB container, is intended to be constructed and manipulated in a visual
it is not possible to retrieve such a bean and reuse it as a builder tool.
single bean for further composition. However, individual For example, consider a simple bean MessageBox, which
beans in the container in the design phase are reusable in is a Java class that has a method for displaying a message,
the sense that every bean is accessible to clients in the mouse events such as mousePressed, and the message
deployment phase, regardless of what other beans it is that it displays is a property of the bean.
linked to, and, whatever method a client calls, the correct Properties are local to a component, so these do not
links will automatically be followed. figure in the beans interface. Events can be source or target
Thus, although it is a repository for enterprise beans that
events. Source events in one bean can trigger (target)
supports the design phase composition, the EJB container
methods in another bean. More precisely, an event listener
does not support the storage or retrieval of composite
(for a target event) in a bean, when notified by an external
components as identifiable units. The reason is that the
container is also the execution environment for beans. source event (that is, a source event in another bean),
In EJB, after the design phase comes the runtime phase. triggers a corresponding method in the bean. Thus, in a
Thus, no new composition is possible after the design phase bean, target events and methods are provided services in
(for example, see [52]). In the runtime phase, bean instances the beans interface and external source events are the
are created and executed in the EJB container. required services, that is, required services are event sinks.
Consider the bookstore example again. In the design Individual JavaBeans are constructed in a Java program-
phase, an assembly of the session bean BookStoreBean and ming environment such as Java Development Kit and
the entity bean BookBean is deposited into the EJB deposited in the ToolBox of the BDK [33], [44], which is the
container. The composition is defined by BookStoreBean repository for JavaBeans. To execute or compose JavaBeans,
calling the methods create and set defined in the home the beans have to be dragged into a container like BeanBox.
interface BookHome and the remote interface Book of More precisely, for each bean, a JAR file containing the bean
BookBean (Fig. 13). implementation class, the event state object, and the event
In the runtime phase, this system is looked up and listener interface are deposited in the ToolBox of BDK.
instantiated. In this instance of the system, the Book- Binaries of a bean can be dragged from the ToolBox,
StoreClient calls the method create defined in the home composed, instantiated, and executed in the BeanBox.
interface BookStoreHome of the BookStoreBean, which Although the ToolBox acts like a repository, it does not
returns an instance of BookStore, the remote interface of support composition of beans. Thus, the only composition
716 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

Fig. 14. Composition of JavaBeans. Fig. 15. Example of composition of JavaBeans.

possible in JavaBeans is the composition of beans in the

deployment phase.
Deployment phase composition is handled by the Java
delegation event model, which specifies how a bean sends a
message to other beans without knowing the exact methods
that the other bean implements. To compose two chosen
JavaBean instances in BeanBox, one bean instance must act Fig. 16. A Koala component.
as a source bean that can generate a source event and a
method must be chosen in the other (target) bean instance,
In Koala, a component can have multiple interfaces
which will be triggered by the source event. Of course, the
implementing different functions and is represented in
target method of the target or listener bean must match the
event type of the source beans method. The communication Fig. 16. Each interface specifies the signature of the function
between the source and target beans is indirect, but this is that it implements and is represented as a square containing
handled by BeanBox automatically: BeanBox generates, a triangle. The tip of the triangle represents the direction of
compiles, and loads an event adapter class which routes that function call.
messages from the source bean to the target bean to connect For example, consider a Stopwatch device that is used to
the source beans event to the target beans event handler count down from a specific number, for example, 100. The
method (Fig. 14). Stopwatch device is comprised of a Countdown component
Consider the composition of two beans, MessageBoxA and a Display component (Fig. 17). The interfaces of the
and MessageBoxB. In the design phase, these two beans are Countdown and Display components are specified in Koala
developed and deposited into the ToolBox of BeanBox. No IDL and their component definitions are in Koala CDL. The
composition is possible at this stage. In the deployment ICount interface of the Countdown component specifies the
phase, suppose an instance of MessageBoxA (Bean A is signature of the function count that the Countdown
created with the property Hello, Im bean A) and an component implements. The Countdown component defini-
instance of MessageBoxB (Bean B is created with the tion defines its provides interface ICount and its implementa-
property Hello, Im bean B) by dragging MessageBoxA tion c_impl. The ICount and ISignal interfaces of the
and MessageBoxB from the ToolBox. To compose beans A Display component specify the signatures of the functions
and B, we choose bean B to be the event source and Bean A count and display that the Display component imple-
to be the event target and we choose a source event ments. The Display component definition defines its requires
mousePressed in bean B. Next, bean B is linked to bean A and provides interfaces and its implementation d_impl.
and a target event or method in bean A showText is Koala components definition files are deposited in a
chosen which will be a listener for the source event that has repository, namely, the KoalaModel WorkSpace, which is a
been selected in bean B. BeanBox effects this composition by file system. In the design phase, Koala components are
automatically generating and compiling an adapter class
composed by method calls through connectors. There are
that connects beans A and B (Fig. 15). More precisely,
three kinds of connectors: binding, glue code, and switch.
BeanBox creates a class that calls the showText method in
bean A whenever the event mousePressed occurs in . Binding is used to connect the requires interface of a
bean B. It then associates the source and target beans with component to a provides interface of the same type
this adapter object. Therefore, when bean B is selected, of another component.
and the mouse is pressed, bean A displays the message
Hello, Im bean A. . Glue code serves as an adapter that connects the
requires interface of a component to a provides
3.4 Category 4: Design with Repository interface of a different type of another component.
This category includes Koala, SOFA, and KobrA. The . Switch is special glue code that switches binding
representative example is Koala. between components.
In Koala [20], [21], a component is a unit of design which Any combination of components is, again, a component;
has a specification and an implementation. Semantically, that is, the combination of components is a composite
Koala components are units of computation and control component. A composite component is represented as in
(and data) connected in an architecture. Therefore, syntac- Fig. 18. Connector binding is represented as a line, glue
tically, Koala components are defined in an ADL-like code is represented as a node, with m for modules, and a
language, namely, Koala, consisting of an IDL for defining switch connector is represented as a switch node.
component interfaces, a CDL for defining components, and In Koala, composite components can be deposited back
a Data Definition Language (DDL) for specifying local data into the repository.
in components. Koala component definitions are compiled In the deployment phase, Koala components are com-
by the Koala compiler to their implementation in a piled into binaries of a programming language, for
programming language, for example, C. example, C. However, no new composition of component
LAU AND WANG: SOFTWARE COMPONENT MODELS 717

Fig. 18. Component composition in Koala.

Fig. 19. A stopwatch device.

Fig. 17. Example of Koala components.

binaries is possible. In the runtime phase, component Fig. 20. Example of component composition in Koala.
instances are executed in the runtime environment of the
chosen programming language. these categories are more meaningful than those based on
Consider the Stopwatch device again. In the design phase, component semantics or syntax.
the Stopwatch device (Fig. 19) is being implemented by
constructing a new Countdown component and composing it 4.1 Categories Based on Component Semantics
with a Display component from the repository. The definition Based on semantics, current component models can be
files for the Display component are retrieved from the grouped into three categories: 1) component models in
repository (definition files contain the definitions of inter- which components are classes, 2) models in which
faces, components and data). Then, the definition files for the components are objects, and 3) those in which components
Countdown component are constructed. Using their defini- are architectural units (Fig. 21).
tion files, Countdown and Display are composed by method Component models that belong to 1) are JavaBeans and
calls. This yields a definition file for Stopwatch (Fig. 20). The EJB since, semantically, components in these models are
definition files for Countdown and Stopwatch are deposited special Java classes, that is, classes hosted by containers.
into the KoalaModel WorkSpace. In the deployment phase, Component models that belong to 2) are COM, .NET,
the definition files of Stopwatch Countdown and Display are CCM, Web Services, and Fractal since, semantically,
compiled by the Koala compiler to C header files. Then, the components in these models are runtime entities that behave
programmer has to write C files and compile these with the like objects. In COM, a component is a piece of compiled
header files to binary C code for Stopwatch. code that provides some services which is hosted by a COM
In general, the Koala component model is used to build a server. In .NET, a component is an executable DLL that is
product population for consumer electronics from reposi- hosted by a Common Language Runtime (CLR). In CCM, a
tories of preexisting components, that is, product lines. component is a Corba metatype that is an extension and
The other models in this category, that is, SOFA and specialization of a Corba object which is hosted by a CCM
KobrA, are outlined in Appendix A.3. In these models, the container on a CCM platform such as OpenCCM. In Web
builder is a programming environment, that is, SOFANode Services, a component is a piece of binary code that provides
for SOFA and the UML Visual Builder tool for KobrA, the some services which is hosted by a Web server. In Fractal, a
repository is a file system, for example, the Template component is an object-like runtime entity in languages with
mappings from the chosen IDL.
Repository for SOFA, and the runtime environment is that
Component models that belong to 3) are Acme-like
of the implementation language.
ADLs, UML2.0, KobrA, Koala, SOFA, and PECOS. Seman-
tically, components in these models are units of computa-
4 A TAXONOMY tion and control (and data) connected in an architecture. In
ADLs, a component is an architectural unit that represents a
In this section, we propose a taxonomy for the 13 component primary computational element and data store of a system.
models described in the previous section (and in the In UML2.0, a component is a modular unit of a system with
Appendix). Clearly, such a taxonomy could be based on well-defined interfaces which is replaceable within its
component semantics, syntax, or composition. We will base environment. In KobrA, components are UML components.
the taxonomy on composition, following the categories In Koala, SOFA, and PECOS, a component is a unit of
defined in the previous section, and we will argue why design which has a specification and an implementation.
718 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

Fig. 21. Categories based on semantics.

Fig. 22. Categories based on syntax.

4.2 Categories Based on Component Syntax However, comparing these two groups with the cate-
Based on component syntax, current models fall into three gories based on composition in the component life cycle
categories: 1) models in which components are defined by (Fig. 3), it is clear that there is no meaningful way of
object-oriented programming languages, 2) those in which an merging the former with the latter. Of the object-based
IDL is used and in which components can be defined in group of the former, EJB, COM, .NET, CCM, and Web
programming languages with mappings from the IDL, and Services belong to different categories from JavaBeans and
3) those in which components are defined by ADLs (Fig. 22). from Fractal in the latter. Of the architecture-based group of
Component models that belong to 1) are JavaBeans and the former, KobrA, Koala, and SOFA belong to different
EJB, where components are implemented in Java. categories from Acme-like ADLs, UML2.0, and PECOS in
Component models that belong to 2) are COM, .NET, the latter. Conversely, the categories based on composition
CCM, Web Services, and Fractal. These models use IDLs to are not simply divided between object-based models and
define generic interfaces that can be implemented by architecture-based models. For example, in these categories,
components in specific programming languages. COM Fractal, which is object-based, belongs to the same category
and .NET use the Microsoft IDL [15], CCM uses the OMG as the architecture-based models Acme-like ADLs, UML2.0,
IDL [35], and Web Services use Web Service Description and PECOS.
Language (WSDL), whereas Fractal can use any IDL. In view of this, we believe that the only meaningful
Component models that belong to 3) are Acme-like taxonomy is one based on composition in the idealized
ADLs, UML2.0, KobrA, Koala, SOFA, and PECOS. component life cycle. Composition is the central issue in
Obviously, in all ADLs, components are defined in ADLs. CBD after all. Moreover, in the idealized life cycle,
In UML2.0 and KobrA, the UML notation is used as a composition takes place in both the design and deployment
kind of ADL and components are defined by UML phases. By contrast, object-based models and architecture-
diagrams. In Koala and SOFA, components are defined
based models tend to be heavily biased toward one phase or
in ADL-like languages. In PECOS, components are
the other. In object-based models like COM, .NET, CCM,
defined in CoCo, which is essentially an ADL, too.
and Fractal, components are objects that are executable
The main difference between these categories is that
components in 1) and 2) are directly executable in their binaries and are therefore more of deployment phase
respective programming languages, whereas components entities than design phase entities. On the other hand, in
in 3) are only specifications which have to be implemented architecture-based models such as UML2.0, components are
by somehow using suitable programming languages. expressly design entities by definition, with or without
binary components in the deployment phase.
4.3 A Taxonomy Based on Composition Thus, we propose the taxonomy of software component
We have seen three groupings of categories based on models shown in Fig. 23 based on component composition
component semantics, syntax, and composition. The question in the idealized component life cycle, as discussed in
is whether it is possible or meaningful to combine them into a Section 3. The categories are the same as those in Fig. 3, but
single taxonomy. Looking at the categories based on Fig. 23 shows more details about their characteristics.
semantics (Fig. 21) and those based on syntax (Fig. 22), it is In Fig. 23, the first four columns of characteristics are
obvious that they can be merged straightforwardly into two design phase characteristics, whereas the last one refers to
groups: the deployment phase characteristics. In the design phase,
Deposit-N stands for new components can be depos-
. Object based: JavaBeans, EJB, COM, .NET, CCM, ited in a repository, Retrieve stands for components
Web Services, and Fractal. can be retrieved from the repository, Compose stands
. Architecture based: Acme-like ADLs, UML2.0, for composition is possible, and Deposit-C stands for
KobrA, Koala, SOFA, and PECOS. composite components can be deposited in the
LAU AND WANG: SOFTWARE COMPONENT MODELS 719

Fig. 23. A taxonomy based on composition.

repository. In the deployment phase, Compose stands therefore focused on designing (systems and) components
for composition is possible. from scratch rather than reusing existing components.
In the Design without Repository category, in the design Models in the other two categories are middle of the
phase, there is no repository for components. Therefore, road. They also use repositories, but they behave differ-
neither new components can be deposited nor can existing ently from those in the Design with Repository category in
components be retrieved from a repository. Consequently, that the former store binary compiled code, whereas the
components are all constructed from scratch. However, latter store units of design in the repository, which are more
composition is possible. In the deployment phase, since no generic and, hence, more reusable.
repository is available, no new composition is possible. The taxonomy also reveals that no existing model has
In the Design with Deposit-only Repository category, in composition in both the design and the deployment phases.
the design phase, new components can be deposited in a No model can retrieve composites for further composition
repository but cannot be retrieved from it. Composition is in the deployment phase, not even those in the Design with
possible, that is, composites can be formed, but composites Repository category. That is, the ideal category would be
cannot be deposited in (and, hence, retrieved) from the Design and Deployment with Repository, but this does
repository. In the deployment phase, no new composition is currently not exist. Thus, there is room for improvement
possible. and better component models are possible. Indeed, the
In the Deployment with Repository category, in the taxonomy that we have presented in this paper has been
design phase, new components can be deposited in a used by other researchers to evaluate and improve their
repository but cannot be retrieved from it. Composition is component models, for example, [54].
not possible in the design phase, that is, no composites can Apart from adding composition and repository to both the
be formed, and, so, no composites can be deposited in the design and deployment phases, there are two other important
repository. In the deployment phase, components can be issues: 1) how components that are easy to reuse can be
retrieved from the repository and their instances can be designed and 2) how composition mechanisms that will
formed and composed. enable systematic composition can be designed. On both
In the Design with Repository category, in the design points, current component models do not perform well. All of
phase, new components can be deposited in a repository the models (where components are either objects or archi-
and components can be retrieved from the repository. tectural units) use message passing as the composition
Composition is possible and composites can be deposited in mechanism: Objects communicate by direct message passing,
the repository. In the deployment phase, no new composi- whereas architectural units use indirect message passing.
tion is possible: The composition of the component Message passing relies on and induces close coupling
instances is the same as in that of the components in the between components. This hampers component reuse, in
design phase. particular the reuse of composite components.
Current models also do not have well-defined composi-
tion theories that support systematic composition. Objects
5 DISCUSSION do not have a composition theory: The composition of
The basis for the taxonomy in Fig. 23 is the idealized two objects by direct message passing is not supported by a
component life cycle, which is based on the commonly composition theory and the result is not a single object but
accepted desiderata of CBD, as discussed in Section 2.3. It is just the two objects calling each others methods. Archi-
interesting to note that models in the Design with tectural units compose via their ports and have a simple
Repository category meet the requirements of the idealized composition theory. However, this theory does not support
life cycle better than the other categories. This is not systematic composition. In particular, it is usually defined
surprising since Koala and KobrA use product line at the level of ports and used for type checking connected
engineering, which has proved to be the most successful ports [47] rather than at the level of whole components, in
approach for software reuse in practice [53]. The main particular composite components.
reason for its success is precisely its use of repositories of We believe that to overcome these problems, compo-
families of preexisting components, that is, product lines. nents should have the key properties of encapsulation and
At the other end of the scale, models in the Design compositionality and we have formulated such a component
without Repository do not perform so well, mainly model [55], [56]. Our model improves reuse and defines
because they are based on Acme-like ADLs and are composition hierarchically. Components encapsulate their
720 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

own data, control, and computation and their composition

results in composites that preserve encapsulation. Encap-
sulation makes reuse easier because it removes coupling
between components. Composition that preserves encapsu-
lation leads to composite components being self-similar to
their subcomponents. Consequently, composition is hier- Fig. 24. A UML component.
archical in our model.
Objects and architectural units are both lacking in
encapsulation and compositionality. Objects encapsulate
data but not control or computation. They are not
compositional. Architectural units are compositional and
can encapsulate data, but they do not encapsulate control or Fig. 25. Component composition in UML.
computation.
Encapsulation has the potential to counter complexity. In
our model, encapsulation occurs at every level of composi-
tion and it encapsulates every composite into just an
interface. This interface is all we need to know about the
Fig. 26. A PECOS component.
composite in order to use it for further composition. This
means that we can encapsulate much larger composites at
each step and, by so doing, we are able to subsequently provided service by a lollipop (Fig. 24). Components can be
compose much larger composites without regard to their constructed in a visual builder tool such as Visual UML.
size or complexity. In the design phase, UML2.0 components are composed
Finally, we have not included our model in this survey of UML connectors (Fig. 25). There are two kinds of
because it has not yet reached a mature stage of development. connectors:

. An assembly connector (lollipop in socket) is used to

6 CONCLUSION connect the required interface of a component to the
provided interface of another component.
In this paper, we have presented a survey of software
. A delegation connector (arrow) is used to forward
component models. As far as possible, we have tried to use
requested and provided services from inside the
a unified terminology in the context of an idealized scenario
environment of a composite component to outside
for CBD. We have deliberately avoided adopting terminol-
the component.
ogy from any one component model. For example, we use
the term builder in the design phase and the term Like ADLs, there is no deployment phase and imple-
assembler in the deployment phase to refer to composi- mentations of the components and connectors in the system
tion tools in these phases rather than builder tools that are constructed in the design phase have to be constructed
specific to any component models because the latter do not manually somehow. Some tools can perform code genera-
follow a unified terminology. tion from UML2.0 specifications. Either way, the imple-
We have proposed a taxonomy by generalizing from mented system is executed in the runtime environment for
software component models that we have examined and the chosen programming language.
compared. The taxonomy clearly reveals the characteristics
of categories of existing component models with regard to A.1.2 PECOS
the desiderata of CBD. Thus, it shows what desirable In PECOS [27], [28], a component is a unit of design which
features a component model should have in order to has a specification and an implementation. The inputs and
achieve these desiderata. outputs of a component are represented as ports (Fig. 26).
The ideal model does not yet exist. Such a model would Components are composed by linking their ports with
allow composition in both the design and deployment connectors.
phases, together with the use of a repository. It would also Every component in PECOS has a name, a number of
use components that are easier to reuse, as well as property bundles, a set of ports, and behavior. Ports are for
composition operators that better enable systematic compo- data exchange, which is the only form of interaction
sition than are afforded by current models. We believe that between components with their environment (and, hence,
the ideal model should have the key characteristics of other components). A port is specified with a unique name
encapsulation and compositionality. within a component, the type of the data passed over the
port, the range of values that can be passed on this port, and
APPENDIX A the direction of the port, that is, in, out, and inout. A port can
only be connected to another port having the same type and
This appendix contains the outlines of component models complementary direction.
that are not covered in detail in the main text. The behavior of a component is a function or an algorithm
that takes data available on the component ports or some
A.1 Category 1: Design without Repository
internal data and produces data on the component ports.
A.1.1 UML2.0 In PECOS, there is no component repository. In the design
In UML2.0 [25], [26], a component is a modular unit of a phase, each system or component is specified in the CoCo
system with well-defined interfaces that is replaceable language [27] in a top-down manner, that is, in terms of
within its environment. A component defines its behavior compositions of subcomponents. Like ADLs, CoCo specifies
by one or more requires and provides interfaces (ports) only the properties and ports of a component and its
which implement its required and provided services. Every connectors but not its behavior. The behavior of a component
required service is represented by a socket and every has to be filled in (implemented) by the programmer. Since
LAU AND WANG: SOFTWARE COMPONENT MODELS 721

Fig. 27. A Fractal component.

Fig. 29. A COM component.

Fig. 28. Component composition in Fractal.

CoCo does not specify the behavior of components, the CoCo Fig. 30. Component composition in COM.
specification of the entire system is a syntactic specification of
the composition of the subcomponents. This composition is
A.2 Category 2: Design with Deposit-Only Repository
the composition in the design phase. The (sub)components
have no implementation at this stage. A.2.1 COM
Components are composed of connectors that link their In Microsofts COM [15], a component is a unit of compiled
ports. A connector describes a data-sharing relationship code (binary object) on a COM server. The language for the
between ports. It is described by its name, its type, and a list source code of a component can be any programming
of ports that it connects. A connector may only connect two language that is supported by Microsoft IDL [15], for
ports if the in port and the out port have compatible data example, C, C++, and Ada. Services in a component are
types. Ports of components can only be connected if they invoked via pointers to the functions that implement them.
belong to the same parent component, that is, connectors For each service provided by a component, there is an
may not cross component boundaries. interface [57]. A COM component can implement multiple
PECOS is used for specifying and developing embedded interfaces (Fig. 29). COM interfaces are specified in
systems of field devices represented as software compo- Microsoft IDL and every component must implement an
nents. A complete system typically represents a device IUnknown interface.
COM components are constructed in a programming
running in a control loop. It must have a schedule that
environment such as Microsoft Visual Studio .NET, which
specifies the order in which its behavior and the behavior of
provides a builder for COM components. The COM server
its subcomponents are run. Therefore, to realize an is the repository and there is no assembler.
executable system from its CoCo specification, the behavior In the design phase, COM components are composed by
of subcomponents has to be implemented by the program- method calls through interface pointers (Fig. 30). After the
mer and a schedule must then be provided for the system design phase comes the runtime phase, with the COM
and any subsystem that contains subcomponents. server providing the runtime environment.

A.1.3 Fractal A.2.2 .NET Component Model

In Fractal [30], [31], [32], a component is a runtime entity In Microsofts .NET [18], a component is an assembly that is a
that behaves like an object. IDLs (for example, OMG IDL) binary unit supported by CLR [58]. CLR is the runtime
are used to define generic interfaces that can be implemen- environment of .NET that loads, executes, and manages .NET
ted by components in specific programming languages. The types in the Intermediate Language (IL) into which all .NET
current Fractal API is extended and modified from Java API languages are compiled. Types of all .NET languages are
with JavaBeans-like introspection facilities. implemented within the Common Language Specification
A Fractal component is comprised of a content and a (CLS), which is a subset of the language features that are
controller (Fig. 27). The content of a component contains its adopted by CLR to realize cross-language interoperability.
interfaces and implementation. The interfaces of a compo- Thus, a .NET component is implemented in any .NET
nent are the only access points for other components to invoke language, including C#, VB, C++, that is constrained by CLS
operations defined by the component. The controller of a (only features included in CLS can be used) and compiled to
component defines the control behavior associated with this IL code, whatever the implementation language is.
component. In particular, it intercepts incoming and out- A .NET component is made up of metadata and IL code
(Fig. 31). The metadata of a .NET component contains the
going operation invocations and operation returns targeting
following information:
or originating in the components content that it controls.
A Fractal component can implement multiple interfaces. . Description of assembly: Assembly identity, including
A parametric component allows attributes to be set by its name, version, and so forth, the files, types, and
clients (via its AttributeController interface). other resources that make up the assembly, any
In the design phase, components are constructed in a other assemblies that this assembly depends on, and
programming environment with Fractal APIs and are the set of permissions that are required to run.
composed by method calls through connectors (Fig. 28). . Description of types: Name, visibility, base class,
The Java Virtual Machine serves as the runtime environ- interfaces implemented, and members, including
ment for Fractal components. methods, fields, properties, events, and nested types.
722 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

Fig. 31. A .NET component.

Fig. 34. A Web service.

Fig. 32. Component composition in .NET.

Fig. 35. Web service composition.

In the design phase, Corba components are assembled by

method and event delegations in such a way that facets
match receptacles and event sources match event sinks. In
Fig. 33. A Corba component. the runtime phase, the CCM container provides the runtime
environment for Corba component instances.
. Attributes: Garbage collection; security attributes;
version binding, and so forth.
A.2.4 Web Services
Web Services [62] are fundamental elements of distributed
The IL code of a .NET component is the output of a
applications in Service-Oriented Computing [19]. A Web
number of compilers of .NET languages (the IL code is service (Fig. 34) is a piece of binary code designed to support
actually the CPU-independent instruction set) that is used interoperable machine-to-machine interactions for resource
as the input to a just-in-time compiler in CLR (the IL code is sharing over a network. It has an interface described in a
converted to native CPU-specific code by the CLR). There- machine processable format, specifically in the WSDL [63].
fore, the metadata is the interface of a .NET component. Web services interact with one another via SOAP messages
.NET components are constructed in Microsoft Visual [62], typically conveyed by using HTTP with an XML
Studio .NET, which therefore provides a builder for these serialization in conjunction with other Web-related stan-
components. The CLR is the repository and runtime dards. The manner in which a Web Service handles SOAP
environment of .NET components. messages is prescribed by its WSDL interface. WSDL defines
In the design phase, .NET components are composed by the message formats, data types, transport protocols, and
method calls through references via metadata (Fig. 32). transport serialization formats that should be used between
After the design phase comes the runtime phase, with the services.
CLR providing the runtime environment. Services can be implemented in any programming
language and deployed on server machines that are publicly
A.2.3 CCM available. Interfaces of services are published in a Universal
In CCM [35], [59], a component is a metatype in Corba [60], Description, Discovery, and Integration (UDDI) [62].
which is an extension and specialization of a Corba object, In the design phase, Web services are composed by
hosted by a CCM container on a CCM platform such as delegation of method calls through SOAP messages
OpenCCM [61]. Component types are specific named (Fig. 35). For a service to be composed with another service,
collections of features that can be described in OMG IDL 3. it first locates the server machine for this service by
Component interfaces (Fig. 33) are made up of ports. physically specifying its address in the code so that the
CCM supports four kinds of ports: two services could send and receive SOAP messages in the
design phase.
. Facets are distinct named interfaces that are provided Services are deployed in the design phase, so there is no
by the component for client interaction. They are the
separate deployment phase. In the runtime phase, the
provided operation interfaces of the component.
server of each service provides the runtime environment for
. Receptacles are named connection points that de- the service.
scribe the components ability to use a reference Note that by service composition we mean server-side
supplied by some external agent. They are the
composition and not what is called Web service orchestra-
required operation interfaces of the component.
tion on the client side. The latter is used by the Web services
. Event Sources are named connection points that emit community to create client-side applications by defining
events of a specified type to one or more interested
their workflows in the BPEL [39].
event consumers or to an event channel. They
publish or emit events. A.3 Category 4: Design with Repository
. Event Sinks are named connection points into which
events of a specified type may be pushed. They A.3.1 SOFA
consume events. In SOFA [23], [24], a component is a unit of design that has a
Corba components have homes that are component specification and an implementation. It is specified by its
factories that manage a component instances life cycle, frame and architecture. The frame defines provides and
including creation, destruction, and retrieval. Each compo- requires interfaces (Fig. 36) and properties of the compo-
nent instance must be managed by one home instance. nent which can be implemented by more than one
Corba components are constructed in a programming architecture. The architecture describes the structure of
environment such as Open Production Tool Chain and the component. SOFA components are defined in an ADL-
deposited into a CCM container hosted and managed by a like language, that is, SOFA CDL, which is used to define
CCM platform such as OpenCCM. The programming envir- interfaces, frames, and architectures of SOFA components.
onment is the builder and the CCM container is the repository. SOFA components definitions are compiled by the SOFA
LAU AND WANG: SOFTWARE COMPONENT MODELS 723

[5] K.-K. Lau and Z. Wang, A Survey of Software Component Models,

second ed., School of Computer Science, Univ. of Manchester,
http://www.cs.man.ac.uk/cspreprints/PrePrints/cspp38.pdf,
May 2006.
[6] M. Shaw and D. Garlan, Software Architecture: Perspectives on an
Emerging Discipline. Prentice Hall, 1996.
Fig. 36. A SOFA component. [7] L. Bass, P. Clements, and R. Kazman, Software Architecture in
Practice, second ed. Addison-Wesley, 2003.
CDL compiler to their implementations in a programming [8] L. DeMichiel, L. Yalcinalp, and S. Krishnan, Enterprise JavaBeans
Specification Version 2.0, 2001.
language, for example, Java.
[9] R. Monson-Haefel, Enterprise JavaBeans, fourth ed. OReilly &
SOFA components are constructed in the SOFANode Assoc., 2004.
and deposited into the Template Repository. The SOFA- [10] P. Clements, A Survey of Architecture Description Languages,
Node is the builder for SOFA components and the Template Proc. Eighth Intl Workshop Software Specification and Design (IWSSD
Repository is the repository of SOFA components. There is 96), pp. 16-25, 1996.
no assembler. [11] N. Medvidovic and R.N. Taylor, A Classification and Compar-
In the design phase, SOFA components are composed by ison Framework for Software Architecture Description Lan-
guages, IEEE Trans. Software Eng., vol. 26, no. 1, pp. 70-93, Jan.
method calls through connectors. In the deployment phase,
2000.
the SOFANode provides the runtime environment for [12] K.-K. Lau and Z. Wang, A Taxonomy of Software Component
SOFA components. Models, Proc. 31st Euromicro Conf. Software Eng. and Advanced
Applications (SEAA 05), pp. 88-95, 2005.
A.3.2 KobrA [13] M. Broy, A. Deimel, J. Henn, K. Koskimies, F. Plasil, G.
In KobrA [22], a component is a UML stereotype. Every Pomberger, W. Pree, M. Stal, and C. Szyperski, What Char-
acterizes a Software Component? SoftwareConcepts and Tools,
KobrA component has a specification and an implementa- vol. 19, no. 1, pp. 49-56, 1998.
tion. The specification describes what a component does [14] B. Meyer, The Grand Challenge of Trusted Components, Proc.
and, thus, it is the interface of the component, and the 25th Intl Conf. Software Eng. (ICSE 03), pp. 660-667, 2003.
implementation describes how it does it. [15] D. Box, Essential COM. Addison-Wesley, 1998.
KobrA components can be constructed in a visual [16] CORBA Component Model, V3.0, OMG, http://www.omg.org/
technology/documents/formal/components.htm, 2002.
builder tool such as Visual UML and deposited into a file [17] JavaBeans Specification. Sun Microsystems, http://java.sun.com/
system. The visual builder tool is the builder for KobrA products/javabeans/docs/spec.html, 1997.
components and the file system is the repository of KobrA [18] A. Wigley, M. Sutton, R. MacLeod, R. Burbidge, and S. Wheel-
components. There is no assembler. wright, Microsoft .NET Compact Framework (Core Reference). Micro-
In the design phase, KobrA components are composed by soft Press, Jan. 2003.
[19] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web Services:
direct method calls. In the deployment phase, component Concepts, Architectures and Applications. Springer-Verlag, 2004.
implementations can be refined from their specifications. No [20] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee,
new composition of component instances is possible. The Koala Component Model for Consumer Electronics Soft-
ware, Computer, vol. 33, no. 3, pp. 78-85, Mar. 2000.
[21] R. van Ommering, The Koala Component Model, Building
ACKNOWLEDGMENTS Reliable Component-Based Software Systems, I. Crnkovic and
M. Larsson, eds., pp. 223-236, Artech House, 2002.
The authors wish to thank Ivica Crnkovic, David Garlan, [22] C. Atkinson, J. Bayer, C. Bunse, E. Kamsties, O. Laitenberger, R.
Dirk Muthig, Oscar Nierstrasz, Bastiaan Schonhage, and Laqua, D. Muthig, B. Paech, J. Wust, and J. Zettel, Component-Based
Kurt Wallnau for information and helpful discussions. They Product Line Engineering with UML. Addison-Wesley, 2001.
are also grateful to the reviewers and the editor for [23] F. Pla!sil, D. Balek, and R. Janecek, SOFA/DCUP: Architecture for
Component Trading and Dynamic Updating, Proc. Fourth Intl
illuminating feedback and constructive comments, which Conf. Configurable Distributed Systems (ICCDS 98), pp. 43-52, 1998.
enabled them to make considerable improvements to the [24] F. Pla!sil, M. Besta, and S. Visnovsky, Bounding Component
paper. Z. Wang would like to thank Universities UK for the Behavior via Protocols, Proc. Technology of Object-Oriented
Overseas Research Students (ORS) Award and the School of Languages and Systems (TOOLS 31), pp. 387-398, 1999.
Computer Science, University of Manchester, for the [25] UML 2.0 Superstructure Specification, OMG, http://www.omg.org/
cgi-bin/doc?ptc/2003-08-02, 2007.
Departmental Studentship. Parts of the material in this [26] J. Cheesman and J. Daniels, UML Components: A Simple Process for
paper were presented as tutorials at the 21st IEEE/ACM Specifying Component-Based Software. Addison-Wesley, 2000.
International Conference on Automated Software Engineer- [27] T. Genssler, A. Christoph, B. Schulz, M. Winter, C. Stich, C.
ing (ASE 2006) and the 28th International Conference on Zeidler, P. Muller, A. Stelter, O. Nierstrasz, S. Ducasse, G.
Arevalo, R. Wuyts, P. Liang, B. Schonhage, and R. van den Born,
Software Engineering (ICSE 2006) [4], as well as in a
PECOS in a Nutshell, http://www.pecos-project.org/, Sept. 2002.
conference proceeding [12]. [28] O. Nierstrasz, G. Arevalo, S. Ducasse, R. Wuyts, A. Black, P.
Muller, C. Zeidler, T. Genssler, and R. van den Born, A
Component Model for Field Devices, Proc. First Intl IFIP/ACM
REFERENCES Working Conf. Component Deployment (CD 02), pp. 200-209, 2002.
[1] F. Bachmann, L. Bass, C. Buhman, S. Comella-Dorda, F. Long, J. [29] The Fractal Project Web Page, http://fractal.objectweb.org/,
Robert, R. Seacord, and K. Wallnau, Volume II: Technical 2007.
Concepts of Component-Based Software Engineering, second [30] E. Bruneton, T. Coupaye, and J. Stefani, Recursive and Dynamic
ed., Technical Report CMU/SEI-2000-TR-008, Software Eng. Inst., Software Composition with Sharing, Proc. Seventh Intl Workshop
Carnegie Mellon Univ., 2000. Component-Oriented Programming (WCOP 02), 2002.
[2] Component-Based Software Engineering: Putting the Pieces Together, [31] E. Bruneton, T. Coupaye, and J. Stefani, The Fractal Component
G. Heineman and W. Councill, eds. Addison-Wesley, 2001. Model, ObjectWeb Consortium, Technical Report Specification
[3] C. Szyperski, D. Gruntz, and S. Murer, Component Software: Beyond V2, 2003.
Object-Oriented Programming, second ed. Addison-Wesley, 2002. [32] E. Bruneton, T. Coupaye, and M. Leclercq, An Open Component
[4] K.-K. Lau, Software Component Models, Proc. 28th Intl Conf. Model and Its Support in Java, Proc. Seventh Intl Symp.
Software Eng. (ICSE 06), pp. 1081-1082, 2006. Component-Based Software Eng. (CBSE 04), pp. 7-22, 2004.
724 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 10, OCTOBER 2007

[33] JavaBeans Architecture: BDK Download. Sun Microsystems, http:// [58] M. Barnett and W. Schulte, Runtime Verification of .Net
java.sun.com/products/javabeans/software/bdk_download. Contracts, Systems and Software, vol. 65, no. 2003, pp. 199-208,
html, 2003. 2003.
[34] Java 2 Platform, Enterprise Edition Sun Microsystems, http:// [59] BEA Systems et al., CORBA Components, Object Management
java.sun.com/j2ee/, 2007. Group, Technical Report orbos/99-02-05, 1999.
[35] Common Object Request Broker Architecture: Core Specification, [60] R. Natan, CORBA: A Guide to Common Object Request Broker
Version 3.0.3, http://www.omg.org/technology/documents/ Architecture. McGraw-Hill, 1995.
corba_spec_catalog.htm, Mar. 2004. [61] OpenCCM Users Guide, ObjectWebOpen Source Middleware,
[36] D. Garlan, R. Monroe, and D. Wile, Acme: Architectural http://openccm.objectweb.org/doc/0.8.1/user_guide.html, 2007.
Description of Component-Based Systems, Foundations of Compo- [62] E. Newcomer, Understanding Web Services: XML, WSDL, SOAP, and
nent-Based Systems, G. Leavens and M. Sitaraman, eds., pp. 47-68, UDDI. Addison-Wesley, 2002.
Cambridge Univ. Press, 2000. [63] Ariba, Microsoft, and IBM, Web Services Description Language
[37] C. Peltz, Web Services Orchestration and Choreography, (WSDL) Version 1.1., http://www.w3.org/TR/2001/NOTE-wsdl-
Computer, vol. 36, no. 10, pp. 46-52, Oct. 2003. 20010315, 2001.
[38] M. Lumpe, F. Achermann, and O. Nierstrasz, A Formal
Language for Composition, Foundations of Component Based Kung-Kiu Lau received the BSc and PhD
Systems, G. Leavens and M. Sitaraman, eds., pp. 69-90, Cambridge degrees from the University of Leeds, United
Univ. Press, 2000. Kingdom. He is currently a senior lecturer in the
[39] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. School of Computer Science at the University of
Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Manchester, United Kingdom. He is the series
Weeragwarana, Business Process Execution Language for Web editor of a book series on component-based
Services (BPEL4WS) Version 1.1. IBM, http://www-106.ibm.com/ software development published by World
developerworks/library/ws-bpel/, 2004. Scientific. He is an area editor (for logic and
[40] R. Allen and D. Garlan, A Formal Basis for Architectural software engineering) of the Journal of Applied
Connection, ACM Trans. Software Eng. and Methodology, vol. 6, Logic. He has served on the program commit-
no. 3, pp. 213-249, 1997. tees of numerous international conferences, including ASE, CBSE, and
[41] I. Crnkovic, H. Schmidt, J. Stafford, and K. Wallnau Proc. Sixth SC. He has also delivered invited talks and tutorials at many
Workshop Component-Based Software Eng.: Automated Reason- international meetings, including an invited keynote talk at FMCO
ing and Prediction (CBSE 04). ACM SIGSOFT Software Eng. Notes, 2005 and tutorials on software component models at ASE 2005 and
vol. 29, no. 3, pp. 1-7, May 2004. ICSE 2006. His main research interest is component-based software
[42] B. Christiansson, L. Jakobsson, and I. Crnkovic, CBD Process, development.
Building Reliable Component-Based Software Systems, I. Crnkovic and
M. Larsson, eds., pp. 89-113, Artech House, 2002. Zheng Wang received the BSc degree from the
[43] B. Warboys, B. Snowdon, R. Greenwood, W. Seet, I. Robertson, R. University of Manchester, United Kingdom,
Morrison, D. Balasubramaniam, G. Kirby, and K. Mickan, An where he is currently working toward the PhD
Active Architecture Approach to COTS Integration, IEEE Soft- degree in the School of Computer Science. He
ware, special issue on incorporating COTS into the development participated in and completed the project Eur-
process, vol. 22, no. 4, pp. 20-27, July/Aug. 2005. opean Network of Excellence in Computational
[44] The Bean Builder, Sun Microsystems, https://bean-builder.dev. Logic (CologNet), where he maintained the Web
java.net/, 2007. site of Component-Based Software Develop-
[45] AcmeStudio 2.1 User Manual, Carnegie Mellon Univ., http://www- ment. He coorganized the 2004 and 2005
2.cs.cmu.edu/~acme/Manual/AcmeStudio-2.1.htm, 1998. Workshop on Predictable Software Component
[46] J. Aldrich, C. Chambers, and D. Notkin, ArchJava: Connecting Assembly. His research interests are component-based software
Software Architecture to Implementation, Proc. 24th Intl Conf. engineering and software verification.
Software Eng. (ICSE 02), pp. 187-197, 2002.
[47] J. Aldrich, C. Chambers, and D. Notkin, Architectural Reasoning
in ArchJava, Proc. 16th European Conf. Object-Oriented Program- . For more information on this or any other computing topic,
ming (ECOOP 02), pp. 334-367, 2002. please visit our Digital Library at www.computer.org/publications/dlib.
[48] J. Aldrich, D. Garlan, B. Schmerl, and T. Tseng, Modeling and
Implementing Software Architecture with Acme and ArchJava,
Proc. Companion 19th Ann. ACM SIGPLAN Conf. Object-Oriented
Programming, Systems, Languages, and Applications (OOPSLA 04),
pp. 156-157, 2004.
[49] L. DeMichiel and M. Keith, Enterprise JavaBeans, Version 3.0. Sun
Microsystems, 2006.
[50] R. Monson-Haefel, Enterprise JavaBeans 3.0, fifth ed. OReilly &
Associates, 2006.
[51] Eclipse Web Page, http://www.eclipse.org/, 2007.
[52] Y. Choi, O. Kwon, and G. Shin, An Approach to Composition of
EJB Components Using C2 Style, Proc. 28th Euromicro Conf.
(Euromicro 02), pp. 40-46, 2002.
[53] P. Clements and L. Northrop, Software Product Lines: Practices and
Patterns. Addison Wesley, 2001.
[54] P. Hn!etynka and F. Pla!sil, Dynamic Reconfiguration and Access
to Services in Hierarchical Component Models, Proc. Ninth Intl
Symp. Component-Based Software Eng. (CBSE 06), I. Gorton et al.,
eds., pp. 352-359, 2006.
[55] K.-K. Lau, P. Velasco Elizondo, and Z. Wang, Exogenous
Connectors for Software Components, Proc. Eighth Intl Symp.
Component-Based Software Eng. (CBSE 05), I. Gorton et al., eds.,
pp. 90-106, 2005.
[56] K.-K. Lau, M. Ornaghi, and Z. Wang, A Software Component
Model and its Preliminary Formalisation, Proc. Fourth Intl Symp.
Formal Methods for Components and Objects (FMCO 06), F. de Boer
et al., eds., pp. 1-21, 2006.
[57] A. Major, COM IDL and Interface Design. John Wiley & Sons, Feb.
1999.