UNIT V

COMPONENT FRAMEWORKS AND DEVELOPMENT

Connectors – contexts – EJB containers – CLR contexts and channels – Black Box
component framework – directory objects – cross-development environment – component-
oriented programming – Component design and implementation tools – testing tools -
assembly tools
COMPONENT FRAMEWORK:
Definitions of key terms :
A component framework is a dedicated and focused architecture of a few key
mechanisms and a fixed set of policies for mechanisms at the component level.
A component system architecture consist of a set of platform decisions, a set of
component frameworks, and an interoperation design for the component frameworks.
Component framework is a software entity,which defining certain standards and
allowing “Plug-in”. It is also a component.
5.1.CONNECTOR :
Connectors can then perform actions of synchronisation, encryption , authentication,
and so , on.
The roots of ADLs are Module Interconnection Languages(MILs) , originaaly
proposed to address the problems of programming in-the large.
Connectors represent interactions among components. Examples include simple forms of
interaction, such as pipes, procedure call, and event broadcast.
Below figure represent the configurations of components and connectors.

• In Pure-connection oriented approach, all component are restricted to only interact

with other components if connected appropriately.
Figure Classification of Architectural Element
 Architecture Element

Build-in User-
defined

Component Type Connector Type

Computation Procedure Call

Component Data flow

Manager Implicit triggering

Controller Message passing

Connectors are the basis of Architecture Description Languages

 ADL is built on connection oriented programming
 Connectors are used to compose components
 With ROOM (Real-time Object-Oriented Modeling) it has been possible to reuse the
same description for all instances of a component and through-out the inheritance tree.
 In ROOM , Component instances are called actors, which communicate by
exchanging messages following protocols.
 A ROOM derivative called UML-RT has been proposed as a UML profile,where
ROOM style actors are now called Capsuals.
ADL :
o It is typically distinguish components and connectors. Components are meant
to provide .
o Early ADLs are were restricted to static connectivity, but later it supports
dynamic connectivity.
o To increase the understandability and reusability of architectural designs, and
enable greater degrees of analysis.
• Metaprogramming has its roots from Lisp systems
o Its idea is to have a metaprogram which inspects and manipulates another
program and its execution
o Suggests a separation of aspect code and functional code, however has binding
problems and is not commonly supported
• Aspect-oriented programming vs Contextual Component Framework
o AOP can be called as static metaprograming
o DCOM and Corba use and IDL to capture aspects.
 o Recently an AspectJ is introduced as an extension to Java
5.2.CONTEXTS :
COM+ Contexts :
Frameworks for Contextual Composition: COM+
• For configured components running within COM+ applications, contexts are the
foundation on which COM+ services are provided.
• In COM+, a context is defined as set of run-time properties associated with one or
more COM objects that are used to provide services for those objects.
• In COM+, every COM object is associated with precisely one context as it runs (that
is, between its activation and deactivation), and every context resides within precisely
one COM apartment.
• Multiple objects can run within the same context, and multiple contexts can reside
within the same apartment
• Initialized when an object is activated, context properties, such as security context
properties, represent the run-time needs of an object.

• COM+ uses,
 COM apartments
 MTS (Microsoft Transaction Server)contexts
• COM apartments separate objects by threading model
• COM classes configured for use with MTS carry declarative requests in new or non-
existing transactional contexts.
• DTC (Distributed Transaction Coordinator) creates transactional domains and each
domain is considered as a single thread.

Figure shows Domains and Contexts

Wher c1,c2,c3 are Contexts and x,u,v,w are objects.
Note: For unconfigured components that do not use COM+ services, the context is, for the
most part, ignored.
• COM+ uses context properties as the basis for providing run-time services. These
properties hold state that determines how the execution environment performs
services for objects within the context.
• In some cases, you can interact directly with an object's context properties to indicate
some state relevant to a service being provided for the object.
• Activation, or the initialization of an object in an appropriate context.
• Interception, or what COM+ does on calls across a context boundary.
CONTEXT ACTIVATION:
In COM+, every COM object is created with an associated context. This means that
either a new context must be created and initialized or an appropriate existing context is
used. This process is known as activation.
INTERCEPTION OF CROSS-CONTEXT CALLS :
When an object is activated in a given context, subsequent calls to or from it, within
the context, are handled differently than calls across the context boundary. Calls across
the context boundary are handled with lightweight proxies. These proxies handle
whatever mediation is required to adjust the run-time environment from one that
accommodates the caller to one that accommodates the callee. This process is known as
interception.
Cross-context call interception is necessary because objects in different contexts have
different run-time requirements—this is precisely the reason for contexts.
Some Context Services are,
• ObjectContext
• GetObjectContext
• IObjectContext
• IObjectContext::SetComplete
• COM+ Just-in-Time Activation
• IContextState
• IObjectContextActivity
• ISecurityCallContext
• GetSecurityCallContext
5.3. EJB CONTAINERS :
Enterprise JavaBeans (EJB) technology is the server-side component architecture for
Java Platform, Enterprise Edition (Java EE).
 Enterprise Java Beans is a component architecture for the development and
