UNIT-I INTRODUCTION

Unit - I (INTRODUCTION)

Software component – objects – fundamental properties of component technology – modules –

interfaces – callbacks – directory services – component architecture – components and middleware.
--------------------------------------------------------------------------------------------------------------------------------

SOFTWARE COMPONENTS:

• Definition: A software component is a unit of composition with contractually specified interfaces and
explicit context dependencies only. A software component can be deployed independently and is subject
to composition by third parties.

• The characteristic properties of a component are:

1. A component is a unit of independent deployment. This is because a component encapsulates its

constituent features.
2. A component is a unit of third-party composition. Components come from independent sources and
are integrated by the third parties. For this the component should be self-contained and come with clear
specifications of what is required and what is provided by the component. Therefore, the component
should encapsulate its implementation and interact with its environment through well-defined interfaces.
Software components can thus be viewed as executable units of independent production, acquisition and
deployment that can be composed into functioning system.
3. A component has no externally observable state. A component can be loaded and activated in a
particular system. But, due to its stateless nature, it does not make sense in having multiple copies of the
same component.

• The following are the features of components:

1. Information Hiding: The most important characteristic is that components completely hide their
implementation. Components are like black boxes. The programmer has a complete idea of the services
provided by the component through the interfaces. The implementation details are hidden. It thus
provides complete encapsulation.
2. Context Independence: Components are easily transferable into different application contexts.Hence,
components should be self-contained software elements.
3. Implicit Invocation: Components use an indirection mechanism to facilitate themselves to be
exchangeable. A central registry stores all information about the components and interfaces. Each time a
client wants to invoke a method, it queries the registry for the required interfaces which in turn returns a
reference to the implementing component.
4. Interoperability: This facilitates a component to communicate with components programmed in
another programming language or located on a different host. This is brought about by virtual machines
and middleware technologies like CORBA from OMG and DCOM from Microsoft.
1
UNIT-I INTRODUCTION

5. Component models: The software architecture of the component system determines the interfaces,
composition and interaction of components. A component model provides a common framework in
which components interact. Outside the framework the component is not usable. JavaBeans from Sum
Microsystems and ActiveX from Microsoft are some examples of component model.
6. Simplicity: While developing software, there is no need to develop components from scratch as they
can be purchased from a third party. This shorter development time results in reduced costs.
7. Reliability: Components enhance the reliability of the software as they are already
improved, tested and debugged. Apart from this, the composer can choose and combine the
best components of different vendors.

• Explicit context dependencies: What the deployment environment will need to provide so that the
components can function. These needs are called context dependencies. They include the
component model that defines the rules of deployment, installation and activation of components.
For example, a mail merge component would specify that it needs a file system interface.

• Advantages of components:

1. Components can be built from a variety of technologies.

2. Components exists in varying sizes from single-objects inside a library to whole application.
3. Reduces software development time and hence cost, because of it ready-to-use nature.
4. ORBs (Object Request Broker) like RMI registry in JAVA can be used to define interfaces and
compose components. Hence, components facilitate uniform interfacing.
5. The software applications developed using components are of better quality, as these
applications make use of components that have already been tested.
6. Components can be customized to meet the user’s needs.
7. They aid in satisfying the engineering goals of software engineering –reuse, time-to-market
and quality.

• The main limitation of components is that, to be reused in a number of applications, they should
be developed in a generic way.

OBJECTS:

• Components are larger entities and contain several objects. Components can also be non-object
oriented.
• Definition: An object is an entity that has a state and a defined set of operations which operate on
that state.
• Software objects are conceptually similar to real-world objects: they too consist of state and related
behavior. An object stores its state in fields (variables in some programming languages) and
exposes its behavior through methods (functions in some programming languages).
• The characteristics properties of objects are:

2
 UNIT-I INTRODUCTION

 is a unit of instantiation, it has a unique identity;

 may have state and this can be externally observable;
 encapsulates its state(field) and behavior(methods).

