Send to a Friend
of large, monolithic software systems are fast moving into oblivion. The pace
of software development becomes aggressive with development cycles reduced drastically.
The current trend favors a short-term development process where large and complex
applications are being built using a series of smaller parts, referred to as
components. Component technology is the next step in the evolution of software
design and development. It is strongly associated with Object technology, though
this association is not necessarily an accurate one. Here is an explanation
of what is all about components and their usefulness. The area of component
technology has spawned a slew of new buzz-words, some of them are confusing.
Components are typically business objects that have predefined and reusable
behaviors. Implementation detail is hidden in the interfaces, which isolate
and encapsulate a set of functionality. Interfaces are the means by which components
connect. An interface is a set of named operations that can be invoked by clients.
More importantly, well-defined interfaces define the component's entry points,
and a component's accessibility is done only via its interface. In a component-based
approach, providers and clients communicate via the specification of the interface,
which becomes the mediating middle that lets the two parties collaborate and
In summarizing, we have the following:
- A component is an independent, application-level software unit that is developed
for a specific purpose and not for a specific application. Components are
self-contained, pluggable abstract data types. They are of large grained entities.
Component assembly (application development) is concerned with high level
domain experts rather than programmers. Programmers will be responsible for
component construction and the fabrication of components for use would be
accomplished by component assemblers.
- Components are accessed through well-defined interfaces. A component's interface
serve as the access points to its functionality. These interfaces may be implemented
by objects internal to the component, if the component developer so desires.
But interfaces may be implemented by a non-OO language.
- Only a single instance of a component exist per system. If there are more
than one client accessing the functionality being provided by the component,
different object references may be distributed to those clients. An object
reference is a handle to an object in a component which implements an interface.
- Component comprised systems will typically feature components from different
vendors. Components will be interoperable by conformance to industry standard
- Components are platform-independent
- Components will be encapsulated and modular. Their internals may utilize
inheritance for implementation reasons. This fact will remain as an implementation
detail, not visible to the component clients. Components can not be extended
systems shall be developed by assembling co-operative software units. These
units need not necessarily originate from the same vendor, but will conform
to a standard interface for units offering their respective functionality.
Assembly of such units will be aided by use of tools which will extract self
descriptive information from these units. Delivery of such an assembled system
will involve the deployment of these units configured appropriately. These
units may be delivered on any platform. Such software units are known as components.
Components and Objects
worth considering the relationship existing between components and objects.
A component approach to software development builds upon fundamental constructs
of object-oriented paradigms. Although the terms "component" and "object" are
often used interchangeably, a component is not an object. An object is an instance
of a class that gets created at runtime. A component can be a class, but is
usually a collection of classes and interfaces. At runtime, a component becomes
alive when its classes get instantiated. Therefore, at runtime, a component
becomes a web of objects.
Their usage seems synonymous. While objects are well-suited for component construction,
a non-OO approach to component construction is perfectly valid. The following
explains how objects differ from components.
- Components are large-grained entities, e.g. a payroll module. Objects are
fine-grained entities, e.g. a Person.
- Components are accessed via well-defined interfaces. Objects are also accessed
via interfaces. Thus the two are similar in this respect, but not identical.
Components interfaces are based on industry standards, object interfaces are
not. A component with a CORBA IDL interface is easily accessible from any
language. An object implemented in C++ is not easily accessible from another
language. Components need not use OO approach to implement their interfaces.
The same is also true of objects. The objects often act as wrappers to non-OO-code.
- Only single component instances will exist per system whereas multiple objects
will exist per system. Components are more akin to Object factories which
also delegate functionality to objects within the factory.
- Component based systems will be made up of heterogeneous vendor components.
Seamless integration is possible as components will be built to industry standard
interfaces. Achieving the same with objects tends to be more difficult as
objects are built to proprietary interfaces, thus can not be seamlessly integrate.
Such integration is possible if the object interfaces are standard such as
- Components will be runnable out of the box. Only Java objects on a system
running a JVM can boast of this property.
- Components can be encapsulated and non-extendable. Objects will be both
encapsulated and extendible through inheritance. But inheritance may be misused
and hence this is being avoided in components as component assemblers are
experts in domain knowledge not on OO techniques.
are a whole lot of exciting and robust components in the existing systems. Extraction
of them and reusing for the purpose of building software applications is one
interesting task. The other one is to build components from the scratch using
component-based programming languages.
Component-oriented programming addresses the aspects of programming components.
Component construction itself can be performed using arbitrary programming languages,
as long as the language supports the particular component standard's interface
conventions. Many programming languages such as COBOL, C, C++, Pascal, Smalltalk
lack support for encapsulation, polymorphism, type safety or a combination of
these. So nowadays Java is becoming the most favored programming language for
building software components.
In the absence of existing legacy code, a component must be built from scratch.
In this case, it makes sense to implement a component using an OO approach.
However, it is often the case that legacy code providing similar functionality
will be available somewhere.
The aim of components is to deliver better applications to the market in a
shorter time. This is easily achieved through leveraging existing components.
Thus the philosophy of component assembly is re-use. The philosophy for component
construction remains the same.
When assembling a component based system, it is assumed that the selected components
are fit for the purpose. That is, the components have been rigorously tested
and their performance metrics well understood. Reuse is encouraged through faith
in the components. When constructing components, existing code will be often
be reused. We below give a brief explanation for some of the approaches in this
Object wrapping: In a system which is object-based,
all entities within the system must behave as objects. Thus, when non-OO code
is being reused, it can not be used directly- it must be wrapped. A class is
created which delegate functionality to the non-OO code. The objects created
from this class will behave as object oriented proxies for the legacy code.
Refactoring: System development is an incremental
process. The more a system is used, the more it must evolve to meet new requirements.
It is often the case that code which was cut in the original release, while
functionally sound, may prove to be inflexible for current requirements. Refactoring
is changing code's internal structure to make it easier to understand and use
while leaving its functionality unchanged. Refactoring can breath new life into
powerful but inflexible systems.
Mining: It is performed by analyzing elements of
the existing system. These elements are only considered within the scope of
the existing (legacy) system. This provides the miner with a comprehensive picture
of the system. While designing/implementing a new system, the mistakes of the
previous system can be avoided, as they were identified in the mining process.
In addition, useful elements of the legacy system will have been identified
and these can be reused. Mining is a powerful concept and may be applied at
the code level as well. Code identified in the mining process as suitable for
reuse will typically undergo wrapping and possibly refactoring.
Caveat: With a vast collection of systems already
tied and tested, it would seem tempting to go for a reuse approach outright.
However,it is worth distinguishing between Legacy Assets and Legacy Liabilities.
Most systems will be littered with both, with dependencies between the two.
It is the skill of the system miner to distinguish between the assets and the
liabilities and to identify the assets with little or no liability dependencies.
Software Components - Benefits
benefits of software components are manifold:
- A component is more generalized and application-independent
- Components can be reused in a variety of contexts.
- Individual components can be custom-made to suit specific requirements,
whereas existing ones can be customized to meet those requirements.
- Several components can be assembled to form a functioning system.
- Upgrades of individual components end the problem of massive upgrades
as done in monolithic systems
- Components can live anywhere on a network - in computers best suited for
running them - based on the functions the components provide.
- Using distributed computing system standards such as CORBA, Java RMI and
EJB, and Microsoft's COM/DCOM, components can be distributed among the computers
in an enterprise network.
Return to Articles