deployment of object-oriented, distributed, enterprise-level applications.

Applications written using the Enterprise JavaBeans architecture are scalable,

transactional, multi-user and secure.
EJB containers
An Enterprise JavaBeans (EJB) container provides a run-time environment for
enterprise beans within the application server. The container handles all aspects of an
enterprise bean's operation within the application server and acts as an intermediary
between the user-written business logic within the bean and the rest of the application server
environment.
One or more EJB modules, each containing one or more enterprise beans, can be installed in
a single container.
The EJB container provides many services to the enterprise bean, including the following:
• Beginning, committing, and rolling back transactions as necessary.
• Maintaining pools of enterprise bean instances ready for incoming requests and
moving these instances between the inactive pools and an active state, ensuring that
threading conditions within the bean are satisfied.
• Most importantly, automatically synchronizing data in an entity bean's instance
variables with corresponding data items stored in persistent storage.

The architecture of EJB container comprises of

EJB Home: serves as class factory
EJB object: used to perform business process i.e provide client view of the application.
 EJB Home

Create,find,
remove

client Enterprise Bean

methods EJB Object

Figure . Interaction of EJB Object and EJB Home

SERVICES:
• Beginning, committing, and rolling back transactions.
• Maintaining pools of enterprise bean instances ready for incoming requests and
moving these instances between the inactive pools and an active state, ensuring that
threading conditions within the bean are satisfied.
Automatically synchronizes data with corresponding data items stored in persistent storage.
Explicit transaction Services :
EJB pattern is almost the same as that of MTS but classes can be given attributes so
that their instances can explicitly call on transaction API to explicitly begin, commit or abort
a transaction by themselves.
Existence of persistence Object :
Containers in EJB support persistent objects by distinguishing between session and
entity beans. In session beans, state is lost once enclosing transaction terminates. In entity
beans, state is transferred to a persistent store of a transaction has committed.
Container Managed persistence :
EJB provides improved container manager persistence and relationship, improving
portability of EJB beans from the container of one vendors application server to that of
another.
Local Objects :
These are the objects within the same AppDomain.
Remote Objects :
All other(except local objects ) objects are “Remote”. Evne if the AppDomain are
hosted within the same process.
Enterprise beans
• An enterprise bean is a Java component that can be combined with other resources to
create J2EE applications. There are three types of enterprise beans, entity beans,
session beans, and message-driven beans.
 • All beans reside in EJB containers, which provide an interface between the beans and
the application server on which they reside.
• Entity beans store permanent data, so they require connections to a form of persistent
storage. This storage might be a database, an existing legacy application, a file, or
another type of persistent storage.
• Session beans typically contain the high-level and mid-level business logic for an
application. Each method on a session bean typically performs a particular high-level
operation. For example, submitting an order or transferring money between accounts.
Session beans often invoke methods on entity beans in the course of their business
logic.
• Session beans can be either stateful or stateless. A stateful bean instance is intended
for use by a single client during its lifetime, where the client performs a series of
method calls that are related to each other in time for that client. One example is a
"shopping cart" where the client adds items to the cart over the course of an online
shopping session. In contrast, a stateless bean instance is typically used by many
clients during its lifetime, so stateless beans are appropriate for business logic
operations that can be completed in the span of a single method invocation. Stateful
beans should be used only where absolutely necessary -- using stateless beans
improves the ability to debug, maintain, and scale the application.
Message-driven beans enable asynchronous message servicing.
• The EJB container and a Java Message Service (JMS) provider work together to
process messages. When a message arrives from another application component
through JMS, the EJB container forwards it through an onMessage() call to a
message-driven bean instance, which then processes the message. In other respects,
message-driven beans are similar to stateless session beans.
• The EJB container and a Java Connector Architecture (JCA) resource adapter work
together to process messages from an enterprise information system (EIS)
EJB modules
An EJB module is used to assemble one or more enterprise beans into a single deployable
unit. An EJB module is stored in a standard Java archive (JAR) file.
An EJB module contains the following:
• One or more deployable enterprise beans.
• A deployment descriptor, stored in an Extensible Markup Language (XML) file. This
file declares the contents of the module, defines the structure and external
dependencies of the beans in the module, and describes how the beans are to be used
at run time.
 You can deploy an EJB module as a stand alone application, or combine it with other EJB