• Creational design patterns are design patterns that deal with object creation mechanisms, and will
create objects in a manner suitable to the situation..
• Some examples of creational pattern-factory method pattern, prototype pattern, object pool etc.
• The prototype pattern and the factory pattern are very similar in both intent and functionality. Both are
creational patterns that will create objects of some interface without needing to specifically know the
underlying class types.
• The main difference between the two patterns involves how objects are constructed. The factory
pattern will, generally, construct an object using the same construction parameters each time. Each object
will be initialized with the same state information and be roughly equivalent to each other.
• The prototype pattern, on the other hand, can use any cloneable object that is given to it, even if those
objects are of the same class type but with different state information assigned to them. Each object then
becomes the prototype or template for any objects cloned from them.
• An example can demonstrate this:

public void factoryDoSomething(Factory factory) {

Point pt = factory.createPoint();
... do something with the point ...
}

public void prototypeDoSomething(Point prototype) {

Point pt = (Point) prototype.clone();
... do something with the point ...
}

• Notice that in the factoryDoSomething method, the point that is created is initialized in the same
way and cannot be customized.
• The prototypeDoSomething method can create a point from any other point with any type of state
assigned to it. We could have called it with a "new Point (23, 85)" or a "new Point (2929, 59483)"
and the cloned object would have similar state to those prototypes. The, point of the matter is that we
can customize the state of the objects that will be created by the prototype pattern.

Components and objects:

• A component is likely to act through objects( For example, In VB IDE tool box we have the
‘Command Button component’, but it will act through its object(Command1) which we are
dragging and dropping in the form) and therefore would normally consist of one or more classes or
immutable prototype objects.
• However, component may contain classes or may not contain classes at all. A component could
contain traditional procedures

3
UNIT-I INTRODUCTION

