PreparedbyM.S.AbiramiandM.

Uma
CS0356 Component Based Technologies
UNIT I Introduction
Components and objects are similar. Both are making
their services available via interfaces. Object and component
interactions are described using object and component patterns
and prescribed using object and component frameworks.
Both components and frameworks are said to be white
box or black box. Also specified as namespaces, modules, and
packages by the language designers.
Components
The characteristic properties of a component are,
(1) It is a unit of independent deployment;
(2) It is a unit of third-party composition;
(3) It has no (externally) observable state.

For a component to be independently deployable, it
needs to be well separated from its environment and other
components. It encapsulates its constituent features. It will
never be deployed partially.
For a component to becomposable with other
components by a third party, it needs to be self-contained. It
needs to come with clear specifications of what it requires and
provides. That is, it encapsulates its implementation and
interacts with its environment by well-defined interfaces.
A component should not have any externally
observable state it is required that the component cannot be
distinguished from copies of its own. Exceptions are attributes
not contributing to the components functionality such as serial
numbers used for accounting.
A component can be loaded into and activated in a
particular system. In any given process, there will be at most
one copy of a component. Since multiple copies are mutually
indistinguishable.
Components are heavyweight units with exactly one
instance in a system. For example, student database server is a
component (immutable) and student data is an instance
(mutable) that is an object.
Components does not promote or demote the use of the
state, observable or not, at the level of objects. Also, it is
unrelated to the life-time of object state (per call, per session,
or persistent).

Objects
The properties of objects are,
(1) It is a unit of instantiation, it has a unique identity;
(2) It may have state and this can be externally observable;
(3) It encapsulates its state and behavior.

An object cannot be partially instantiated. Object has a
unique identity to identify the object despite changes for its
entire life-time.
As objects are instantiated, a construction plan is
needed that describes the state space, initial state and behavior
of a new object. Also, that plan needs to exist before the object
can come into existence. Such a plan may be explicitly
available and is called a class.
Alternatively, it may be implicitly available as an object
that already exists, and can be cloned. Such a pre-existing
object is called a prototype object.
The code required to control object creation and
initialization can be a static procedure called a constructor if
PreparedbyM.S.AbiramiandM.Uma
it is part of the objects class. Alternatively, it can be an object
of its own called a factory object. Methods on objects that
return freshly created other objects called factory methods.

Fundamental Properties of Component Technology

Components come from independent sources and are
integrated by third parties. For the safety of individual
components, fault isolation is necessary.
Errors are detected only during system integration and
testing (not at the level of individual components). With third-
party integration, this situation becomes more difficult, as
integration testing of modules from different sources needs to
be addressed.
For most integration tests, a negative result would come
too late in the process as the components will have already
been acquired and deployed. For example, J ava applet code
will not be integrated into the requesting browser, until a
webpage is requested by a browser. Version checks (tests) are
useful at the stage of late integration.
Late checks can only rescue the user, but cannot
directly help to improve the quality of the components. A
component vendor faces a combinatorial explosion of system
configurations against which to test a component (as new
components are added).
Testing against a few possible configurations is the best
(modular checking instead of full integration testing).
Therefore, the component vendors need to strengthen the per
component process. This requires conservative engineering
(defensive programming).
Component safety is important even if a component
fails to function, it must not violate system-wide rules. One of
the critical decisions to be made is the proper choice of
programming languages and tools.
Once safety properties are in place, functionality and
performance have to follow. Conservatism is the only
advisable strategy. OMG (Object Management Group)
recommends mixing and matching its various object services,
claiming orthogonality and interoperability. But actual mixing
is not easy.
Performance remains a formidable problem. It is
affected in non-trivial ways by the actual composition. It is
primarily addressing Is it fast enough? However, problems of
economical resource utilization are closely related, including
demands for processing capacity, primary and secondary
storage, or network bandwidth.

Modules

Components are close to modules. The most popular
modular languages are Modula-2 and Ada. In Ada, modules are
called packages. There is separate compilation in modular
approach.
Modules would each implement one abstract data type
(ADT). A class can implement an ADT, with the additional
properties of inheritance and polymorphism. However,
modules can be used, to package multiple entities, such as
ADTs, or classes, into one unit. Also, modules do not have a
concept of instantiation, whereas classes do.
In most recent language designs such as Modula-3,
Component Pascal, and C
#
modules and classes are kept
separate. In languages such as J ava that do not have a module
concept, nested classes are used.
Unlike classes, modules can be used to form minimal
components. Even modules that do not contain any classes can
PreparedbyM.S.AbiramiandM.Uma
function as components. A good example is math libraries.
Component is not normally supported by module
concepts. There are no persistent immutable resources that
come with a module. Resources parameterize a component.
Replacing these resources allows the component to be
configured without the need to rebuild its code. For example,
resource configuration can be used for localization to assign
mutable state to a component. However, as components are not
supposed to modify their own resources, it is useful to regard a
localized version of a component as a different (but related)
component.
Components do not permit observable state, while
modules can clearly be built to use global static variables to
expose observable state. Modules depend statically on
implementations in other modules by importing direct
interfaces from other modules. For components, such static
dependencies on component-external implementations are
allowed but not recommended.

Interfaces

A component will have multiple interfaces
corresponding to different access points. Each access point
may provide a different service, catering for different client
needs.
The following are the non-technical aspects that
interface to be successful.
First, the economy of scale has to be kept in mind. A
component can have multiple interfaces, each representing a
service that the component offers. If the components have no
market, then there may be development of the extension of the
component.
Second, undue fragmentation of the market has to be
avoided as it threatens the viability of components. Redundant
introductions of similar interfaces have thus to be minimized.
Third, to maximize the reach of an interface
specification and components implementing this interface,
there need to be common media to publicize and advertise
interfaces and components. This requires a small number of
widely accepted unique naming schemes.

Callbacks
A callback is a procedure that is passed to a library at
one point, when the callback is registered with the library. The
library then calls the callback.
In a layered architecture, normal calls always originate
in higher layers (more abstract), then they move downwards. A
callback usually reverses the direction of the flow of control, so
a lower layer calls a procedure in a higher layer (up-calls).
In a strict procedural library model, the client never
observes any intermediate states of the library. The only
relevant library states (for the client) are those just before and
just after a call to the library. But the intermediate library state
at the point of calling the callback may be revealed to clients.
A library has to establish a valid state, as far as observable by
the client, before invoking any callbacks. A callback may cause
the librarys state to change through direct or indirect calls to
the library. So, the observable state of the library has to remain
valid for as long as any callbacks are active.
.
Directory Services

A directory service is a software system that stores and
organizes information in a directory and provides access to that
information.
PreparedbyM.S.AbiramiandM.Uma
The directory service supports callbacks to notify
clients of changes in the managed directory. Such a notification
service is useful to keep the directory service up to date.

Directory is similar to dictionary (different meaning is
given for one word), that it stores different type of data. In a
dictionary names are organized in an alphabetical order. But in
a directory, names are organized as a hierarchical tree where
each node is a valid name with associated data.
Example:
1. Dictionary Narrow scope
2. DNS - Broader scope

Components Architecture
Components and Middleware
Refer Page nos. 419 to 421
(Text Book: Component Software Clemens
Szyperski)