modules or with Web modules to create a J2EE application. An EJB module is installed and
run in an enterprise bean container.
5.4.CLR CONTEXTS AND CHANNELS:
o CLR context infrastructure attempts to provide an extensible infrastructure for
contextual composition.
o Third parties ca introduce new properties to context boundaries.
o CLR objects come in four top-level flavors:
 Value types
 Pass-by-value types
 Pass-by-reference types
 Context-bound types
o Standard types include marshalling over SOAP/HTTP and DCOM
Common Language Runtime is an execution engine and a full-featured class library
built to the specification of the Common Type System (CTS). CLR is responsible for loading
and running the application safely. It handles garbage collection and security checks. Code
that runs in CLR is called managed code.
CLR uses two types channels like TCP Channel and HTTP Channels.
TCP Channel :
The TcpChannel class uses a binary formatter to serialize all messages to a binary stream and
transport the stream to the target Uniform Resource Identifier (URI) using the TCP protocol.
The TcpChannel performs the following functions:
• Provides communication between sender and receiver using TCP sockets.
• Provides encoding of payloads in binary format and the industry standard SOAP
serialization format.
• Generates and consumes ChannelDataStore for object references.
The TcpChannel opens and caches as many connections as there are threads making requests
to another server at that moment. Socket connections are closed on the client after 15-20
seconds of inactivity.
HTTP Channels:
The HttpChannel class transports messages to and from remote objects using the
SOAP protocol. All messages are passed through a SoapFormatter object, where the message
is changed into XML and serialized, and the required SOAP headers are added to the stream.
The HttpChannel is compliant with SOAP 1.1 and performs the following functions:
• Provides communication between sender and receiver using the HTTP protocol as a
transport.
• Provides encoding of payloads in SOAP, an XML encoding standard.
 • Sets the receiver to receive HTTP requests and send HTTP responses in ASP.NET
and on a TCP socket.
• Generates and consumes ChannelDataStore for object references.

The CTS ensures that all code is self-describing.Having the .NET compiler insert
metadata that carry information about the resources needed like types, references and
member variables. The runtime uses metadata to .nd and load classes and to be able to
(layout) done space for instances. The CLR handles automatic memory management, like
garbagecollection, this eliminates common errors like invalid memory references and
memory leaks.
To handle interoperability between programming languages, the .NET Framework
types are CLS compliant and can therefore be used from any programming language that
targets the CLR and supports the CLS. Code written in different .NET languages can be
combined.
CLR is an implementation of the Common Language Infrastructure (CLI)
speci.cation, adding COM+ interoperability and Windows platform access services.In
particular CLR over dynamic loading and unloading, garbage collection, context interception,
metadata rejection, remoting, persistence and other runtime services that are fully language
independent.
CLI defines a language neutral platform and an intermediate Language (IL) and
deployment .le format (assemblies). CLI also includes support for extensible metadata. The
CLR is the implementation of the CLI speci.cation.
Application domain :
In .NET the primary application boundary is the AppDomain and not a process. CLR
partitions a process into one or more application domains (AppDomain). An AppDomain
isolates a set of objects from all objects in other AppDomains, but is more lightweight and
thus cheaper than a process. Communications across AppDomain boundaries requires
marshalling (Communication through proxy objects that handle the communication channel).
.NET managed code must be verified by the CLR. This means that the code is type safe and
that the CLR can provide equal level of isolation as the operating system process through
application domains. This increases performance. The application domains do not have to
make cross-process calls or switch between processes. Additional benefits are that individual
applications can be stopped or unloaded without stopping the entire process. The CLR uses
threads to execute code.
Context
Finer execution space beyond AppDomains is provided by Contexts. An App- Domain can
contain many contexts and must contain at least one called default context. A context
provides an environment with a set of properties shared by all objects that exist in the
context. It provides an interception boundary for the runtime to apply pre and post processing
to all method calls from outside the context. The Context is a home for objects with similar
runtime requirements such as synchronisation or just-in-time activation. shows how a process
can be divided into application domains, which in turn will contain one or more contexts.