• The difference between state maintained by ‘objects created by a component’ and state maintained
by a ‘component ‘ is that state maintained by an object is abstracted by that object’s reference.(For
example Text1.visible=true)
• A component that does not maintain observable state cannot maintain references even to the objects
it created. A reference to the component itself (the component’s fully qualified name) cannot be used
to retrieve any objects.( for example, even if you have the name of the component (name:Comman
button),using this name we cant refer to the object(Command1 in form) created from that
component.
• A component may contain multiple classes, and just as classes can depend on other classes
(inheritance), components can depend on other components (import).
• The superclasses of a class do not necessarily need to reside in the same component as the class
itself. Where a class has a superclass in another component, the inheritance relation crosses
component boundaries.
• Hence, it is concluded that object is not component. But, it’s the instance of a component.

FUNDAMENTAL PROPERTIES OF COMPOENET TECHNOLOGY:

• The fundamental properties of compoenet technology are

 Technological feasibility
 Technical problems
 Integration and testing
 Potential of software components

1. Technological feasibility: Establishing markets for components depend on the technological

feasibility .Although many of the required key technologies are available; overall understanding of
component software is required. For example, before starting the development phase of a
component, it is advisable to analyze what are all the component technologies (ex: RMI,OMG’s
CORBA,MS-DCOM etc)available and to select the best technology for that component. If this is
done correctly then the components market will be good.
2. Technical problems: As components come from independent sources and are integrated by third
parties. In the absence of countermeasures component system is only as strong as its weakest
component. Hence, all the individual components must be free from faults.
3. Integration and testing: In traditional engineering process, module development and testing is
followed by integration and testing. And this testing will ensure that both hardware and software
(all modules) were functioning together properly.
• With third-party integration, the situation becomes difficult, as integration testing of
modules from different sources needs to be addressed.

4
UNIT-I INTRODUCTION

• So, integration testing of software components will ensure that components interact with
each other and operate in a correct manner.
4. Potential of software components: A component vendor faces a combinational explosion of
possible system configurations against which to test a component. For example, consider Java
applets, until a web page is requested by a browser, the applet code will not be integrated into the
requesting browser. When this late integration is used , integration testing is no longer feasible.
Hence, what we can do is we can check the version during this late integration.

• Instead of full integration testing, testing against a few possible configurations will be better.
Therefore component vendors need to strengthen the per component process.(for example:
checking whether the component is easily shareable, the vendor must check whether the
component provides the same quality of service even it is shared by multiple applications,
whether the component is implementing the services promised by the interfaces etc.)

MODULES:

• The main goal of modularization is to group similar functionalities together. In procedural

languages, modularization was brought about using subprograms. In object-oriented languages, the
physical building blocks are modules. Here, a module is viewed as a logical collection of objects
and classes.
• Definition: Modularity is the property by which a system can be decomposed into a set of
cohesive and loosely coupled modules. These modules can be implemented, compiled and tested
separately. These tested modules can then be linked together to form a complete executable
program.
• Modules package multiple classes into a single unit. A module differs from a class in the following
ways:

1. Modules do not have the concept of instantiation, whereas classes do.

2. Modules with or without classes from a minimal component. But classes cannot be viewed as
components. For example, traditional math libraries which are functional in nature can be
packaged into modules. These can be viewed as components.
3. When a module has multiple classes, inheritance cannot cross module boundaries.
4. Components are mainly used in plug-and-play.Plug-and-play on a per-class is not feasible. To be
plug-and-play ,a module must satisfy the following requirements:

• It should perform a significant functionality.

• It should group similar classes.

Modules cannot qualify as components due to the following reasons:

5
UNIT-I INTRODUCTION

1. Modules, unlike components, do not have immutable resources. Hence they cannot be configured
without rebuilding its code.
2. Components do not permit observable state, while modules can be built to use global (static)
variables to expose observable state.
3. Modules can depend statically on the implementation of other modules by importing the direct
interfaces from other modules. Even though such static dependencies are available in components,
they are not favored.

INTERFACES:

• Interfaces are the means by which the components connect.Technically, an interface is a set of
named operations that can be invoked by clients.
• An interface specifies the semantics of the operations. This specification plays a dual role as it
serves both providers implementing the interface and clients using the interface.
• Interfaces specify the services provided by the component.
• A component may either provide interface directly or implement objects that, if made available,
provide the required interfaces to the clients. Thus interfaces are categorized as follows:

1. Procedural Interfaces or Direct Interfaces: Interfaces directly provided by a component

correspond to procedural interfaces of traditional libraries. They are called direct interfaces.
2. Object Interfaces or Indirect Interfaces: The interfaces provided indirectly by objects that are
made available by the component are called object interfaces. They are also known as indirect
interfaces.

• The differences between these types of interfaces are:

1. Procedural interfaces are interfaces to procedural implementations. Object interfaces are interfaces
to an object.
2. Procedural interfaces are direct interfaces as the interfaces and their implementation belong to the
same component. Object interfaces use indirection or dynamic lookup. At runtime, object interfaces
resolve a method invocation by retrieving the target object’s class and directing the call to the method
implemented by the class. Method dispatch can lead to the involvement of a third party.
3. Version checking: Procedural interfaces perform version checks at bind time. Object interfaces
perform version checking dynamically when components are accessed. With indirect interface care
must be taken to avoid indirect coupling of parties that are of incompatible versions. For example,
a client originally requesting a service may be capable of working with version 1 of that service. Once
it holds an object reference, it may pass the reference on to another component.However,the latter
component might require version 2 of the service. Unless versions are checked in every place where
an object reference crosses component boundaries, version checking is not sound.
6
UNIT-I INTRODUCTION

Fig: Example of Direct and indirect interfaces:

Figure 1 differentiates between direct and indirect interfaces. Consider the ATMServices component.
It offers a card authentication interface.ATMServices also has a mediator component that can select a
default authentication component. This is done by passing an object that implements the authentication
interface to AMServices.The authentication component is a third-party component. It is used by
directly by the ATMServices as well as indirectly by the other clients of ATMServices.Steps in
indirect access is listed as follows:

1. The authentication component gets information about the mediator component.

2. The authentication component registers itself as default checker with the mediator component.
3. BankServices gathers details about the mediator.
4. BankServices obtains the reference to the authentication component from the mediator.

• Some of the properties of the interfaces provided by the components are:

1. Interfaces define a component’s Access points: A component can have multiple access points
(interfaces) each of which provides a different service. As the component is transparent to its user, the
interface acts as a contract for successful interaction between them. Some of the non-technical features
of contractual interfaces are:

• A component can have multiple interfaces, each representing a service that a component offers.

7
UNIT-I INTRODUCTION

• Interfaces have to be standardized to minimize the possibility of similar interfaces offered by the
component.
• A method to publicize and advertise the components and interfaces is essential to maximize usage
of components and the functionalities offered by them.

2.Component Technology Enforces a strict separation of the interfaces from its implementation:
In component technology, providers and clients are ignorant of each other. Hence the component
specification acts as a middleman to enable the two parties work together. It is therefore important to view
interfaces and their specifications in isolation of any specific component that may implement or use such
interfaces.

3. Interface specification Bind Components: As components are bound dynamically, interface

specifications are essential to glue components together to form an application.
4. Interfaces are Immutable to maintain version compatibility: Multiple versions of the same
component can be loaded and instantiated in the same space. These versions should be checked for
compatibility. For this purpose, once interfaces are published, they are frozen and never changed.
Thus interfaces are described as immutable and help to maintain version compatibility. Supporting
multiple versions is equivalent to supporting multiple interfaces. Once these interfaces are
outdated, they are not supported. These types of immutable interfaces are supported in COM.
5. Interfaces Aid in modularity: Interfaces limit the contextual dependencies between the
components and thus make the system modularized.
6. Interfaces Serve as contracts: A useful way to view interface specifications is as contracts
between a client of an interface and a provider of an implementation of interface. The contract
states what the client needs to do to use the interface. It also states what the provider has to
implement to meet the services promised by the interface. To be effective component, contracts
should be simple and complete.

• A contract has tow sides-the client and the provider. Contracts are established by specifying the
pre-and post-conditions for the operations. The client has to establish pre-condition before calling
the operation. The provider ensures that the pre-condition is met when the operation is called. The
provider establishes the post-condition before returning to the client.
• The interface contract has to ensure both functional aspects (ex: pre-and post-condition) and non-
functional aspects (ex: performance) of the components. Let us consider that the implementation of
the library functions in general purpose software is changed. The procedural interface contracts
should ensure that these changes in implementation do not impact on the performance of a
particular application. For example, the implementation of a math function (like sine or cosine)
may be changed. Since this math library can be used for animation packages, the speed of the math
library functions should be also maintained through the changes. Thus contracts establish the
service-level guarantees(non-functional aspects) such as availabilty, meantime between failures,
throughput latency etc.

8
UNIT-I INTRODUCTION

CALLBACKS:

• Definition: A callback is a procedure that is registered with the library at one point. In times of
need, the library calls the callback procedures.
• Thus the callbacks have to be registered to be used. These callbacks are common in procedural
libraries to handle asynchronous events. They are used in windows library to resize or destroy a
window.

• Fig: Call sequence between library and client in the presence of callbacks:

• In a layered architecture, normal calls always originate from higher layer to lower layer. A
callback reverses the direction of the flow of control, so a lower layer (library) calls a procedure in
a higher layer. For this reason, callback invocations are sometimes called up-calls.
• In a strict procedural library model, it is always the client calling the library. The library operations
always run to completion before returning control. Thus, the client never observes any
intermediate states that the library might go through. The only relevant library states, as far as the
client is concerned, are those just before and after a call to the library.
• In the presence of callbacks, the situation changes. The intermediate library state at the point of
calling the callbacks may be revealed to clients. A library thus has to be careful to establish a
“valid” state, as far as observable by the client, before invoking any callbacks.

9
UNIT-I INTRODUCTION

Example of Callbacks: DIRECTORY SERVICE:

• The Directory service is a part of a simple file system. It supports callbacks to notify clients of
changes in the directory being managed. It is used to provide an up to date visual representation of
the directory to the clients.
• A directory service must provide the following facilities:

1. Lookup for the required file.

2. Addition of named files.
3. Deletion of named files.
4. Registration of callbacks.
5. Deregistration of callbacks.

• These registered callbacks are called on addition/deletion of files. The ‘Directory

services’ make use of a module called ‘Directory’. There are two interfaces within the
module. They are 'Directory’ and ‘DirectoryDisplay’ interfaces.

• ‘Directory’ interface has the following operations:

1. Search file: It takes the name of the file as the input parameter and returns the filename “n” if found in
the folder or it returns NULL. The pre-condition is that the filename “n” should not be empty (NULL).

2. Add file: This operation takes the file to be added and dirname as parameters and add the file to the
specified directory. It checks if dirname and file is not NULL before performing the operation.

3. DelFile: This operation takes the filename “n” and deletes the file from the current directory. It checks
if filename is not NULL before performing the operation.

4. RegisterNotifier: This operation registers the notifiers for callback. These callbacks notify the clients
of the changes in the directory being managed.Notifier is called when a file is added/deleted from the
directory. It checks if notifiername is not NULL before performing the operation.

5. UnRegisterNotifier: This operation unregisters the notifiers when no longer needed. It checks if
notifiername is not NULL before performing the operation.

6. InNotifier: This operation checks if a callback is already in process and if so, it returns a true value.
Only, if no callbacks occur, then AddFile and delFile operation should be called. Hence the value returned
from this operation is used in AddFile and DelFile operation as pre-conditions.

10
UNIT-I INTRODUCTION

• The interface ‘DirectoryDisplay’ has an operation called Notifier.It checks if the file is deleted or
a new file is added to the current directory. If so, it makes the corresponding changes in the
directory being displayed.

• Fig: The module DIRECTORYSERVICE with ‘Directory‘ and ‘DirectoryDisplay’ interfaces is

shown with pre-conditions and post-conditions as follows.

module DIRECTORYSERVICE
{
Interface Directory
{

• The client of the above-mentioned directory service uses directory callbacks to maintain a visual
display of the directory contents.
11
UNIT-I INTRODUCTION

• The DirectoryDisplay class displays the updates on the client side. If the filename “n” is
deleted/added, then the directory service should update the current display by adding/deleting it
respectively from the display. For this, the notifier is called in the AddFile and DelFile operations
before returning.

• Whenever some changes occur in the Directory (addition/deletion of file), the directory service
will call the registered callbacks. For this the client has to develop the notifier and register that by
calling the method ‘RegisterNotifier’ of Directory interface.

Fig:A client of the Directory service:

/*Notifier begins*/
PROCEDURE Notifier(IN n:Directory.Name);

BEGIN
If.Directory.ThisFile(n)=NIL Then
(*entry under name n has been removed-delete n in display*)
ELSE
(*entry has been added under name n-include n in display*)
END

END NOTIFIER

Directory.RegisterNotifier(Notifier) /*As a client you are connecting your event handler(here its
notifier procedure) to the the directory events(addition/deletion of files).so as you have registered your
handler ,whenever addition/deletion of file happens ,the directory callbacks your notifier procedure. Hence
the Notifier procedure is known as callback procedures.*/

• The sequence of steps in the AddFile procedure is as follows:

1. Check the pre-conditions and ensure that dirname and filename is not NULL.(For example,
add a file file1’ to the directory ‘dirname’)
2. Search the directory with dirname for file1.
3. If file1 is not available in the directory then add the file1 to the directory.
4. If file1 is available in the directory then replace the old file with newfile.
5. Invoke the notifier. ( That is, Whenever some new file has been added in the directory
,then it should be notified to the clients of the directory ,so that the client can have a up to
date visual representation of the directory.)

12
UNIT-I INTRODUCTION

COMPONENT ARCHITECTURE:

• While developing a complex system, in order to provide rules for design and development, an
architecture is needed.

• Object cannot serve as units of deployment. Hence component architecture is used. The
architectural components of component-based system are:

13
UNIT-I INTRODUCTION

14
UNIT-I INTRODUCTION

COMPONENTS AND MIDDLEWARE:

• Middleware is computer software that connects software components or some people and their
applications. The software consists of a set of services that allows multiple processes running on
one or more machines to interact. This technology evolved to provide for interoperability in
support of the move to coherent distributed architectures.
• Example for middleware technologies:RMI,EJB,CORBA,COM

15