5.5.BLACK BOX COMPONENT FRAMEWORK :

Carrier-rider-mapper design pattern
- - Separation into three parts
– • Carriers –
– Data carrying objects that can be accessed by position.
– Direct interfaces (implementation interface) for reuse and extension
• Riders –
– Encapsulate access paths to data in carriers
– Client can access the interface with riders
– • Mappers - Data formatting filters which directs to the specific client

- Different ways to access data bottleneck

• Directly by interfaces of Carriers
• Through Riders --- more efficient
• Through Mappers --- more suitable to requirements
• Directory Objects (Factory Objects)
– New objects are created using factory objects
– Eg File abstraction
- Used to instantiate a new object
• Language-level NEW is not available in BlackBox
 - Default directory objects
• Hierarchical model view separation (HMVC)
– View – visual representation of data that can be Context-sensitive
– Model – represents and manage data presented by views
 Controllers - Interact with the user and interpret the user input.
+ Introduction to MVC (model view controller)
• Multiple views display the same model
• View can be customized through its controller
+ HMVC vs. MVC
• A model can contain nested views in HMVC
• Documents correspond to the root view
• Container modes
+ Aiming to take advantage of unification of construction and use of components
without losing control. It Separate the design of the component and its usage.
– Containers can be set in any mode:

• Edit mode
• Layout mode
• Brower mode
• Mask mode
• Cascade Message Multicasting Services
– Message objects are used to decouple to MVC
5.6.DIRECTORY OBJECTS:
BLACKBOX PATTERNS
BlackBox uses four major creational patterns:
1) prototypes
2) factory methods
3) directory objects
4) factory managers
PROTOTYPES
• Sometimes it is necessary to create an object of the same type as some other already
existing object.
• In this case, the existing object is called a prototype, which provides a factory
function or initialization method.
• BlackBox models can act as prototypes.
• For example, it is possible to clone a prototype and to let the prototype initialize its
clone.
 • This makes sure that the newly created object has exactly the same concrete type as
the prototype, and it allows the prototype and its clone(s) to share caches for
performance reasons.
• For example, a BlackBox text model and its clones share the same spill file that they
use for buffering temporary data. Sharing avoids the proliferation of open files

Var t,t1:TextModels.Model
…
t:=…;
t1:=TextModels.Clone(t);
t1.InsertCopy(t,0,42);
…

FACTORY METHOD
• Sometimes there exists an object that can be used to create an object of another type.
• For this purpose, the existing object provides a factory function, a factory method.
• Possibly, the object may provide different factory methods which support different
initialization strategies or which create different types of concrete objects.

• In BlackBox, a text model provides the procedures NewReader and NewWriter, which
generate new readers and writers.
• They are rider objects that represent access paths to a text.
• Factory methods are appropriate for objects that are implemented simultaneously
("implementation covariance"). This is always the case for riders and their carriers
DIRECTORY OBJECTS
• In black box abstraction not even the name of the implementation are made public.
• So use of NEW statement is not helpful
• New objects are created using factory methods or factory objects
• These factory objects are termed as the directory objects
• In BlackBox, factory objects are used in a particular way:
• They are installed in global variables and may be replaced at run-time, without
affecting client code.
 For historical reasons, we call factory objects which are used for configuration
purposes directory objects.
For example
• module TextModels exports
 the type Directory which contains a New function,
the two variables dir and stdDir
 and the procedure SetDir.
• By default, TextModels.dir is used by client code to allocate new empty text models.
• TextModels.stdDir contains the default implementation of a text model,
• which is mostly useful during the debugging of a new text model implementation.
• For example, you could use the old directory while developing a new text model
implementation.
• When the new one is ready you install its directory object by calling SetDir, thereby
upgrading the text subsystem to the new implementation.
• From this time, newly created texts will have the new implementation.
• Texts with the old implementation won't be affected.
• If the new implementation has errors, the default implementation can be reinstalled by
calling TextModels.SetDir(TextModels.stdDir).

Var t1:TextModels.Model
…
t1:=TextModels.Clone(t);
t1.InsertCopy(t,0,42);
…
t.Replace(0,42,t1,t1.Length())

• Note that objects allocated via directories are often persistent and their
implementation thus long-lived.
• For this reason, several different implementations appear over time which have to be
used simultaneously.
• Typically, the normal default directory objects of a subsystem are installed
automatically when the subsystem is loaded.
• If other directory objects should be installed, a Config module is used to set up the
desired directory object configuration upon startup.

• The name "directory object" comes from another use of the directory design pattern:
 in module Files, a file can be created by using the directory object Files.dir.
• But a Files.Directory also provides means to find out more about the current
configuration of the file system (e.g., procedure Files.Directory.FileList.)
VAR f:Files.File;
…..
f:=Files.dir.old(Files.dir.This(“/dev”),”null”);

Fileused to open an existing old file or create a new one

• File directories are interesting also because they show that a replacement directory
may sometimes need to forward to the replaced directory object.
• For example, if the new directory implements special memory files, which are
distinguished by names that begin with "M:\", then the new directory must check at
each file lookup whether the name begins with the above pattern.
• If so, it is a memory file.
• If not, it is a normal file and must be handled by the old directory object.
• There may exist several directory objects simultaneously. For example, if a service
uses files in a particular way, it may provide its own file directory object which by
default forwards to the file system's standard directory object
• Multiple directory objects and chaining of directory objects are part of the directory
design pattern. This chaining part of the pattern is cascadable, if a new directory
object accesses the most recent old one, instead of stdDir.
• Note that unlike typical factory classes, directories are rarely extended.
Forwarding between two directory objects

client code
performs allocation
via dir variable

new default
directory directory
object object

dir stdDir

• A registry would be a valuable addition to directory objects.

 • A registry is a persistent central database which stores configuration information,
such as the particular directory objects to install upon startup.
• The problem with registries is that they contradict the decentral nature of software
components, which leads to management problems such as finding registry entries
that are no longer valid.
• Directory objects are a solution involving global state.
• This is only desirable if this state changes rarely, and if no parallel activities occur
(threads).
• For example, in server environments a state-free solution is often preferable.
• This can be achieved by parameterizing the client: the client must be passed a factory
object as parameter.
• This makes it possible to determine the exact nature of an implementation at the "top"
of a hierarchy of procedure calls, always passing the factory object "downward".
• This is useful since the top-level is typically much less reusable than lower-level
code.
FACTORY MANAGERS
• suitable for creating non-persistent objects
• while directory objects are often more suitable for creating persistent objects.
• Instead of passing a factory object, its symbolic name may be passed.
• At the "bottom", a service interprets this name; if necessary loads the module which
implements the corresponding factory function; and then creates an object using the
factory function.
• In this way, the service acts as a factory manager.
• This approach is used for some BlackBox services, in particular for the Sql and
Comm subsystems.
• In both cases, the name of a module can be passed when allocating a new object.
• For Sql, the modules SqlOdbc and DtfDriver provide appropriate object
implementations and factory functions.
• For Comm, the module CommTCP provides a suitable object implementation.

PORTOS -A HARD REALTIME COMPONENT FRAMEWORK AND ITS IDE

• Portos is a realtime operating systems implemented in component Pascal.

• New components can be loaded at runtime if the systems is connected to a server.
• Portos teams with rapid application development tool that is built on top of BlackBox.
STRUCTURE OF PORTOS

• Portos core is a small runtime environment for embedded or realtime systems.

• It includes a heap manager and a garbage collector and is designed in such a way that
it never interferes with other tasks.

• The rectangles represent individual Component Pascal modules.

• Rectangles with thicker outline are complete subsystems consisting of several
modules or open collection of component implementations.
• The Comm subsystems is a component framework for reliable communication via
serial bytestreams.It supports extensibility in four dimensions ,namely
clients,services,channels,protocols.
• The process peripheral modules constitute a component framework for input/output of
digital and analog data.It supports extensibility in three dimensions –
applications,device drivers and scales.
• Various configurations of Portos are possible .
• At the least ,modules PortosKernel and PortosTask are required.
 • PortosKernel contains some unsafe low level facilities and heap manger and the
garbage collector.
• PortosTask is the interface for developers of hard realtime applications.
• Optionally, module PortosThreads may be added.
• It implements a scheduler for prioritized threads-that is tasks that are not time critical.
• Their scheduler can be plugged into module PortosTask.If desired , PortosThreads
could be replaced by other threading mechanism.
• Several modules from BlackBox component framework is available for Portos,in
particular Meta and CommStreams.
• PortosLog is a simple console output service that uses the communication facilities to
send output to a host computer running the Portos IDE.
• Several optional modules implement server functionality that can be used during cross
development and for visualization purposes.
• A user can issue remote commands in the IDE,which are executed on the Portos.New
modules can be installed on Portos in this way.
• PortosLoader is necessary to load new module at runtime.
• New code files can be downloaded from the host using the communications facilities
and then loaded into the memory.These code files contain native machine code,not
intermediate byte code .
• Module loading and unloading is fully dynamic the loader is an optional service that
can be left out in closed embedded systems that have no communication facilitites.

REALTIME SCHEDULER

• The central module is the PortosTasks.

• A combination of monitor and signal is used as the synchronisation construct but its
definition is compatible with the java.lang.Object class ,in that it supports suitably
defined Enter,Exit,Wait,Notify, NotifyAll methods.
• A task represents a concurrent process,which is implemented by a
PortosTasks.Handler object.Handler object contain an abstract method called Run
,which implements the code of the process.
• An optional exception handler may be implemented or the system’s default exception
handler is used.
• Tasks are inactive after they have been created with one of the NewTask factory
functions .
 • They can be stopped,started,suspended,resumed,and sent to sleep for some time
• A task may not run for an indefinite amount of time.
• A task must terminate before some deadline has passed or some amount of time has
been consumed.
• If the constraint is violated then exception handler is called.This means that the hard
realtime scheduler knows about time ,and uses it for scheduling purposes(“Earliest
DeadlineFirst” scheduling).
• If the processor gets saturated , he scheduler rejects new tasks.This is an example of a
component –oriented approach in the realtime domain.

JBED
• A Java version of Portos called JBed is largely identical to Portos ,but provides Java
interfaces to the kernel’s services.
• Esmertec's Jbed Micro Edition CLDC is a Java virtual machine (JVM) for PDAs
(Personal Digital Assistants), mobile phones, and Internet appliances
• The scheduler,class loader,heap manager,,and the realtime garbage collector for
Component Pascal and Java are identical.
• JBed is fast because the kernel directly implements the runtime environment needed
for Java-there is no inefficient translations or expensive kernel calls.
• The Portos/JBed core is the virtual machine ,except Java byte code is translated by
across –compiler before downloading into the embedded system.
5.7.COMPONENT ORIENTED PROGRAMMING
Introduction:
Component-oriented programming has now become a recognised software development
method. This follows a move away from large, monolithic, difficult-to-maintain software
systems to be replaced by systems comprising multiple binary components.
Such systems achieve greater
 reusability
 extensibilty, and
 Maintainability
and also benefit from being
 faster to market
 more robust
 highly scalable, and have
 lower development and long-term maintenance costs
Component technologies:
There are several technologies available to implement component-oriented applications,
E.g.
• DCOM - Distributed Component Object Model is based on the COM providing a set
of interfaces to allow clients and servers to communicate within the same computer
• CORBA - Common Object Request Broker Architecture is an architecture and
specification for creating, distributing, and managing distributed program objects in a
network.
• JavaBeans - is an object oriented programming interface from sun micro system that
facilitates the building of re-usable applications or components that can be used in a
network on any major operating system platform.
• . Net -
Terminology :
• A component provides the business logic to clients.
• A client is any entity that uses the component.
• An object is an instance of a component; similar to the classic OO definition of an
object as an instance of a class.
• The object is also referred to as the server and the relationship existing between the
client and the object as the client/server model.

A client creates an object and accesses its functionality via a publicly available entry point: a
public method or, preferably, an interface.
COP vs OOP :
Essentially
• OOP focuses on the relationship between classes that are combined into one large
binary executable, whereas
• COP focuses on interchangeable code module that work independently and does not
require familiarity with their inner workings to use them.
In OO, the business logic many well be achieved using numerous classes, but when they are
combined the result is monolithic binary code. Although developers may work on individual
classes to agreed APIs, eventually the classes are tested and linked. Each subsequent class
change will require the entire application being re-linked, and retesting and re-deployment of
all the other classes.
A component-oriented application comprises a collection of interacting binary application
modules, i.e. the components and the calls that bind them.
 -- components Call that binds component
• No existing clients of the component requires recompilation or redeployment. In fact
components may be updated while the client is running , provided the client is making
use of the component at the time.
• Improvements, enhancements and fixes to components becomes available
immediately whether on the same machine or across a network.

Principles of COP:
The more important are:
• Separation of interface and implementation
• Binary compatibility
• Language independence
• Location transparency
• Version control
• Concurrency management
• Component-base security
Interface separation:

• The interface is a logical grouping of method definitions that provides a service

contract between client and object. It is implemented by a black-box binary
component that completely encapsulates its interior.
 • To use a component, the client need only know the interface definition to be able to
access a binary component that implements the definition.
• Almost certainly OO methods will be employed to implement the functionality inside
the component as represented by the interface.
• Interfaces facilitate reuse. In OOP the unit of reuse is the object and it may be argued
time and effort is saved by not having to implement and test the object.. In COP, the
unit of reuse is the interface, not a component, which in turn facilitates the reuse of
existing and new components.
Binary compatibility:
Traditional OOP requires both clients and servers to be part of a monolithic
application. During compilation, server entry points are inserted into the client code.
• COP involves packaging binary code into components. Any changes to the
component are contained in the binary unit and hence does not require the client to be
recompiled and redeployed.
• Accordingly the client code is able to interact at run time with exactly what might be
expected as far as the binary layout in memory of the component entry points.
This ability to replace or plug-in new binary versions of the server implies binary
compatibility between client and server.
Language independence:
• Since the client interacts with the server only at run-time, they are only bond by virtue
of binary compatibility. Consequently the choice of programming language to
develop and deploy components should be irrelevant.
• Language independence promotes interchangeability of components, and the adoption
and reuse.
• Example: .NET achieves language independence through an architecture and
implementation called the Common Language Runtime (CLR) which will be covered
later.
Location transparency:
A component-base application is likely to comprise multiple binary components.
These can exist
• in the same process
• in different processes on the same machine
• on different machine on a network, or
• with the advent of web services distributed across the internet
 A component technology provides a client with location transparency such that the
client code is oblivious to the actual locations of the objects it uses. This allows
• client and components to be developed locally then distributed across a network
• a choice as to whether to use the same process for all components or multiple
processes for multiple machines

Versioning support:

• COP allows clients and components to evolve separately. Hence developers are able
to deploy new versions (or just fixes) of existing components without affecting
existing client applications.
• Further client development expect to be able to develop new versions of a client
application and expect them to work with the older (familiar) versions of the
components.
• Incompatibility of components to client are signalled.
Let us consider an example
• Consider a typical DLL Hell scenario involves two client applications:
• Suppose application A1.0 and B1.0, each use version C1.0 of a component held in the
mydll.dll file.
• Both A1.0 and B1.0 install a copy of mydll.dll in some global location, such as the
System directory.
• Subsequently, when a version A1.1 is installed, it also install version C1.1 of the
component, providing new functionality in addition to the functionality defined in
C1.0. mydll.dll can still contain C1.1 and serve both old and new client application
versions. Old clients will be unaware of the new functionality available
• A problem arises when application B1.0 is reinstalled. As part of the reinstallation,
C1.0 is reinstalled, overriding C1.1 and consequently A1.1 is broken and will no
longer execute.

Concurrency management:
 • It is not possible in advance to know all the ways in which a component might be
used or, in fact, whether several applications will use it simultaneously.
• Incorporating a synchronisation mechanism within a component, however, might lead
to deadlocks if each component has its own or if two components attempt to access
each other.
• This is overcome by providing a concurrency management service such that
components participate in an application-wide synchronisation mechanism even when
components are developed separately.

Component-based security:

• Component developers have no way of knowing how a client application or end user
will attempt to use their work, whether above-board or malicious.
• Similarly, a client application does not know whether it is interacting with a malicious
component. Even if client and component have no ill intent, damage can still be
caused inadvertently.
• Consequently a component technology provides a security infrastructure to deal with
such situations. This is kept to a minimum and is detached from the code itself.
• Systems administrators are still able to customise and manage the application security
policy without requiring changes to the code.

Example for Component Reusability in .Net :

Create Class Library
• Name the project ResponseLibrary
• Rename default Class1, Response
• Open new project and select Class Library template:
• Enter the following
code:
Public Class Message
Public Sub Method1()
MsgBox("This is method 1 version 1")
End Sub
Public Sub Method2()
MsgBox("This is method 2 version 1")
End Sub
End Class
• Click Build|Build ResponseLibrary
 Client
Create client software (Windows application)
• Name new project proj1
• Enter button called cmdRun on Form1
• Create Click handler for cmdRun
• Click Project | Add Reference and navigate to ResponseLibrary.dll in
……\ResponseLibrary\ResponseLibrary\bin\Release and select.
• Ensure that the code reads:
Imports ResponseLibrary
Public Class Form1
Private Sub cmdRun_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles cmdRun.Click
Dim aResponse As Response = New Response
aResponse.Method1()
aResponse.Method2()
End Sub
End Class
• Compile and run
 Modifying component
• Return to ResponseLibrary and change version number in message box lines.
• Rebuild ResponseLibrary
• Copy ResponseLibrary.dll from project folder and replace existing file in proj1
folder.
• Run proj1.exe from project folder
Note that changes to messages have been performed without recompiling the client

5.8.COMPONENT TESTING TOOLS:

• Components can only be tested in a few configurations.
• Systematic approaches to testing of components are needed and intense tool support
for this purpose is likely to be required.
• Faced with the extreme difficulties of components testing, two strategies seem
advisable.
 The first strategy is avoiding errors statically wherever possible. For example,
a safe and expressive language can allow a compiler or analyzing tool to catch
substantial errors statically. Even better, a carefully crafted language can rule
out entire classes of errors.
  The second strategy is to make sure that components are deployed in such a
way that faults leave logged traces. In this way, a failure in a production
component system can at least be traced.
Examples:
* QTP Testing Tools
* Win Runner Testing Tools
* Load Runner Testing Tools
* Test Director Testing Tools
* Silk Test Testing Tools
* Test Partner Testing Tools
QTP:
Quick Test Professional (QTP) is an automated functional Graphical User Interface
(GUI) testing tool that allows the automation of user actions on a web or client based
computer application.
Testing Process:
Test - A compilation of steps organized into one or more actions, which we can use to
verify that our application performs as expected.
1) Planning
• Determine the functionality you want to test, short tests that check specific functions
of the application or complete site.
• Decide how you want to organize your object repositories.
2) Creating Tests or Components
We can create a test or component by
a) Either recording a session on your application or Web site.
As we navigate through the application or site, QuickTest graphically displays each step we
perform as a row in the Keyword View. A step is something that causes or makes a change in
your site or application, such as clicking a link or image, or submitting a data form.
b) Build an object repository and use these objects to add steps manually in the Keyword
View or Expert View.
We can then modify your test or component with special testing options and/or with
programming statements.
3) Inserting checkpoints into ther test or component.
A checkpoint is a verification point that compares a recent value for a specified
property with the expected value for that property. This enables you to identify whether the
Web site or application is functioning correctly.
4) Broaden the scope of the test or component by replacing fixed values with
parameters.
 • To check how the application performs the same operations with different data we can
parameterize our test or component.
• When we parameterize your test or component, QuickTest substitutes the fixed values
in our test or component with parameters
• Each run session that uses a different set of parameterized data is called an iteration.
• We can also use output values to extract data from our test or component. An output
value is a value retrieved during the run session and entered into the Data Table or
saved as a variable or a parameter. We can subsequently use this output value as input
data in your test or component.
5) Running the test
• After creating test or component, we run it.
• When we run the test or component, QuickTest connects to our Web site or
application and performs each operation in a test or component, checking any text
strings, objects, or tables you specified.
6) Analyzing the results
• After we run test or component, we can view the results in the Results window.
• We can view a summary of the results as well as a detailed report.
• Report defects identified during a run session.
5.9.ASSEMBLY TOOLS :
Components are assembled by instantiating and connecting component instances and
customizing component resources
• WebSphere Application Server supports three tools that you can use to develop,
assemble, and deploy J2EE modules: Application Server Toolkit (AST), Rational
Application Developer (RAD), and Rational Web Developer. These tools are referred
to in this information center as the assembly tools.
• One or more tools are available on separate CD-ROMs in your WebSphere
Application Server CD-ROM package. RAD is available only on a trial basis in the
WebSphere Application Server CD-ROM package.
• The assembly feature of the AST, RAD and Rational Web Developer and products
runs on Windows and Linux Intel platforms. Users of WebSphere Application Server
on other platforms must assemble their modules using an assembly tool installed on
Windows or Linux Intel platforms