CBT1

COMPONENT BASED TECHNOLOGY
RAJA COLLEGE OF ENGINEERING & TECHNOLOGY, MADURAI-20.
DEPARTMENT OF INFORMATION TECHNOLOGY
COMPONENT BASED TECHNOLOGY STUDY MATERIALS
Unit I INTRODUCTION
Software component – objects – fundamental properties of component technology –

modules – interfaces – callbacks – directory services – component architecture –
components and middleware.
1. Introduction
Software components are executable units of independent production, acquisition, and

deployment that can be composed into a functioning system. To enable composition, a
software component adheres to particular components model and targets a particular
component platform. Composite systems composed of software components are called
component software. Components are the way to go because all other engineering
discipline introduced components as they become mature – and still use them.
1.1. Software Component
 A self-contained unit of software code consisting of its own data and logic,
with well-defined connections or interfaces exposed for communication.
 It is designed for repeated use in developing application, either with or
without customization.
 A software component is a loosely defined term for software technology for
encapsulating software functionality. It is an object written to a
specification (i.e. COM, Java Bean, etc.)
 A component is a reusable piece of software that can be assembled easily to
create applications. The basic idea of developers is to build small reusable
components once and reuse them as many times needed.
 Marshalling is employed to turn the component or one of its interfaces into
a bit stream.
1.1.1. Definition
“A component is a binary unit of independent production, acquisition and deployment

that interact to from a functional system”
1.1.2. Use of Components
 Components are the way to go because all other engineering disciplines

introduced components as they became mature & still use them.
 “Software integrated circuit” to resolve software crisis\
1
 Components are independent units of deployment.
1.1.3. Benefits of Components
1. Provides a middle path between the two extremes of traditional software development.
2. Although each bought component is standardized product, the process of component

assembly allows significant customization.
3. Still, individual component can be custom – made to suit specific requirements or to
foster strategic advantages.
4. Puts an end of massive upgrade cycles since evolution replace revolution.
Two traditional S/W

development extremes
Custom_Made S/W Standard S/W
Development from Scratch Bought and Parameterized
1.1.4. Characteristics of Components
 Unit of independent deployment

- It needs to be well separated from the environment and other components
- Never be deployed partially because the third-party can not have access to
construction details of all components involved.
 Unit of third party composition
- Encapsulate implementation.
- Interaction through well-defined interfaces
 No persistent state
- It is required that component can not be distinguished from copies of its
own.
- Possible exception: attributes not contributing to the functionality such as
serial number used for accounting.
- A component can be loaded into and activated in a particular system.
From the above characterization, the following definition can be formed.
2
“A software component is a unit of compostio0n with contractually specified interfaces

and explicit context dependencies only. It can be deployed independently and is subject
to composition by third parties.”
Software
Component Based
Custom_Made Traditional
1.1.5. Important Aspects of Components
 Independent deployment: E.g. Executable, Shared library, .class file etc.

 Interaction standard: Well-defined mechanisms for component interaction.
 Composition standard: Well-defined mechanism for composition of components
 Interfaces: Allows clients for a component to access its services.
 “Properties that make it reusable and replaceable”: “it has high cohesion, low
coupling, a well-defined interface, and is an encapsulated abstraction of a well-
understood thing”.
1.2. Objects
 Identity
 State
 Behaviour
The definition of an object is a piece of software that contains the functions that represent
what the object can do and associated state information for those functions.
1.2.1. Properties of Objects
A. It is a unit of instantiation
B. It may have state; can be a persistent, so it has a unique identity;
C. It encapsulates its state and behaviour.
3
An object is a unit of instantiation. So it cannot be partially instantiated. As objects are

instantiated, there needs to be a construction plan that describes the state space, initial
state, and behaviour of anew object.
1.2.2. Prototype Object
A construction plan needs to be exists before the object can come into existence. If that
plan is explicitly available and then it is called as class. If that plan is implicitly available
in the form of an object that already exists is called as prototype object.
1.2.3. Component and Objects
 Components gets life through objects and hence can contain one or more classes
or immutable prototype objects
 Component could contain procedures and global static variables
 Objects created in a component could leave the component and become visible to
the component’s client.
 A component may contain multiple classes, but classes are restricted to be part of
a single component.
 Components may depend on other component.
 Super class need not reside in the same component as the class itself
 Inheritance relation could cross component boundaries
1.3. Fundamental Properties of Component Technology
In the world many of the key technologies are available for better use. But overall
understanding of knowledge of software is still lacking. From different sources
components are developed. And they are integrated by third parties. In the absence of
critical measurements a component system is only as strong as its weakest component.
For the safety of individual components fault is important.
In traditional software engineering process, module development and testing is followed

by systems integration and testing. This is approach gives room for errors. These errors
are merely a result of composition and which are not apparent at the level of individual
components. But these errors should be detected during systems integration and testing.
When third party doing integration is not possible, as integration testing of modules
comes from different sources that need to be addressed.
The following are the some examples for above said integration issues.
i Java Applets
Until a webpage is requested by a browser, the applet code will not be integrated into the
requesting browser.
4
ii IC Chip
Even though the late version checks are very helpful for user, it does not help to improve
the quality of the components used. A component vendor faces the issues of combination
of system configuration to which test a components.
iii. Safety Measurements
The CLR provisions for establishing type safety, module safety, and security integrity
across all supported languages show that the choice of language is second to the
establishment of underlying principles compatible with many languages.
1.4. Modules
A component has to specify explicitly which services- from the system or other
components – it needs to access. This is done in the form of module that import lists. The
language and system do not allow access to any non – imported module. Hence, if that
list contains only permissible module; then it is safe to load and execute the new
component.
Abstract Data Type
Due to the idea of a module implementing Abstract Data Type (ADT) with the properties
of inheritance and polymorphism. It was claimed that class is a better module. Modules
can be used to package multiple entities like classes or ADTs into one unit.
Modules do not have concept of instantiation whereas classes have. This frequently leads
to the introduction of “static” classes in module – less languages that essentially serve as
simple modules.
In languages such as Java, Oberon, Modula - 3, Pascal and C#, classes are kept separate.
In Java we don’t have separate module concept. Class inheritance can cross module
boundaries.
Modularity
Modularity is a prerequisite for component technology. But components need to be

formed beyond traditional modularity criteria rather than just modules.
Thus modularity is certainly not a new concept. But today, the vast majority of software
solutions are not modular. Component technology leads to modular solutions that
requires adoption principles of independence and controlled explicit dependencies.
5
1.5. Interfaces
An interface is a strongly-typed group of semantically-related functions, also called

“interface member functions”.
Interfaces are used to connect components. It is a set of named operations that can be
invoked by clients. A component may either directly provides an interface or implement
object that, if made available to client, provide interface.
Components can be specified separate from interfaces and their specifications.

Traditional interfaces specification focusing only on the interaction between two
components through one interface.
1.5.1. Attributes of Interfaces
 An interface is not a class

An interface is not a class in the normal definition of “class”. A class can be
instantiated to form an object. An interface cannot be instantiated by itself
because it carries no Implementation.
 An interface is not an object

An interface is just a related group of functions and is the binary standard through
which clients and objects communicate. The object can be implemented in any
language with any internal state representation, so long as it can provide pointer to
interface member functions.
 Interfaces are strongly typed

Every interface has its own interface identifier thereby eliminating any chance of
collision that would occur with human-readable names. Programmers must
consciously assign an identifier to each interface and must consciously support
that interface.
 Interfaces are immutable

Interfaces are never versioned, thus avoiding versioning problems. A new version
of an interface created by adding or removing functions or changing semantics, is
an entirely new interface and is assigned a new unique identifier.
1.5.2. Direct and Indirect interfaces
 Direct interfaces
Provided directly by a component corresponding to interfaces of traditional
libraries. Definition and implementation belong to one component.
 Indirect interfaces
Provided by objects implemented by a component, corresponding to object
interfaces. Definition and implementation might sit in different components.
6
Example of direct and indirect interfaces
Word processing Component Grammar checking component
Word processor Grammar Checker
3 1 4
<<interface>>
Text Services 2 ICheck Grammar
Text Services Mediator Component
“has a”
Implements
1.5.3. Versions
In the component world, component versions can be prolific. Many vendors will provide
various enhanced versions of a successful component. The management of version
numbers becomes a subtle problem in component field.
When moving from direct to indirect interfaces (i.e.) object interfaces, the version checks
are done at bind time. A care must be taken to avoid version conflict when coupling
different systems.
1.6. Callbacks
A procedure passed to a library at one point and called by the library at some later point
is called call backs.
Generally normal calls always originate in higher layer and then stay in their layer or
move to lower layer. A call back usually reverses the direction of the flow control. So a
lower layer calls a procedure in higher layer.
1.6.1. Callbacks are,
 A feature in library to handle asynchronous events.
 Has to be registered with library
7
 A critical region exits for the library in which its state has to remain valid as long
as callback is active
Client Other Party Library
Clients installs callback
Third party calls library
Library invokes callback
Call back queries library
Callback returns
Library returns
Time
Calls
Results
1.6.2. Need of Callback
 Validity of the library states is specified as part of contract.

 Normal pre and post conditions don’t specifies the order to perform callback and
change the library states.
 Enable observation of library state and state changes by queries.
 Usually can be used to notify registered clients of changes of library states.
8
1.6.3. A Directory Service
The directory service supports callbacks to notify clients of changes in the managed
directory. Such a notification service is useful, for instance, to keep a visual
representation of the directory up to date. Consider a system that provides a basic
directory service as part of a simple file system.
The simple directory service interface is grouped into two parts.
 The first part support
1. File lookup
2. Addition or removal of named files
3. Modeling a single flat directory.
 The second part supports registration and unregistration of callbacks. Registered

callbacks are invoked on addition or removal of a name. Each operation of the
interface is specified using simple pre and post-conditions. The interface in post-
condition is guaranteed to remain unchanged.
1.7. Component Architecture
System architecture is the pivotal basis of any large-scale software technology and is of
utmost importance for component based systems.
1.7.1. The benefits of components architecture are
a. Interaction between components and their environment is regulated.

b. The roles of components are defined.
c. Tool interface are standardized.
d. User interface aspects both for end users and for assemblers are regularized.
1.7.2. Roles of an Architecture
 An architecture is needed when asking for guidelines and rules for complex
system design and implementation.
 An architecture needs to create simultaneously the basis for independence and
cooperation. Independence of system aspects is required to enable multiple
sources of solution parts.
 Architecture is about a holistic view of a system, often one that is yet to be
developed. An architecture defines properties that characterize any system built
following this particular architecture.
 An Architecture categorizes central resources to enable independence in the
presence of competition for resources.
9
1.7.3. Key Terms in Component Architecture
i. A set of platform decisions

ii. A set of component frame works
iii. An interoperation design for the component frameworks
1.7.4. A Tiered component Architecture
Layers are fundamental notion of traditional software architectures. In component

systems layers and hierarchical decomposition remain very useful. The components are
layered and may be located with in particular layers of larger architecture.
First-Tiered Architecture
I. The layers formed by an architecture.

II. The layers formed by a meta – architecture
The layers formed by a meta-architecture are called tiers Example: Muti tier Client –
server application.
The architecture itself needs to be layered to show the complexity of larger component
systems.
Second- Tiered Architecture
A component system architecture arranges an open set of component frameworks.
In second-tier architecture each of the component frameworks introduces a first

architecture.
Traditional Layers Tiers

Traditional layers seen from the bottom up Decreasing performance in resource
approach. This approach is an abstract and relevance and increasing performance in
application specific nature structural relevance
All layers have their performance and Different tiers focus on different degrees of
resource implication in well-balanced integration. But all of similar application
layered system. relevance.
Three-Tier Architecture
 Higher tiers provides shared lower layer to accept lower tiers.

 Tiers are depicted beside each other
 Layers sit on top of each other.
10
Component frame work
Component
Component System
(Component framework)
Component Instance
i. Directly (by using Com connectable objects, COM messaging service messages,
CORBA events, Java Beans events)
ii. Indirectly (by using a component framework)
When component framework instance interact the mediator a three-tier instance recurs.
CFFI
CFI
CI
Free Versus mediated interaction in a tiered architecture
11
1.8. Components and Middleware
Middleware is a name for the set of software that sits between various operating systems
and distributed programming platform. Middleware is categorized into message-oriented
versus object oriented. However, most modern middleware uses both MON and OOM.
However, most modern middleware uses both MOM and OOM. Nowadays traditional
operating systems incorporate direct support from middleware.
1.8. Middleware
The term middleware is used to describe a board array of tools and data that help
applications use networked resources and services. Some tools, such as authentication
and directories, are in all categorization.
1.8.1. Middleware Importance
Middleware has emerged as a critical second level of the enterprise IT infrastructure,

between the network and application levels. The need for middleware stems from the
increasing growth in the number of application, in the customizations within those
applications, and in the number of locations in our environments.
1.8.2. Specialized Server
 Application Server
It combines application management, data transaction, load balancing and other
functions (E.g. .Net/COM + Server, J2EE server implementations)
 Integration servers
It combines protocol conversion, data translation, routing, and other functions.
(E.g., Crosswords, Web sphere B2B integrator (IBM), Integrator (Sybase) etc)
 Workflow and Orchestration servers

It combines event routing, decision making, and other functions. All these server
categories introduce their own component frameworks usually built on top of the
leading components platforms such as J2EE (or) .NET.
1.8.3. Evolution of Middleware
The emergence and rapid growth of the internet, beginning in the 1970s, brought forth the
need for distributed applications. For years, however, these applications were hard to
develop due to a paucity of methods, tools, and platforms.
Various technologies have emerged over the past 20+ years to alleviate complexities
associated with developing software for distributed applications and to provide and
advanced software infrastructure to support it.
12
The next generation of advances included OSF’s Distributed computing Environment,

IBM’s MQ Series, CORBA, and COM.
Most recently, middleware technologies have evolved.
 To support distributed real time and embedded applications (E.g., Real time
CORBA)
 To Provide higher – level abstractions, such as component models (E.g., CCM

and J2EE, Web- Services: SOAP, Model driven middleware: Cadena and
CoSMIC)
The success of the middleware technologies outlined above has added the middleware
paradigm to the familiar operating system, programming language, networking, and
database offerings used by previous generations of software developers.
13
Summary
 A component is a reusable piece of software that can be assembled easily to

create applications with better development efficiency.
 Component are independent units of deployment.
 Custom-made software developed with the help of tool and libraries.
 An object typically implements a single class interface, which may be related
to other classes by inheritance.
 A component system is only as strong as its weakest component.
 A component can have multiple interfaces; each interface provide different
service.
 The directory service supports callbacks to notify clients of changes in the
managed directory.
 Middleware has emerged as a critical second level of the enterprise IT
infrastructure, between the network and application levels.
14
Possible Two Mark Questions (10 x 2=20)
1. Define Component.
2. List the requirements of a component.
3. Benefit of Components
4. Uses of Modules.
5. What is Directory Service?
6. Benefits of Component architecture.
7. What is Middleware?
8. What are the middleware technologies that use IDL for defining the interface?
9. What are the three types of servers supported by COM for implementing
Components?
10. Explain Callbacks
Possible Sixteen Mark Questions (16X5=80)
1. What is software component? How does it differ from an object?

2. Describe in detail the feature of software components giving suitable examples.
3. Explain in detail how objects are destroyed in COM.
4. Write the difference between tiers and traditional layers.
5. Explain Component Architecture.
15
UNIT – II JAVA BASED COMPONENT TECHNOLOGIES
Thread-Java Beans-Events and connections-properties-introspection-JAR files-reflection-

object serialization-Enterprise Java Beans-Distributed object models-RMI and RMI-IIOP
2. Introduction
A thread is an independent sequential path of execution with in a program. Threads also

know as execution contexts or light-weight process. Many threads can run concurrently
with in a program.
2.1. Threads
At runtime, threads in a program exist in a common memory space and can therefore,
share both data and code, that is, they are light weight compared to process, they also
share the process running the program. The running instance of a program is called a
process. It is program execution. Now the system resources and the CPU time are
allocated to the various running process. When the time slice is allocated to a process, the
various threads in the process make use of the available to the particular process. The
difference between a thread and a process is that a thread cannot exit on its own, whereas
a process can.
2.1.1. Overview of Threads
Every thread in Java is created and controlled by unique object of the java.lang.Thread
class. Often the thread and its associated Thread object are thought of a being
synonymous. Threads make the runtime environment asynchronous, allowing different
tasks to be performed concurrently. Using this powerful paradigm in java centers around
understanding the following aspects of multithreaded programming.
 Creating threads and providing the code that gets executed by a thread.
 Accessing common data and code through synchronization.
 Transitioning between thread states
The advantages of using threads are as follows:
 Requires less overhead.
16
 Can be created faster.

 Inter process communication are faster.
 Context switching is faster
 Use CPU time optimally.
2.1.2. The Main Thread
When a GUI application is started, a special thread is automatically created to monitor

the user- GUI interaction. This user thread keeps the program running, allowing
interaction between the user and the GUI, even though the main thread might have died
after the main( ) method finished executing.
2.1.3. Thread Creation.
A thread in java is represented by an object of the thread class. Creating threads is

achieved in one of two ways:
 By implementing the java.lang.Runnable interface

 By extending the java.lang.Thread class
2.1.3.1. Implementing the Runnable Interface
Prototype declaration:
Public interface Runnable

{
void run( );
}
The code in the run ( ) method defines an independent path of execution and thereby the
entry and the exists for the thread. The thread ends when the run ( ) method ends, either
by normal completion or by throwing an uncaught exception.
The procedure for creating threads based on the Runnable interface is as follows:
1. A class implements the Runnable interface, providing the run ( ) method that will be
executed by the thread. An object of this class is a Runnable object.
2. An object of Thread class is created by passing a Runnable object as argument to the

Thread constructor. The Thread object now has a Runnable object that implements
the run ( ) method.
3. The start ( ) method is invoked on the Thread object created in the previous step. The
start ( ) method returns immediately after a thread has been spawned.
17
The run ( ) method of the Runnable object is eventually executed by the thread
represented by the Thread object on which the Start ( ) method was invoked.
Sequence of Events is illustrated.
Current Thread
Create
Creates a runnable object
Runner
New thread (runner)

Create a Thread object
Thread
Start ( )
Two threads are now
running concurrently
Run ( )
Starts new thread calls

returns immediately A new thread of
execution begins
Spawning Threads using a Runnable Object
Important constructors and methods from the java.lang.Thread class:
Thread (Runnable threadTarget)

Thread (Runnable threadTarget, String thread name)
The argument thread Target is the object whose run ( ) method will be executed when the
thread is started. The argument threadName can be specified to give an explicit name for
the thread, rather than an automatically generated one. A thread’s name can be retrieved
by using the getName ( ) method.
 Static Thread currentThread ( ): This method returns a reference to the Thread

object of the currently executing thread.
18
 Void run ( ): The Thread class implements the Runnable interface by providing
an implementation of the run ( ) method. This implementation does nothing.
Subclasses of the Thread class should override this method. If the current thread
is created using a separate Runnable object, then the Runnable object’s run ( )
method is called.
 Void Start ( ): This method spawns a new thread, that is, the new thread will
begin execution as child thread of the current thread. The spawning is done
asynchronously as the call to this method returns immediately. It throws an
illegal ThreadStateException if the thread was already started.
Example 1: Implementing the Runnable Interface
Class Counter implements Runnable {

Private int currentValue;
Private Thread worker;
Public Counter (String threadName) {
CurrentValue = 0;
Worker = new Thread (this, threadName); //(1) Create a new thread.
System.out.println (worker);
worker.start ( ); // (2) Start the thread.
}
Public int getValue ( ) {return currentValue;}
Public void run ( ) { // (3) Thread entry point
try {
while (currentValue < 5) {
System.out.println(worker.getName() + “;” + (currentValue++));
Thread.sleep(250); // (4) Current thread sleeps
}
}catch(interruptedException e) {
System.out.println(worker.getName() + “interrupted”);
}
System.out.println(“Exit from thread: “ + worker.getName());
}
}
public class Client{
public static void main(Sting[] args) {
Counter CounterA=new Counter(“Counter A”); //(5) Create a thread
try {
int val;
do {
val = counterA.getValue(); //(6) Access the counter value
System.out.println(“Counter value read by main thread: “ +val);
Thread.sleep(1000); //(7) Current thread sleeps
} while (val<5);
}catch(interruptedException e) {
19
System.out.println(“main thread interrupted.”);

}
System.out.println(Exit from main() method.”);
}
}
Possible output from the program:
Thread[Counter A,5, main]

Counter value read by main thread: 0
Counter A: 0
Counter A: 1
Counter A: 2
Counter A: 3
Counter A: 4
Exit from thread: Counter A
Exit from main method.
The Client class uses the Counter class. It creates an object of class counter at (5) and
retrieves its value in a loop at (6). After each retrieval, it sleeps for 1,000 milliseconds at
(7), allowing other threads to run.
2.1.3.2. Extending the Thread Class
Current Thread
<<Create>>
runner
Creates an object of
a class that extends <<Thread>>
the Thread class Start ( )
……
<<subclass>>
run ( )
Starts new thread Start ( ) ………
calls returns
immediately run ()
Two threads are now A new thread of

running concurrently execution begins
Spawning Threads – Extending the Thread Class
20
1. A class extending the Thread class overrides the run( ) method from the Thread
Class to define the code executed by the thread.
2. This subclass may call a Thread constructor explicitly in its constructors to initialize
the thread, using the super ( ) call.
3. The start ( ) method inherited from the Thread class is invoked on the object of the
Class to make the thread eligible for running.
Example 2: Extending the Thread Class.
Class Counter extends Thread {

Private int currentValue;
Public Counter( String threadName) {
Super(threadName); // (1) initialize thread
currentValue=0;
System.out.println(this);
Start ( ); // (2) Start this thread
}
Public int getValue ( ) { return currentValue;}
Public void run ( ) { // (3) Override from superclass
try {
while (currentValue < 5 ) {
System.out.println(getName( )+”;” + (currentValue++));
Thread. Sleep(250); // (4) Current thread sleeps
}
} catch ( InterruptedException e) {
System.out.println(getName( ) + “ interrupted.”);
}
System.out.println(“Exit from thread:” + getName( ));
}
}
Public class Client {
Public static void main(String[] args) {
System.out.println(“Method main( ) runs in thread” +
Thread.CurrentThread ( ). getName( ) ); // (5) Current thread
Counter counter A = new Counter(“ Counter A”) // (6) Create a thread
Counter counter B = new Counter (“Counter B”); // (7) Create a thread
System.out.println(“Exit from main( ) method”);

}
}
Possible output from the program
Method main( ) runs in thread main
21
Thread [Counter A, 5, main]

Thread [Counter B, 5, main]
Exit from main( ) method.
Counter A: 0
Counter B: 0
Counter A: 1
Counter B: 1
Counter A: 2
Counter B: 2
Counter A: 3
Counter B: 3
Counter A: 4
Counter B: 4
Exit from thread: Counter A
Exit from thread: Counter B
There are other ways of starting a thread. The call to the start ( ) method can be factored
out of the constructor, and the method can be called later, using a reference that denotes
the thread object.
2.1.4. Synchronization
Threads share the same memory space, that is, they can share resources, however, there
are critical situations where it is desirable that only one thread at a time has access to
shared resource.
2.1.4.1. Locks
In java, all objects have a lock – including arrays. This means that the lock from any java
object can be used t o implement mutual exclusion. By associating a shared resource with
a java object and its lock, the object can act as a guard, ensuring synchronized access to
the resource.
Lock mechanism enforces the rules of synchronization
 A thread must acquire the object lock associated with a shared resource,
before it can enter the shared resource. The runtime system ensures that no
other thread can enter a shared resource if another thread already holds the
object lock associated with the shared resource. If a thread cannot
immediately acquire the object lock, it is blocked, that is, it must wait for the
lock to become available.
 When a thread exits a shared resource, the runtime system ensures that the
object lock is also relinquished. If another thread is waiting for this object
lock, it can proceed to acquire the lock in order to gain access to the shared
resource.
22
The keyword synchronized and the lock forms the basis for implementing synchronized
execution of code.
 Synchronized methods
 Synchronized blocks
2.1.4.2. Synchronized Methods
This is simply achieved by calling the method. If the lock is already held by another
thread, the calling thread waits. No particular action on the part of the program is
necessary. Synchronized methods are useful in situations where methods can manipulate
the state of an object in ways that can corrupt the state if executed concurrently. A stack
implementation usually defines the two operations push and pop as synchronized, so that
pushing and popping of elements are mutually exclusive operations.
2.1.4.3. Synchronized Blocks
Synchronized (<object reference expression>) {<code block>}

The <object reference expression> must evaluate to a non-null reference value,
otherwise, a NullpointerException is thrown. The code block is usually related to the
object on which the synchronized is being done. This is the case with synchronized
methods, where the execution of the method is synchronized on the lock of the current
object.
Public Object pop ( ) {
Synchronized (this) { // Synchronized block on current object

// …..
}
}
2.1.5. Thread Transitions
2.1.5.1. Thread States
Understanding the life cycle of a thread is valuable when programming with threads.
Threads can exist in different states.
I. Ready-to-run state: A thread starts life in the Ready-to-run state.

II. Running state: if a thread is in the running state, it means that the thread is
currently executing .
III. Dead state: Once in this state, the thread cannot ever run again.
IV. Non-runnable states: A running thread can transit to one of the non-
runnable states, depending on the circumstances. A thread remains in a non-
runnable state until a special transition occurs.
23
The non-runnable states can be characterized as follows:

a) Sleeping: The thread sleeps for a specified amount of time.
b) Blocked for I/O: The thread waits for a blocking operation to complete.
c) Blocked for join completion: The thread awaits completion of another thread.
d) Waiting for notification: The thread awaits notification from another thread.
e) Blocked for lock acquisition: The thread waits to acquire the lock of an object.
Wait Wait for

for lock notify
terminated
new
runnable running
Suspended
Methods of Thread class
 final Boolean isAlive()

 final int getPriorty()
 final void setPriority(int newPriority)
 Static void yield()
 Static void sleep(long millisec) throws interruptedException
 Final void join() throws interruptedException
 Final void join(long millisec) throws interruptedException
 Void interrupt ()
2.1.5.2. Thread Priorities
A thread inherits the priority of its parent thread. Priority of a thread can be set using the
setpriority() method and read using the getpriority() method, both of which are defined in
the Thread class.
Parameters to setPriority() methods are:
 MIN_PRIORITY - 1 (lowest priority)
24
 MAX_PRIORITY - 10 (highest priority)
 NORM_PRIORITY - 5 (default priority)
2.1.5.3. Thread Scheduler
Schedulers in JVM implementation usually employ one of the two following strategies:
Preemptive scheduling
If the thread with a higher priority than the current running thread moves to the Ready-to-
run state, then the current running thread can be preempted to let the higher priority
thread execute.
Time-Sliced or Round-Robin scheduling
A running thread is allowed to execute for a fixed length of time, after which it moves to
the Ready-to-run state to await its turn to run again.
It should be pointed out that thread schedulers are implementation and platform
dependent; therefore, how threads will be scheduled is unpredictable, at least from
platform to platform.
2.1.5.4. Thread Termination
A thread can transit to the dead state from the running or the Ready-to-run states. The
thread dies when it completes its run() method, either by returning normally or by
throwing exception.
Once in this state, the thread cannot be resurrected. There is no way to thread can be
enabled for running again, not even by calling the start() method once more on the thread
object.
Example 3: Thread Termination
Class Worker implements Runnable {

Private Thread the Thread;
Public void kickStart() {
if (theThread == null) {
theThread = new Thread(this);
theThread.start();
}
}
Public void terminate() {
theThead = null;
25
}
Public void run() {
While (theThread == Thread.currentThread()) {
System.out.println(“ inside loops.”);
}
}
}
Public class controller {
Public static void main(String[] args) {
Worker worker = new Worker();
worker.kickStart();
Thread.yield();
Worker.terminate();
}
}
Possible output from program:

Inside loops.
Inside loops.
Inside loops.
Inside loops
Inside loops.
2.1.5.5. Deadlocks
A deadlock is a situation where a thread is waiting for an object lock that another thread
holds, and this second thread is waiting for an object lock that the first thread holds.
Since each thread is waiting for the other thread to relinquish a lock, they both remain
waiting forever in the Blocked-for-lock-acquisition state. The threads are said to be
deadlock.
thread t1
lock acquired
O1
thread t2
thread t1 now waiting
to acquire lock on O2 lock acquired
O2
thread t2 now waiting cannot acquire lock
to acquire lock on O1
cannot acquire lock
Dead lock
26
2.2. Java Beans
Java beans is a set of java objects that objects that provides the infrastructure for the
components to be written in java language. Java beans include objects for customizing,
introspecting and event handling. It provides the component frame work from which
reusable components can be built.
Using the bean development kit, the users can implement their own component as well as
describe the interface specifications to their own components. It also enables the users to
define the event mechanisms, properties and public methods.
2.2.1. Overviews
Java beans mission statement is “ Write once, Run anywhere, Reuse everywhere”.
The capability of java beans components to be executed in any environment.
 Reused in many different applications, components, documents, websites and

application builder tools.
 Execution across distributed network environments.
 Cross – platform.
2.2.2. Basic structure of a bean
A bean, like an object in object oriented technology, is comprised of primary things data
and methods that act on the data.
Data Methods
A bean is capable of accessing different types of methods
Private
methods
Data
Protected
methods
Interface A
Public
methods Interface B
Basic structure of Bean
27
Private methods
Accessible only within the internals of beans.
Protected methods
Accessible internally and in derived beans.
Public methods
Accessible internally, from derived beans and from other applications and components.
Public methods have unique importance because they form the primary means by which
the beans can communicate outside through events.
2.2.3. Java Beans Concepts
The JavaBeans API makes it possible to write components software in the Java
programming language. Components are self-contained, reusable software units that can
be visually composed into composite component, applets, application, and servlets using
visual application builder tools. Java Bean components are known as beans.
A “Java Bean-enabled” builder tool can then examines the bean’s patterns, discern its
feature, and expose those features for visual manipulation. A builder tool maintains beans
in a palette or tool box.
Although Beans are designed to be understood by builder tool, all key API’s including
support for events, properties and persistence, have been designed to be easily read and
understood by human programmers as well.
2.2.4. Bean Development Kit
 It is a tool that allows the user to configure and interconnect a set of beans.
 It provides an easy way to test the beans that the user writes and to explore the
capabilities of beans written by others. BDK also includes a set of demonstration
components and their source code.
BDK - Presents a toolbox window that lists the demonstration beans.
Bean box - Window that provides an area in which the user can connect the components.
Properties - Window that provides an interface through which the user configure a bean.
28
2.2.5. In - built components
1. Orange button: default orange color. Like explicit button changing its background
color and serializing it to a file.
2. Our button: is a subclass of java.awt.canvas. act as a simple GUI button. Fire a

standard AWT action perform event.
3. Explicit button: is a subclass of our button it simply adds a Bean info class to
specify the beans behaviour and icons.
4. Event monitor: monitor all the events fired by a source bean. It does this by
analyzing the source bean and crating event adaptors for all the different kinds of
events fired by the bean.
5. Jelly bean: draws an oval and supports a bound property “color” and a constrained
properly “pricelncents”. Provides a mono and color icon in 16 x 16 and 32 x 32 the
16 x 16 is displayed in tool box
6. Juggler: it has very simple JugglerBeanInfo class that defines a 16x16 color icon
for the juggler that gets displayed in the toolbox. Two explicit button to the start
and stop juggling animation method by push events.
7. Tick tock: “invisible bean when the user selects it form the tool box and drops it’s
onto the composition window it will come up as a small rectangle showing the bean
name. The user can hide this using the “hide invisible beans”, item under the “view
menu”.
8. Veto: it is designed to process vetoableChange events. By default it refects all

vetoable change requests, though the user can change its vetoall property to “true”
and then it will allow changes.
9. Change reporter: it is a small text window that can be used to display changes to
bound properties.
29
10. JDBC Select: the JDBC capital bean contacts a target data box at a specified
JDBC URL and runs a SQL select statement to display specified columns for a
target table.
11. Transitional bean: it follows the JDK 1.0.2 compatibility rules, so that it will run
on JDK 1.0.2 as well as JDK 1.1 or higher.
2.3. Events and connections
Events in java and in java beans –are objects created by an event source and propagated
to all currently registered event listeners. Thus, event-based communication generally has
multicast semantics. However, it is possible to flag an event source as requiring unicast
semantics-such a source accepts at most one listener at any one time.
2.3.1. Event object
Listeners need to implement an interface that extends the empty “marker” interface
java.beans.Evenlistener and it has a receiving method for each event the listener listens.
Marker interfaces are also known as tagging interfaces
Example:
Interface UserSleepsListener extends java.util.EventListener {
Void userSleeps (UserSleepsEvent e);

}
2.3.2. Event Adapter
If it is registered with multiple event sources that can all fire the same event, the listener
has to determine where an event came from before handling it. This can be simplified by
interposing an event adapter. An event adapter implements a listener interface and holds
references to listeners.
Thus event adapter is combination of
i. An event listener ii. An event source
A separate adapter can be registered with each of the event sources.
Each adapter then calls a different method of the listener. Thus, event adapters can be
used to demultiplex events. In principle, event adapters can perform arbitrary event-
filtering functions.
30
An event source needs to provide pairs of listener register and unregister methods
Public void addUserSleepsListener(UserSleepsListener i);
Public void removeUserSleepsListener(UserSleepsListener i);
If a source requires unicast semantics, it can throw a TooManyListenersException:
Public void addUserSleepsListener(UserSleepsListener i);

throws java.util.TooManyListenerException;
2.3.3. Event propagation
Event propagation in a multicast environment introduces a number of subtle problems.

While an event is propagated the set of listeners can change. JavaBeans does not specify
how this is addressed, but a typical way is to copy the collection of registered listeners
before starting a multicast.
2.3.4. Event Ordering
Event ordering issues are aggravated in multithreaded environment such as Java. This is
clearly subtle. For one problems only arise if the event listener uses additional threads
besides the one carrying the event notification, because the notifying thread continues to
hold all the locks held by the event source, which would prevent dead locks.
Also, it is not even clear if this recipe can be followed generally with out breaking
encapsulation. It may not be at all easy to determine whether and which locks the event
source holds.
2.4. Properties
 Simple properties
 Bound properties
 Constrained properties
 Indexed properties
2.4.1. Simple Properties
Properties are aspects of a Bean’s appearance and behavior that are changeable at design
time. Properties are private values accessed through getter and setter methods. Property
getter and setter method names follow specific rules, called design patterns.
By using these design pattern-based method names, JavaBeans- enabled builder tools
can.
 Discover a bean’s properties

 Determine the properties’ read/ write attributes
31
 Determine the properties’ types.

 Locate an appropriate property editor for each property type.
 Display the properties
 Alter those properties
For examples, a builder tool, on introspecting your bean, discovers two methods:
public Color getColor ( ) { ….}

public void setColor (Color c) {…..}
from this the builder tool infers that a property named color exists, That it is readable and
writeable, and that it’s type is color. Further, the builder tool can attempt to locate a
property editor for that type, and display the property so it can be edited.
2.4.2. Bound properties
Sometimes when a Bean property changes, another object may want to be notified of the
change, and react to the change. Whenever a bound property changes, notification of the
change is sent to interested listeners.
A bean containing a bound property must maintain a list of property change listeners, and
alert those listeners when the bound property changes.
By implementing the propertyChangeListener interface the listener can be added to the

list maintained by the bound property bean, and because it implements the
PropertyChangeListener.propertychangemethods, the listeners can respond to property
change notification.
Public void firePropertyChange(String propertyName, Object oldValue, Object

newValue)
The firePropertyChange method bundles its parameters into a PropertyChangeEvent

object, and calls propertyChange(PropertyChangeEvent pce) on each registered listener.
The old and new values are treated as Object values. If your property values are primitive
types such as int, you must use the object wrapper version such as java.lang.integer. Also,
property change events are fired after the property has changed.
2.4.2.1. Implementing Bound property Listener
To listen for property change events, your listener Bean must implement the
PropertyChangeListener interface. This interface contains one method:
Public abstract void propertyChange(PropertyChangeevent evt)
This is the notification method that the source bean calls on all property changes listeners
in its property change listener list.
32
1. implement the PropertyChangelistener interface.

2. public class MyClass
3. implements java.benas.PropertyChangeListener.
4. java.io.Serializable
5. implement the porpertyChange method in the listener. This method needs to
contain the code that handles what you need to do when the listener receives
property change event.
2.4.3. Constrained properties
A bean property is constrained when any change to that property can be vetoed. Usually
an outside object exercises the right to veto, but the bean itself can also veto a property
change. The javaBean API provides an event mechanism, very similar to the bound
property mechanism, that allows objects to veto a bean’s property changes.
There are three parts to constrained property implementations:
 A source bean containing one or more constrained properties

 Listener objects that implement the VetoableChangeListner interface.
 A PropertyChangeEvent object containing the property name, and its old and new
values. This is the same class used for bound properties.
2.4.3.1. Implementing Constrained Property Listener
To listen for property change events, your listener bean must implement the
VetoableChangeListener interface. This interface contains one method:
Void vetoableChange(PropertyChangeEvent evt)

throws PropertyVetoException;
Listener Class
I. Implement the VetoableChangeListener interface.

II. Implement the vetoableChange method. This is the method that will be called by
the source bean on each object in the listener list. This is also the method that
exercises veto power.
2.4.4. Indexed properties
Indexed properties represent collections of values accessed, like an array, by index. The
indexed property design patterns are.
// Methods to access the entire indexed property array

Public<propertyType>[]get<ProeprtyName>();
Public void set<ProeprtyName>(<propertyType>[]Value);
33
// Methods to access individual values

Public <properytType> get<propertyName>(int index);
Public void set<propertyName>(int index, <PropertyType> value);
The adapter class implements the VetoableChangeListener interface and the

vetoableChange method. This adapter is added to the constrained Bean’s listener list,
intercepts the vetoableChangecall, and calls the target Bean method that exercises veto
power.
2.4.4.1. The BDK Property Editors.
The BDK provides editors for the primitive data types like int, boolean, and float and
Color and font class types.
 All the “number” properties are represented as string objects. The IntEditor
overrides PropertyEditorSupport. setAsText.
 The Boolean property editor is a menu of discrete choices that overrides the
PropertyEditorSupport. getTags method to return a String[] containing “ True”
and “False”.
 public String[] getTags () {
 String result[] = { “True”, “False”};
 Return result;
 }
 The color and font property editors implement custom property editors. Because
these objects require a more sophisticated interface to be easily edited a separate
Component pops up to do the property editing. Overriding supportsCustomEditor
to return true signals the property sheet that this property’s editor is a custom
component. The isPaintable and paintValue methods are also overridden to
provide color and font painting in the editor property sheet sample areas.
2.5. Introspection
Java events and properties are major supported by a combination of new standard
interfaces and classes.
I. EventListener
II. EventObject
III. EventSetDescriptor
IV. PropertyDescriptor
The use of interfaces such as EventListener allows an assembly tool using the reflection
services to discover support of certain features by a given bean. In addition, JavaBeans
introduces the new notion of method patterns.
34
2.5.1. Method Patterns
A method pattern is combination of rules for the formation of a method’s signature, its
return type, and even its name. method pattern allow for the lightweight classification of
individual methods of an interface or class
For example, here is the method pattern used to indicate a pair of getter and setter
methods for specific property.
Public <Propertytype> get<PropertyName> ();

Public void set <PropertyName> (<PropertyType> a);
Example
For a property “background” of type java.awt.Color, this pattern yields the following two
methods.
Public java.awt.Color getBackground ( );

Public void setBackground ( java.awt.Color color);
The use of conventional names in method patterns can be avoided – a bean can
implement interface java.bears.Beaninfo.
If this interface is implemented, an assembly tool will use it to query a bean instance
explicitly for the names of
I. Property getters
II. Property setters
III. Event source registration methods.
2.6. JAR Files
Jar is:
 The only archive format that is cross- platform

 The only format that handles audio and image files as well as class files
 Backward-Compatible with existing applet code.
 An open standard, fully extendable, and written in java.
 The preferred way to bundle the pieces of a java applet.
Jar consists of zip archive, containing a manifest file and potentially signature files.
35
Java archive files provide a standard mechanism to compress and package a set of files
for distribution to users. JAR is a platform independent file format that aggregates many
files into one.
 To create a single JAR file that contains several beans and any associated files.
 Many java applets and their requisite components. Can be bundled in a JAR file
and subsequently downloaded to a browser in a single HTTP transaction, greatly
improving the download speed.
for instance, the developer creates a set of beans to receive and transmit streaming audio
and video on the internet.
2.6.1. JAR file contains
I. The beans
II. Any supporting class files
III. Text and html files that provides help to the user
IV. Static images
V. Audio and video clips
VI. Configuration data
VII. Any other file required for the software to operate.
JAR format supports compression, which reduces file size, further improving the
download time.
First element in JAR file is always a manifest file. This is a plain text file that contains
information about all the other files in the archive. The manifest file indicates which of
the class files are java beans.
The APPLET tag
Changing the APPLET tag in your HTML page to accommodate a JAR file is simple.
The jar file on the server is identified by the ARCHIVE parameter, where the directory
location of the jar file should be relative to the location of the html page:
<applet code=Animator.class archive=”jars/animator.jar” width=460 height=160>

<param name=foo value =”bar”>
</applet>
Note that the familiar CODE=myAppplet.class parameter must still be present. The
CODE parameter, as always, identifies the name of the applet where execution begins.
However, the class file for the applet and all of its helper classes are loaded from the jar
file.
2.6.2. JAR Utility
JAR utility provided with the JDK is used create and manage JAR files.
36
Syntax
Jar <options> files.
2.6.3. JAR files specification
A JAR file is essentially a zip file that contains an optional META-INF directory. A JAR
file can be created by the command-line jar tool, or by using the java.util.jar API in the
java platform. There is no restriction on the name of a JAR file, it can be any legal file
name on a particular platform.
2.7. Reflection
Reflection enables java code to discover information about the fields, methods and
constructors of loaded classes, and to use reflected fields, methods and constructors to
operate on their underlying counterparts on objects, within security restrictions.
2.7.1. Applications
The core reflection API accommodates two categories of applications.
I. One category is comprised of applications that need to discover and use all of the
public members of the target object on its run-time class. These applications
require run-time access to all the public fields, methods, and constructors of an
object.
II. The second category consists of sophisticated applications that need to discover
and use the member declared by a given class. These application need run-time
access to the implementation of a class at the level provided by a class file.
2.7.2. Reflection models
The three classes field, method, and constructor are final. Only the java virtual machine
may instances of these classes; these objects are used to manipulate the underlying
objects; that is, to:
 Get reflective information about the underlying member or constructor.

 Get and set field values
 Invoke methods on objects or classes
 Create new instances of classes
The final uninstantiable class Array provides static methods that permit creating new
arrays, and getting and setting the elements of array.
37
2.7.3. Security Model
The java security manager controls access to the core reflection API on a class-by-class
basis.
 The methods of class that give reflective access to a member or a set of member
of a class are the only source for instance of field, method, and constructor.
 Once the system security manager grants initial reflective access to a member any
code may query the reflected member for its identifying information.
2.7.4. Data Conversions
There are two types of automatic data conversions. Wrapping conversions convert from
values of primitive types to objects of class types. Unwrapping conversions convert
objects of class types to values of primitive types. The rules for these conversions are
defined in “wrapping and unwrapping conversions.”
Additionally, field access and method invocation permit widening conversions on

primitive and reference types. These conversions are detailed in “Widening conversions.”
2.8. Object Serialization
Serialization is used for lightweight persistence and for communication via sockets or
Remote method invocation. The default encoding of objects protects private and transient
data, and supports the evolution of the classes. A class may implement its own external
encoding and is then solely responsible for the external format.
2.8.1. Defining Serializable Fields for class
The Serializable fields of a class can be defined two different ways. Default serializable
fields of a class are defined to be the non-transient and non-static fields.
This default computation can be overridden by declaring a special field in the serializable
class, serialPersistentFields. This field must be initialized with an array of
ObjectStreamField objects that list the names and types of the serializable fields. The
modifiers for the field are required to be private, static and final.
For example:
Class List implements Serializable {

List next;
Private Static final objectStreamField[] serialPersistentFields= {new
ObjectStreamField(“next”,List.class)};
}
38
By using SerialPersistentFields to define the serialzable fields for class, thread no longer
is a limitation that a serializable field must be a field with in the current definition of the
serializable class
2.8.2. The Serializable interface
Object serialization produces a stream with information about the JAVA classes for the
objects which are being saved. For serializable objects, sufficient information is kept to
restore those objects even if a different version of the implementation of the class is
present.
The serializable interface is defined to identify classes which implement the serializable
protocol:
Package java.io;
Public interface serializable {};
A Serializable class must do the following:
 Implement the java.io.Serializable interface

 Identify the fields that should be serializable
 Have access to the no-arg constructor of its first nonserializable superclass
This class can optionally define the following methods.
 A writeObject method to control what information is saved or to append

additional information to the stream.
 A readObject method either to read the information written by the corresponding
writeobject method or to update the state of the object after it has been restored
 A writeReplace method to allow a class to nominate a replacement object to be
written to the stream.
 A readResolve method to allow a class to designate a replacement object for the
object just read from the stream ObjectOutputStream and ObjectInputStream
allow the serializable classes on which they operate to evolve.
2.8.3. The Externalizable interface
For externalizable objects, only the identify of the class of the object is saved by the
container; the class must save and restore the comments. The Externalizable interface is
defined as follows.
Package java.io;
Public interface Externalizable extends Serializable
39
{
Public void writeExternal(ObjectOutput out) throws IOException.
Public void readExternal (ObjectInput in) throws IOException,
java.lang.ClassNotFoundExcetpion;
}
The class of an Externalizable object must do the following:
 Implement the jav.io.Externalizable interface

 Implement a writeExternal method to save the state of the object
 Implement a readExternal method to read the data written by the writeExternal
method from the stream and restore the state of the object.
 Have the writeExternal and readExternal methods be solely responsible for the
format, if an externally defined format is written.
2.9. Enterprise Java Beans (EJB)
Sun Microsystems introduced the J2EE application server and the Enterprise
JavaBean(EJB) specifications as a venture into multitier server-side component
architecture market.
It is important to note that thought EJB and JavaBeans are both component models they
are not same. EJBs are interprocess components and JavaBeans are intraprocess
components. EJB is a specification for creating server-side components that enables and
simplifies the task of creating distributed objects.
The key features of EJB are as follows
 EJB components are server-side components written in Java.

 EJB components implements the business logic only. Need not wide code for
system-level services, such as managing transactions and security.
 EJB components provide services, such as transaction and security management
and can be customized during deployment.
 EJB can maintain state information across various method calls.
2.9.1. EJB Component Architecture
EJB is a layered architecture consisting of:
 EJB server, which contains the EJB container

 EJB container, which contains enterprise beans
 Enterprise bean, which contains methods that implement the business logic.
40
Client EJB Server

Home interface
EJB Home stub EJB Home
Home
interface
EJB Container
Remote interface EJB Object
Remote
interface
Bean Class
EJB Object Stub
2.9.2.EJB Server
The EJB server provides some low-level services, such as network connectivity to the
container. It also provide the following services:
Instance passivation
If a container needs a resource, it can decide to temporarily swap out a bean from
memory storage. This is called instance passivation.
Instance pooling
The EJB server enables multiple clients to share instances of enterprise beans. If an
instance of the requested bean exists in the memory, the bean is reassigned to another
client. This is called instance pooling.
Database Connection pooling
When an enterprise bean wants to access a database, it does not create a new database
connection if the database connection already exists in the pool. Instead, it obtains a
database connection from the pool. When the bean releases the database connection, it
can be reused by another enterprise bean.
41
Precached instances
The cache contains information about the state of the enterprise bean. When an enterprise
bean is created, it might require loading some state information. The enterprise bean can
use precached instance to load the information. This increases the speed of creating an
EJB.
2.9.3. EJB Container
The EJB container acts as an interface between an enterprise bean and the clients. Clients
communicate with the enterprise bean through he remote and home interfaces provided
by the container.
The client communicating to the enterprise bean through the container enables the
container to service the client’s request with great flexibility.
Container Services
 Security
 Transaction management
 Persistence
2.9.4. EJB Class
The EJB class implements all business methods declared in the remote interface. To write
an EJB class:
1. Import interfaces:
 Java.rmi.RemoteException
 Javax.ejb.SessionBean
 Javax.ejb.SessionContext
2. Next, create the EJB class by implementing the SessionBean interface.

3. Then, implement the business method defined in the remote interface.
Example
import java.rmi.RemoteException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContect;
public class myEJBClass implements SessionBean

{
public myEJBClass() {}
42
public int mymethod(int i)

{
Return i+5;
}
Public void ejbCreate(){}
Public void ejbRemote(){}
Public void ejbActivate(){}
Public void ejbPassivate(){}
Public void setSessionContext(SessionContext sc){}
}
2.9.4. Enterprise Bean
Enterprise JavaBeans are write-once, run-anywhere, middle-tier components that consist

of methods that implement the business rule. The enterprise bean encapsulates the
business logic.
Entity Bean
Entity beans are enterprise beans that persist across multiple sessions and multiple
clients. There are two types of entity bean:
 Bean-managed persistence
 Container-managed persistence
In a bean-managed persistence, the programmer has to write the code for database calls.
On the other hand, in container-managed persistence, the container takes care of database
calls.
Session Bean
Session beans perform business tasks without having a persistent storage mechanism,
such as a database and can use the shared data. There are two types of session beans.
 Stateful session bean

 Stateless session bean
A stateful session bean can store information in an instance variable to be used across
various method calls. Some of the applications require information to be stored across
various method calls.
2.9.5. Implementing EJB
The enterprise bean can be deployed using products such as WebSphere, WebLogic,
J2EE server, and Oracle 9i provided by vendors like IBM, BEA, Sun Microsystems, and
Oracle.
43
2.9.6. J2EE SDK Architecture
Java 2 SDK, enterprise edition (J2EE SDk) is platform for developing and deployment
enterprise and multi-tier applications in a distributed environment. To create a J2EE
application, you must understand the J2EE architecture.
J2EE Server
EJB Container
Enterprise bean
Enterprise bean
Web Container
JSP file
Servelet
J2EE SDK architecture
J2EE Server
The J2EE server contains the EJB container and the web container.
EJB Container
The EJB container contains the enterprise bean. The container provides remote and home
interfaces through which clients communicate with the enterprise bean. It also provides,
such as transaction management, security, life cycle management and persistence.
Web Container
The web container is a runtime environment for servlets and Java Server pages (JSP)
files.
2.9.7. J2EE Application components
A J2EE application is assembled by
I. J2EE application clients
44
II. Enterprise beans

III. Web components
Each component is packaged into a file with a specific file format.
 A J2EE application client is a java application that runs in an environment, which

enables it to access the J2EE services. A J2EE application client’s packaged into a
.jar (Java archive) file.
 A web component may contain servlet, JSP, HTML, and GIF files. These web
component files are packaged into a .war (Web archive) file.
 An enterprise bean consists of three files: the EJB class, home and remote
interfaces. The enterprise bean files are bound into an EJB.jar file.
The .jar, .war, and EJB.jar files are assembled into a J2EE application, which is an .ear
file. The .ear file is then deployed on the J2EE server.
2.10. Distributed Object Models (DOM)
Under the term distributed objects, we usually understand objects which reside in
separate address spaces and methods of which can be subject of remote method calls (a
remote call is issued in an address space separate to the address space where the target
object resides). By convention, the code issuing the call is referred to as the client; the
target object is referred to as the server object (or simply remote object); the set of
methods which implements one of the server object’s interfaces is sometimes designated
as a service that this object provides. Similarly, the process in which the server object is
located is referred to as a server.
An important goal of the client and server abstractions is to make it transparent how "far"
the client and server spaces actually are - whether they reside on the same machine, are
on different nodes of a local network, or even reside on different Internet URLs (thus
being "intergalactic"); as a special case, client and server may share the same address
space.
2.10.1. Remote reference
One of the key issues of remote method calls is referencing of remote objects.
Classically, in a "local" case, in a method call rro.m(p1,p2, ..., pn) , rro contains a
reference to the target object, m identifies the method called, and some of the parameters
can contain references to other objects as well; let us suppose only one of the parameters,
say pj, contains a reference. However, in a distributed environment we face the following
issue: rro should identify a remote object over the network, and so should pj. It is obvious
that classical addresses will not do as the references, at least for the following reasons: in
addition to the data record of the target object, a reference has also to identify the node
and the server in which the target object resides. Moreover, the target object may
implement more (non polymorphic) interfaces; thus, rro should also identify the
particular interface which the target object implements, and to which m belongs. By
convention, a reference that contains all this information is termed a remote reference.
45
Hence, a remote reference identifies a service. In addition, representation of a remote

reference has to span the differences in the hardware architectures of the nodes where the
objects involved in a particular remote method call reside.
2.10.2. System Architecture
The system consists of three basic layer: the Stub /skeleton layer, remote reference layer,
and transport. A specific interface and protocol defines the boundary at each layer.
Thus, each layer is independent of the next and can be replaced by an alternate
implementation without affecting the other layers in the system.
Architecture Overview
The three layer of the RMI system consist of the following
 Stub/Skeleton – Client-side stubs and server-side skeletons

 Remote reference layer – Invocation behavior and reference semantics
 Transport – Connection set up and management and remote object tracking.
The application layer sits on top of the RMI system.
Client Server
Application
Stubs Skeletons
Remote Reference layer

RMI System
Transport
This figure is an illustration of the layers of RMI system. A remote method invocation
from a client to a remote server object travels down through the layer of the RMI system
to the Client- side transport, then up through the Server- side transport to the server.
2.11. RMI and RMI –IIOP
Remote method invocation (RMI) is java’s traditional form of remote communication.

Basically, it is an object- oriented version of remote procedure call (RPC).
46
RMI –IIOP is an extension of traditional Java RMI that uses the IIOP protocol. This
protocol allows RMI objects to communicate with CORBA objects. Java programs can
therefore interoperate transparently with objects that are written in other programming
languages, provided that those objects are CORBA-compliant. Objects can still be
exported to traditional RMI(JRMP) however, and the two protocols can communicate.
Development procedure
RMI Java
Interface File
(MYObject.java)
RMI Java RMI Java

Client Server
RMIC compiler
(rmic.liop)
Tie_Myobject_ Tie_Myobject_
Tie.Class Tie.Class
IIOP
ORB ORB
IIOP
A difference is the – iiop parameter of rmic compiler. This option used to make rmic
generate the stubs and tie that support the iiop protocol. Without this-iiop option, rmic
generates a stub and a skeleton for the JRMP protocol
Although the development procedure for RMI-IIOP is close to that for RMI the runtime
environment is different in that communication is made through CORBA.
2.11.1. RMI –IIOP and Java IDL
As explained previously, an RMI-iiop client cannot necessarily access an existing

CORBA object. If you do want to use java to access CORBA objects that have already
been written, java IDL is an alternative to RMI-IIOP.
Using java IDL, you can access any CORBA object from Java. Sun’s recommendation
for usage of RMI-IIOP and java IDL. If want to use java to access existing CORBA
resources. Java IDL is recommended.
47
Java IDL
Java’s CORBA’S
World World
RMI-IIOP
CORBA’S
RMI’S
World
World
RMI-IIOP supports both the JRMP and IIOP protocols, there has been much speculation
that RMI (JRMP) will be integrated into RMI –IIOP. However, it would continue
supporting all three protocols, i.e., Java IDL, RMI (JRMP), and RMI-IIOP.
48
Summary
 A thread which is created based on an object the implements the runnable

interface, will execute the code defined in the public method run ().
 Java provides high-level concepts for synchronization in order to control
access to shared resources.
 A thread can transit to the dead state from the running or the ready to run
states.
 Java beans is a set of java objects that provides the infrastructure for the
components to be written in java language.
 Bean box – window that provides an area in which the user can connect the
components
 Event adapter implements a listener interface and holds reference to
listeners.
 Jar is an open standard, fully extendable, and written in java.
 Java archive files provide a standard mechanism to compress and package a
set of files for distribution to user.
 RMI-IIOP is an extension of traditional Java RMI that uses the IIOP
protocol.
49
1. What is Stateless object?

2. Difference between semantics of Remote method invocation and local method
Invocation.
3. Is Java Beans a component model or an object model? Justify your answer.
4. What is EJB? Difference between stateful and stateless EJB.
5. What is DOM?
6. What is JAR?
7. What is object serialization?
8. What are the key features of EJB?
9. What is RMI-IIOP?
10. What is RMI over IIOP?
1. What is EJB? Explain about EJB architecture

2. Difference between java beans and enterprise java beans.
3. Describe briefly about distributed objects.
4. Explain the overview of CORBA architecture with its implementation issues.
5. Explain in detail the features of java beans and list the steps in development of
Java beans application.
50
UNIT - III CORBA COMPONENT TECHNOLOGIES
Java and CORBA – interface Definition language-object Request Broker – System object
model – portable object adapter – CORBA Component model – Containers – application
server – model driven architecture.
3. Introduction:
Today Java and CORBA usually coexists in almost all application server products. When
implementing for the application server tier, it is reasonable to assume the presence of
CORBA mechanisms that is for interoperation.
3.1. Java and CORBA
An important reason to incorporate CORBA into Java projects is to enable the use of
IIOP for communication with non-java subsystems.
 RMI is normally implemented using java Remote Method protocol which limits
the use of RMI to Java to Java communication.
 The RMI over IIOP was introduced in 1999. it is the part of the java Development
kit (JDK) since J2SE 1.3 introduced. It supports a restricted RMI-Over-CORBA
IIOP protocol.
 RMI-Over-IIOP does not support the RMI distributed garbage collection method.
So it falls back on CORBA’s life cycle management approach to deal with the
lifetime of remote objects explicitly.
 In 2004 J2SE 1.4 was introduced. It supports POA(Portable object adapter),
portable interceptors, INS(Interoperable Naming Service), GIOP (General
interoperability Protocol).
 One of the features of J2SE 1.4 is, it enables clients to remotely manage, locate
and invoke persistent objects in CORBA-supporting servers.
 Now J2SE 1.5 is released and it supports many CORBA services with flexibility.
3.2. Interface Definition Language (IDL)
The OMG Interface Definition Language (IDL) is the language used to describe the
interfaces that client objects call and object implementations provide. An interface
definition Written in OMG IDL completely defines the interface and fully specifies each
operation’s parameters.
51
An OMG IDL interface provides the information needed to develop clients that use the
interface’s operations.
Clients are not written in OMG IDL, which is purely a descriptive language, but in
languages for which mappings from OMG IDL concepts have been defined
The mapping of an OMG IDL concept to a Client language construct will depend on the
facilities available in the client language. A source file containing interface
specifications written in OMG IDL must have an “.idl” extension. The file orb.idl
contains OMG IDL type definitions and is available on every ORB implementation.
3.3. Object Request Broker (ORB)
An object request broker (ORB) is a middleware technology that manages

communication and data exchange between objects. ORBs promote interoperability of
distributed object systems because they enable users to build systems by piecing together
objects-from different vendors – that communicate with each other via the ORB
The implementation details of the ORB are generally not important to developers
building distributed systems. The developers are only concerned with the object interface
details. This form of information hiding enhances system maintainability since the object
communication details are hidden from the developers and isolated in the ORB.
3.3.1. ORB Technical Overview
ORB technology promotes the goal of object communication across machine, software,
and vendor boundaries. The relevant functions of an ORB technology are.
 Interface definition.
 Location and possible activation of remote objects.
 Communication between clients and object.
An object request broker acts as a kind of telephone exchange. It provides a directory of

services and helps establish connections between clients and these services.
The ORB must support many functions in order to operate consistently and effectively,
but many of these functions are hidden from the user of the ORB.
It is the responsibility of the ORB to provide the illusion of locality, in other words, to
make it appear as if the object is local to the client, while in reality it may reside in a
different process or machine.
Thus the ORB a frame work for cross –system communication between objects. This is
the first technical step toward interoperability of object systems.
52
ORB
Activate
Locate Service
Service Establish
Connection
Client Remote
application Service(object)
Communicate
Object Request Broker (ORB)
The next technical step toward object system interoperability is the communication of
objects across platforms. An ORB allows objects to hide their implementation details
from clients.
3.3.2. ORB Technologies
There are two major ORB technologies:
 The object Management Group’s (OMG) Common Object Request Broker

Architecture (CORBA) specification.
 Microsoft’s Component Object Model(COM) (COM, DCOM, and Related
capabilities)
An additional, newly-emerging ORB model is Remote Method Invocation (RMI); this is

specified as part of the Java language/virtual machine. RMI allows Java objects to be
executed remotely. This provides ORB- like capabilities as a native extension of Java.
3.4. System Object Model (SOM)
System Object Model (SOM) is an IBM technology that is being licensed to other
companies in anticipation of extending its benefits to heterogeneous environments. In
addition, a number of language vendors are working on providing native SOM capability
for their compilers.
3.4.1. Features of SOM
 Its support for metaprogramming

 Support or binary compatibility across binary releases.
53
The SOM metaprogramming model largely follows the Smalltalk, so every class is itself
an object and as such an instance of a metaclass. All metaclasses are instances of a single
class, metaclass, which is its own metaclass.
SOM goes beyond the reflective capabilities of CORBA as SOM allows classes to be
constructed or modified dynamically.
SOM comes with precise rules as to which changes in a release maintain, and which other
changes break, binary compatibility with previous releases. Binary compatibility is a very
important issue in a component world.
3.4.2. Basic Concepts
SOM provides an object model distinct from those contained in object-oriented

programming languages yet does not interface with the use of those models in the same
application that is using SOM. In addition, SOM can be used with procedural
programming languages thus providing an object model for those languages that do not
have one.
3.4.3. Object
SOM objects are derived from a root object which defines the essential behavior common
to all SOM objects. Factory methods are used to create SOM objects at run time. These
factory methods are invoked on a class object, in the SOM run-time.
1. Operations
The interface to SOM object is defined by permitting the specification of operation

signatures which consist of an operation name and the argument and result types.
Operations are performed on methods which implement an object behavior.
2. Requests
Client requests are invoked on objects by specifying the name of an object and the
name of the operation along with parameters to invoke on it. An object can support
multiple operations.
3. Methods
Messages are not explicitly identified in SOM.
4. Specification of behavioral semantics
SOM defines object behavior by permitting the specification of operation

signatures which consist of an operation name, and the argument and result types.
54
The semantics of the operations on an object are defined by the methods that
implement these operations.
5. Methods
Methods are invoked on SOM objects. Methods can be relocated upward in the
class hierarchy without requiring the client to be re-compiled. SOM supports three
different method dispatching mechanisms; offset, name resolution, and dispatch
function resolution.
6. State
The state of SOM objects is accessed through published interfaces to an object

invoking operations on objects may cause state changes.
7. Object lifetime
SOM objects are created by invoking a create operation on a factory object in the
SOM runtime. Once created, the object will exist until explicitly deleted or until the
process that created it no longer exists.
8. Behavior/State grouping
SOM uses the classical object model in that a target object must be specified for
each operation.
9. Communication model
Complex object interactions that need to span process boundaries can be

constructed on SOM using standard inter-process communication facilities provided
by the underlying system. No serialization code is necessary if programming in a
single process model.
A class library based on SOM is used to provide SOM with distributed access to
remote SOM objects.
3.5. Portable object adapter
An object Adapter is an integral part of the Common Object Request Broker Architecture
(CORBA). An object Adapter assists an object Request Broker (ORB) in delivering client
request to server object implementations (Servants)
Services provided by an Object Adapter include:
 Generating and interpreting object references

 Activating and deactivating servants
55
 Demultiplexing requests to map object references onto their corresponding

servants.
 Collaborating with automatically-generated IDL skeletons to invoke operations on
servants.
3.5.1. Overview
ORBs eliminate many tedious, error-prone, and non-portable aspects of developing and
maintaining distributed applications by automating common network programming tasks
such as object location, object activation, parameter marshaling, fault recovery, and
security.
It allows developers to construct CORBA server application that are portable between
heterogeneous ORB implementations.
3.5.2. CORBA Architecture
Interface IDL Compiler Implementation

repository repository
In args
Operation ()
Clients Object (Servant)
Out args+return value
Dll IDL ORB IDL IDL Object

stubs interface Skeleton (Servant
)
GIOP/IIOP ORB CORE
Standard interface Standard language mapping
ORB –Specific interface Standard protocol
CORBA Object Request Broker (ORBs) allow clients to invoke operations on distributed
objects without concern for:
Object location
CORBA objects can be collocated with the client or distributed on a remote server,
without affecting their implementation or use.
56
Programming language
The languages supported by CORBA include C,C++, Java, Ada95, COBOL, and
Smalltalk, among others.
OS platform
CORBA runs on many OS platforms, including Win32, UNIX, MVS, and real-time
embedded systems like VxWorks, Chorus, and LynxOS.
Communication protocols and interconnects
The communication protocols and interconnects that CORBA can run on include TCP/IP,
IPX/SPX, FDDI, ATM, Ethernet, Fast Ethernet, embedded system backplanes, and
shared memory.
Hardware
CORBA shields application from side-effects stemming from differences in hardware

such as storage layout and data type sizes/ranges.
3.6. CORBA Services
The CORBA services are the set of fundamental enabling interfaces for globally
applicable service capabilities. To success with CORBA a good familiarity with each of
the CORBA services is essential.
Large CORBA based systems frequently use only a few CORBA services. The CORBA
services are reasonably small specifications that can be proto typed quickly and later
upgraded to vendor-supplied implementation if that becomes on option.
3.6.1. OMA
The object management architecture, it contains the details of the CORBA services,
CORBA facilities, CORBA domains and application interfaces. In this OMA, CORBA is
the central component through which all other objects communicate.
CORBA services
CORBA services are enabling services. They are primitive fundamental and globally
applicable. It is useful for all kinds of applications and are domain- independent in that
they are intended to be reused and specialized by applications.
57
CORBA facilities
The other interface is the CORBA facilities. It acts as an intermediater between CORBA
services and CORBA domains. It relates to the CORBA domains interfaces.
CORBA domains
It represents different vertical market areas such as internet and telecom.
Application interfaces
It uses interfaces from CORBA services, CORBA facilities and CORBA domains.
3.6.2. CORBA services architecture
Client Target object
Object request broker
Client-side security Server-side security

-security association -security association
-Access control -Access control
-Message protection -Message protection
-Audit -Audit
It provides an organization for the services and infrastructure elements. It comprises four
categories of service elements. They are
I. Infracture services: it includes services elements that are tightly coupled to the
ORB mechanism such as messaging and interoperability.
II. Task management services: it includes enabling services for managing
distributed object events, transactions and concurrency.
III. Information management Services: it includes basic services for manipulation
and retrieval of data such as properties, relationship and collections.
IV. System management services: it includes basic services for enabling the
management of meta-data, naming and object lifecycle.
3.6.3. Infrastructure Services
3.6.3.1. Time Service
 enables the user to obtain current time together with an error estimate associated
with it.
58
 Ascertains the order in which “events” occurred.

 Generates time-based events based on timers and alarms.
 Computes the interval between two events.
 Consists of two services, hence defines two service interface.
 Time service manages Universal Time Objects(UTOs) and Time Interval Objects
(TIOs), and is represented by the Time Service Interface.
 Timer Event Service manages Timer Event Handler objects, and is represented by
the Timer EventService interface.
Timer Event Service Interface.
module Cos TimerEvent{

enum Time Type{
TTAbsolute,
TTRelative,
TTPeriodic
};
enum EventStatus {
ESTimeSet,
ESTimeCleared,
ESTriggered,
ESFailedTrigger
};
struct TimerEvent T{
TimeBase::UtcT utc;
any event_data;
};
interface TimerEventHandler{
readonly attribute EventStatus status;
boolean time_set(out cosTime::UTO uto);
void SetTimer(
in TimeType time_type,
in CosTime::UTO trigger_time
);
boolean cancel_timer();
void set_data(in any event_data);
};
interface TimerEventService{
TimerEventHandler register(
in CosEventComm::PushConsumer event_interface,
in any data
);
void unregister(in TimerEventHandler timer_event_handle);
CosTime::UTO event_time(in TimerEvent T timer_event);
};
};
59
3.6.3.2. Security Service
1. Identification and authentication of principals to verify they are who they claim to
be.
2. Authorization and access control – deciding whether a principal can access an
object.
3. Security auditing to make users accountable for their security related actions.
4. Security of communication between objects.
5. Non-repudiation provides irrefutable evidence of actions such as proof of origin
of data to the recipient, or proof of receipt of data to the sender to protect against
subsequent attempts to falsely deny the receiving or sending of the data.
6. Administration of security information.
7. Extends the structure of the ORB to allow for security mechanisms and protocols
8. Does not define cryptographic protocols – an Encryption protocol for secure
interoperability is being specified separately.
3.7. CORBA Component Model (CCM)
3.7.1. Introduction
The CORBA Component Model (CCM) is a specification for creating server-side

scalable, language-neutral, transactional, multi-user and secure enterprise-level
applications. It provides a consistent component architecture framework for creating
distributed n-tier middleware.
Since CCM is multi-lingual, its packaging technology needs to be more comprehensive

than EJB. It accomplishes this by building on the software packaging architecture being
developed by the W3C to provide a complete vocabulary for describing binary
executables.
Like EJB, it focuses on the services needed for server applications and leaves most of the
implementation details to the container, not application.
3.7.2. CCM Architecture
A typical CCM Architecture consists of
1. CCM Containers
2. CORBA components that run in these containers
3. The Portable Object Adapter (POA)
4. The Object Request Broker(ORB)
5. Other CORBA object services like CORBA Transactions, CORBA Security
CORBA Persistence, CORBA Events, etc.
60
In a typical development and deployment scenario, there will be an application server

provider who creates and sells and application server along with CCM containers that
will run on these servers. Then there will be the CCM providers-people responsible for
developing CORBA component and the application assemblers-people that use pre-built
CORBA components to build their applications.
Component stock exchange reference

Facet
implementation
Component
Stock_Exchange
Stock_Quate sec
Provided Receptacle
interface
Buy offers
Price change
Event
Even Sell offers source
sink
Attributes Event sink

implementations
Application Servers
These provide the system services like raw execution environment multiprocessing, load-
balancing, device access, provide naming and transaction services and make containers
visible.
CCM Container
These act as the interface between a CORBA Component and the outside world. A CCM
Client never accesses a CORBA Component directly. Any component access is done
through container-generated methods which in turn invoke the component’s methods
there are basically two basic types of containers.
They are,
I. Transient containers
II. Persistent containers
Transient Containers
It may contains transient, non-persistent components whose states are not saved at all.
61
Persistent Containers
It contains persistent components whose states are saved between invocations. Depending
upon the types of components that they can execute, CCM Containers may be divided
into:
I. Service Containers
II. Session Containers
III. Entity Containers
IV. Other Containers
CCM Clients
These make use of the CCM Components for their operations. They find the CCM
container that contains the component through COSNaming and create, or obtain a
reference to the component’s container through the component’s Home interface. They
then make use of the CCM container to invoke the component methods.
3.7.3. Traditional CORBA Object Model
In args
Operation ()
Client Object (Servant)
Out args+return value
IDL ORB IDL Object

Stubs interface Skeleton adapter
ORB CORE
The traditional OMG Common Object Broker Architecture (CORBA) enables software
applications to invoke operations on distributed objects without concern for object
location, programming language, OS platform, communication protocols,
interconnections, or hardware.
To provide higher-level reusable components, the OMG also specifies a set of CORBA
Object Services that define standard interfaces to access common distribution services,
such as naming, trading, and event notification.
62
3.7.4. Overview of the CORBA Component Model (CCM)
To address the limitations with the earlier CORBA object model, the OMG adopted the
CORBA Component Model(CCM) to extend and subsume the CORBA Object Model.
The CCM extends the CORBA object model by defining features and services that enable
application developers to implement, manage, configure, and deploy components that
integrate commonly used CORBA services, such as transaction, security, persistent state,
and event notification services, in a standard environment.
In addition the CCM standard allows greater software reuse for servers and provides
greater flexibility for dynamic configuration of CORBA applications. With the increasing
acceptance of CORBA in a wide range of application domains, CCM is well positioned
for use in scalable, mission-critical client/server applications.
3.7.4.1. CCM Component Overview
CCM Components can expose multiple interfaces. While defining the IDL for each
component, the interfaces that it provides and the interfaces that it uses have to be
specified.
Similarly, the events that it emits and the events that it consumes have to be defined in
the IDL. The interfaces that it provides are called facets. The ability to use an interface is
facilitated by declaring it as a receptacle.
Event emition and publication declarations are used to define an event source. Event
consumption declarations are used to describe event sinks.
Facets, receptacles, event sources and event sinks are collectively called ports.
There are four types of CCM components. They are
1. Service Components
2. Session Components
3. Process Components
4. Entity Components
1. Service Components
Each Service component is usually associated with one CCM Client and its lifetime is
restricted to that of one single operation request. Each service component is created and
destroyed by the particular CCM client that it is associated with. Service components do
not survive a system shutdown.
63
2. Session Components
Each session component is usually associated with one CCM Client. Each session
component is created and destroyed by the particular CCM Client that it is associated
with. A session component can either have states or they can be stateless. However,
session components do not survive a system shutdown. A session component is very
similar to a session EJB.
They are.
a. Stateless session components.

b. Stateful session components
a. Stateless Session Componets
These types of components have no internal state. Since they do not have any states,
they need not be passivated. Because of the fact that they are stateless, they can be pooled
in to service multiple clients.
b. Stateful Session Components
These types of components possess internal states. Hence they need to handle
persistence. These types of components can be saved and restored across client sessions.
3. Process Components
Process components always have states. Each p rocess Components may however be
shared by multiple CCM Clients. Their states can be persisted and stored across multiple
invocations. Hence they can survive system shutdowns.
4. Entity Components
Entity components always have state. Each entity component may however be shared
by multiple CCM clients. Their states can be persisted and stored across multiple
invocations. Hence they can survive system shutdowns.
Each Entity Components can be uniquely identified by its primary key. An Entity
components is very similar to an Entity EJB.
3.8. Container
3.8.1. Overview
The container manages component instances depending on component category. It offers

all its services through simplified APIs. It becomes component’s window to the outside
world.
64
The container offers series of local interfaces for establishing component’s context and
allows component to implement series of callback method.
Home
Transaction
interfaces
Container
External
POA
PSS
ORB
Client
CORBA
Component Security
Call back
Notification
Internal
As shown in the figure above, the container manages a component. It creates and uses a
POA with requested features for specific component category.client can use external
interfaces of a component to interact with component and home interfaces to manage life
cycle of a component.
External API types
The external API types of a Component are the Contract between the component
developer and the component client. It consists of two types of interfaces mainly home
interface and application interface. Home interface allows client to obtain reference to
one of the application interfaces the component implements.
From client’s prospective two design patterns are supported namely factory patterns for
creating new components and finder patterns for existing components. These patterns are
distinguished by the presence of primary key on home declaration.
The Container API type
The container API defines a API framework, i.e. contract between specific component
and container. It defines two types of container APIs namely session APIs.
65
3.8.2. CORBA Usage Model
A CORBA usage model specifies the required interaction pattern between the container,
the POA and the CORBA services. It defines three types of usage model that are
distinguished by reference persistence and servant to object id mapping.
 Stateless - which uses transient object references in conjunction with a POA

servant which can support any object id.
 Conversational – which uses transient references with a POA servant that is
dedicated to specific object id.
 Durable – which uses persistence references with POA servant that is dedicated
to a specific object id.
3.8.3. Component Categories
A service component has behavior, but no state and no identity. It’s useful for modeling
things that provide single independent execution of an operation.
A session component has a behavior, a transient state and but no persistent identity. It’s
useful for modeling a client session such as login, iterate or shopping cart.
An entity component has behavior, persistent state which is not visible to client and
persistent identity which is visible through explicit user defined operations. It’s useful to
model a business process rather than entities.
Servant Programming Environment
The container provides interfaces to component to access CORBA services and to other
elements of component model. Component defines these features using deployment
description for runtime container. In addition to object services the component can
specify servant lifetime policy to optimize memory usage.
1. Servant lifetime management

2. Transaction
3. Security
4. Events
5. Persistence.
1. Servant lifetime management
Servant are programming language object which the POA uses to dispatch operation
requests based on object identification. The server programming model for CORBA
components include facilities to efficiently manage the memory associated with these
programming objects. The servant lifetime policies are defined as follows.
66
Method: This policy causes the container to activate the component on every operation
request and to passivate when that operation is completed.
Transaction: This policy causes the container to activate the component on the first
operation of request within transaction and leave it until transaction completes.
Component: This policy causes the container to activate the component on the first
operation and remains active until component implementation requests to passivate.
Container: This policy causes the container to activate component on the first operation
request and leave it active until container decides to passivate it.
2. Transaction
CORBA component supports both self-managed transaction through container APIs or

container managed transaction by using set of defined polices.
NOT_SUPPORTED: The component does not support transactions. If client sends

transaction to the component, it remains suspended until component completes the
operation.
REQUIRED: The component requires a current transaction to execute successfully. If

the operation is invoked without a transaction context, the container starts new
transaction and commits or rollback once operation is completed by component.
SUPPORTS: This Component will support transaction if one is available.
REQUIRES_NEW: The component requires its own transaction to execute successfully.

If client sends transaction context it’ll remain suspended until the new transaction is
completed.
MANDATORY: The component requires the client be in a current transaction before

this operation is invoked.
NEVER: The Component required that client not be in current transaction before this
operation is invoked.
3. Security
The security policy is applied consistently to all categories of components. The

container relies on CORBA security to Consume the security policy declarations from the
deployment descriptor and to check active credential for invoking operation. Access
permissions are defined by the deployment descriptor associated with the component.
67
4. Events
CORBA components use a simple subset of the CORBA notification service to emit
and consume events. Event can be transactional as well as can contain access control lists
5. Persistence
The entity container API type supports the use of persistence mechanism for making
component state durable. Container API defines two types of persistence support.
Container-managed persistence the component developer simply defines the state that is
to be made persistent and container automatically saves and restores state as required.
Container managed persistence is selected by defining abstract state associated with

component using state declaration language called PSDL
Self managed persistence the component developer assumes the responsibility of

managing persistent state of the component.
3.8.4. Application Server
These provides the system services like.
I. A raw execution environment.

II. Multiprocessing
III. Load balancing
IV. Device access
V. Providing naming and transaction services
VI. Make containers visible.
3.9. Model Driven Architecture
3.9.1. Overview
It’s about integration. It’s about interoperability. For eleven years, the Object
Management Group (OMG) has focused on making sure that you can integrate what
you’ve built, with what you’re building, with what you’re going to build.
By providing transparency to operating system, platform, programming language and

even network protocol, CORBA provides the adapter for the information plug, breaking
down barriers to interoperability at enterprises around the world.
Proven in the marketplace with the standardization of CORBA, the CORBA services
Domain Facilities, UML, the MOF, and OMG’s other Modeling standards, the process is
one of our group’s major assets.
68
3.9.2. OMG’s Modeling Specifications
UML, the Unified Modeling Language, allows a model to be constructed, viewed

developed, and manipulated in a standard way at analysis and design time. As blueprints
do for an office building, UML diagrams allow an application design to be evaluated and
critiqued before it is coded, when changes are easier and less expensive to make.
The Meta-Object Facility (MOF) standardizes a model repository facility and the
foundation for a company’s common reference model. The common Warehouse Meta
model (CWM) standardizes how to represent a database schema for data warehouses,
improving data mining results by matching up concepts common to multiple warehouses
even where they go by different names.
Complementing, but not limited to, CORBA, OMG’s modeling specifications are being
used in virtually every development environment including Java/EJB,
COM/DCOM/.NET and XML/SOAP. Extending the usefulness of OMG’s modeling
standards, forthcoming specifications will lead to automation of design flow UML
models, through coding, to running application.
3.9.3. Middleware proliferates
Middleware environments typically combine a server architecture which may be

componentized but is almost certainly transactional (CCM, EJB, or MTS), with an
interoperability architecture which may be standard (i.e., CORBA), proprietary (e.g.,
DCOM), or somewhere in the middle (e.g., XML/SOAP)
Essential services beyond transactions – such as
1. Directory
2. Persistence
3. Event handling
4. Messaging
are usually included
There is a limited number of middleware environments, including CORBA’s Component

Model, Enterprise JavaBeans, XML/SOAP and .NET.
3.9.4. Model Driven Integration: The Architecture of Choice
At the beginning of the 21st century, OMG has a middleware solution that works:
CORBA. Today CORBA is widely used to communicate over the internet, integrating
applications 24 hours a day, seven days a week. OMG’s layered services and vertical
market specifications build on CORBA , and are strongly established through the OMG
community process.
69
Finally OMG’s modeling environment has spawned universally- recognized standards for
object modeling, repositories, data modeling and data warehousing.
Finance
Manufacturing E-Commerce
CORBA
UML
XMI/XML
WEB
Space Model driven architecture Telecom
MOF
CWM
JAVA NET
Transportation Healthcare
More…
Because of the proliferation of middleware technologies, enterprises have applications

on different middleware that simply have to be integrated even though this process is
time-consuming and expensive.
An architecture built around an open, middleware-neutral model at its core. There is

immense value across the software lifecycle to planning and designing your applications
but, even if you don’t take the time to do this, you can gain flexibility in aheterogenous
world by building your application on a stable platform with planned, consistent, model-
based components.
Mappings
Mappings couple generic elements in each core model with their specific counterparts in
a model of each supported platform.
Modelers, working in UML, build a platform-independent application model that

specifies run-time behavior as well as business rules, and highly automated tools are able
to use a mapping to covert this general application model into one targeted to a specific
platform such as CCM, EJB, or MTS.
70
Automation
Maximizing automation of the mapping step is a goal; however, in most cases some hand
cooling will be required, especially in the absence of MDA tools. As users and tool
builders gain experience, and techniques for modeling application semantics become
better developed, the amount of intervention required will decrease.
Generation of application code
Many of today’s connection technologies will be integrated by the MDA, with room for
tomorrow’s “next best thing”. CORBA provides the best middleware choice because it is
vendor-and language-neutral, and bridges easily to all of the other middleware
environment.
Interoperability
Because the MDA is based on platform-independent core model, adding new middleware
platforms to our interoperability environment is straightforward: After identifying the
way a new platform represents and implements common middleware concepts and
functions, OMG members will incorporate this information in to the MDA as a mapping.
71
SUMMARY
 CORBA uses an interface definition language to specify the interfaces that

objects will present to the world.
 CORBA is a specification of a standard architecture for object request
brokers
 IDL interface provides the information needed to develop clients that use the
interface’s operations.
 An OMG IDL specification consists of one or more type definitions, constant
definitions, exceptions, or module definitions.
 SOM objects are derived from a root object which defines the essential
behavior common to all SOM objects.
 The POA provides an extensible mechanism for associating policies with
servants in a POA.
 CCM is multi-lingual, its packaging technology needs to be more
comprehensive than EJB.
72
1. what is an exception? List any three CORBA system exceptions and their mapping to
java exception.
2. In CORBA, how do you cast an object reference to a more specific type?
3. In a distributed CORBA application, how do you pass a list as a parameter using ;
IDL ? Give an example.
4. What is a IDL programming model?
5. Define transaction with its properties.
6. What is the purpose of creating five more .java files while compiling an IDL file
through a broker?
7. What are the equivalent in Java for the following in OMG IDL?
(a) Short
(b) Module
8. Differentiate between the naming and trading services offered by OMG.
9. What are the features of SOM?
10. What is POA?
1. Explain in detail the need for CORBA trading service

2. What is the purpose of Event service in CORBA? Explain
3. Explain the steps involved in the development of Java ORB with an example
4. Explain the models involved in initiating event communication.
5. How IDL operation are mapped to methods in Java?
73
UNIT - IV .NET BASED COMPONENT TECHNOLOGIES
COM – Distributed COM – object reuse – interfaces and versioning – dispatch interfaces
– connectable objects – OLE containers and servers – Active X controls - .NET
component – assemblies – app domains – contexts – reflection – remoting.
4.1. Component Object Model (COM)
The component object model(COM) is a software architecture that allows the

components made by different range of software vendor to be combined into variety of
applications.
COM defines a standard for component interoperability is not dependent on any

particular programming language, is available on multiple platforms, and is extensible
Developers use COM to:
 Create reusable software components

 Link components together to build applications
 Take advantage of windows services
COM is used in application such as the Microsoft office family of products. COM is the
basis of a number of windows services such as COM+, distributed COM(DCOM),
MSMQ, and ActiveX controls.
4.1.1. Introduction
The Component Object Model (COM) is a component software architecture that permits
applications and systems to be built from components supplied by different software
vendors. COM is the fundamental architecture that forms the foundations for higher-level
software services, like those provided by OLE.
OLE services cover various aspects of component software, including compound

documents, custom controls, inter-application scripting data transfer, and other software
interactions.
Benefit of COM
74
 COM works by having any chunk of software implement its services as one or
more COM objects.
 Each of these COM object supports one or more interfaces, each including a
number of methods.
 Each COM objects runs within a Server.
Interface
Interface
COM Object
Interface
Server
4.1.2. COM Fundamentals
The Component object model defines several fundamental concepts that provide the
model’s structural underpinnings. These include:
 A binary standard for function calling between components.

 A provision for strongly-typed groupings of functions into interfaces.
 A base interface providing
 A way for components to dynamically discover the interfaces implemented by
other components.
 Reference counting to allow components to track their own lifetime and delete
themselves when appropriate.
 A method to uniquely identify components and their interfaces.
 A “Component loader” to set up component interactions and additionally in the
cross-process and cross-network cases to help deal with component interactions.
4.1.2.1. Binary standard
For any given platform, COM defines
 A standard way to lay out virtual function tables in memory,

 A standard way to call functions through the vtables.
Thus any language that can call functions via pointers all can be used to write
components that can interoperate with other components written to the same binary
standard.
75
The double indirection allows for vtable sharing among multiple instances of the same
object class. On a system with hundreds of objects instances, vtable sharing can reduce
memory requirements considerably.
Component object
Client
variable VTBL
VTBL Pointer
Private object data

Pointer to function Function1 (pObj, arg1, arg2…)
{
Pointer to function ……
}
Pointer to function
A Vtable
4.1.2.2 Objects and components
The word object tends to mean something different to everyone. To clarify, in COM, an
object is some piece of compiled code that provides some service to the rest of the
system. To avoid confusion, it is probably best to refer to a COM objects with source –
code object- oriented programming(OOP) objects such as those defined in C++.
Component objects support a base interface called IUnknown along with any
combination of other interfaces, depending on what functionality the component object
chooses to expose.
4.1.2.3. Interfaces
In COM, application interact with each other and with the system through collections of
functions called interfaces. Note that all OLE services are simply COM interfaces. A
COM interface is a strongly-typed contract between software components to provide a
small but useful set of semantically related operations.
Interface name begin with “I” by convention. OLE provides a number of useful general
purpose interfaces, but because anyone can define custom interfaces as well, we expect
developers will develop their own interfaces as they as they deploy component-based
applications.
Example: interface ILookup : public IUnknown
Interface ILookup : public IUnknown

{
public
76
virtual HRESULT_stdcall LookupByName(LPTSTR lpName, TCHAR **lplpNumber)

=0;
virtual HRESULT_stdcall LookupByName(LPTSTR lpNumber, TCHAR
**lplpName)=0;
};
4.1.2.4. COM Objects
COM objects contain interfaces, each of which has two names,
 A name for software to use

 A name for people to use
The human-readable name conventionally starts with an I. The unique software readable
name is called a globally unique identifier, or GUID.
4.2. Distributed COM (DCOM)
4.2.1 Introduction
 Distributed COM(DCOM) is an extension of the component object model (COM)

 Microsoft developed it in 1996.
 It allows the clients to create objects and use their methods on remote machines
 Same as COM, DCOM is also object oriented.
 It can be used in various platforms, such as Windows, Unix, Linux , and
Macintosh.
Microsoft® Distributed COM (DCOM) extends the components object model (COM) to
support communication among objects on different computers- on a LAN, a WAN, or
even the internet.
With DCOM, your application can be distributed at locations that make the most sense to
your customer and to the application, because DCOM is a seamless evolution of COM,
the world’s leading component technology.
4.2.2. DCOM Architecture
COM defines how components and their clients interact. This interaction is defined such
that the client and the component can connect without the need of any intermediary
system component.
When client and component reside on different machines, DCOM simply replaces the
local inter process communication with a network protocol. Neither the client nor the
component is aware that the wire that connects them has just become a little longer.
77
The COM run-time provides object-oriented services to clients and components and uses
RPC and the security provider to generate standard network packets that conform to the
DCOM wire-protocol standard
COM COM
Client run-time run-time Component
Security DCE RPC Security DCE RPC

Provider Provider
Protocol stack
Protocol stack
DCOM network
protocol
4.2.4. DCOM design issues
 Location independence: DCOM’s location independence greatly simplifies the

task of distributing application components for optimum overall performance
 Language Neutrality: With DCOM’s language independence, application
developers can choose the tools and languages that they are most familiar.
 Connection Management: DCOM uses an efficient pinging protocol to detect if
clients are still active.
 Scalability: A critical factor for a distributed application is its ability to grow
with the number of users, the amount of data, and the required functionality.
 Flexible Deployment: As the load on an application grows, not even the fastest
multiprocessor machine may be able to accommodate demand, even if your
budget can accommodate such a machine.
 Evolving Functionality
 Performance
 Bandwidth and Latency
 Optimize Network Round-trips
 Security
 Load Balancing
 Fault Tolerance
 Protocol Neutrality
 Platform Neutrality
78
4.3. Object Reuse
An important goal of any object model is that component author can reuse and external
objects provided by others as pieces of their own component implementations.
IUnknown knows
A,B and C
External Outer Object

interfaces
IUnknown
A Controls
Inner objects
Cuter Object uses Lifetime
Inner Objects C
B Implementation
As any client
Inner Object
Contained inside
C Outer Object
4.3.1. Reusability Mechanisms
Reusable components is black box reuse which means the piece of code attempting to
reuse another component knows nothing and does not need to know anything about the
internal structure or implementation of the component being used.
4.4. Interfaces and Versioning
COM interfaces can be derived from other COM interfaces using single interface
inheritance. All COM interface inherit from IUnknown interface directly or indirectly.
IUnknown is the common base type of the interface hierarchy.
IUnknown
IDispatch IPersist
79
4.5. Dispatch Interfaces
Automation
Why not make applications programmable, so that they can be driven by both people and
software.
Macro languages are an attempt to offer this, but they are generally cryptic, and each
application offers its own macro language, i.e. there is no standard.
Automation is providing general programming through COM. The automation of

repetitive tasks would seem ideal for a language with scripting abilities like Visual Basic.
4.6. Connectable Objects
4.6.1. Overview
The COM technology known as connectable objects supports a generic ability for any
object, called in this context a “connectable” object, to express these capabilities
 The existence of “outgoing” interfaces, such as event sets

 The ability to enumerate the IIDs of the outgoing interfaces
 The ability to connect and disconnect “sinks” to the object for those outgoing IIDs
 The ability to enumerate the connections that exists to a particular outgoing
interface.
4.6.3. Architecture of Connectable Objects
The connectable object is only one piece of the overall architecture of connectable
objects. This technology includes the following elements:
 Connectable Object
 Client
 Sink object
 Connection point object
4.7. OLE Containers and Servers
Object Linking and Embedding (OLE) is Microsoft’s component document standard

OLE is a large collection of predefined interfaces
The OLE compound documents approach distinguishes between document container and
document server.
 A document server provides some content model and the capabilities to display
and manipulate that content.
80
 A document container accepts parts provided by arbitrary document servers.
4.8. ActiveX Controls
4.8.1. Overview
The original specification for ActiveX controls was very rigid. This led to code bloat, as
many controls didn’t need all of the features, such as being able to display a user
interface.
Control Container
ActiveX controls must run within a control container. A control container is client
software that knows how to use an ActiveX control.
Examples:
 Visual basic
 Internet Explorer
4.8.2. ActiveX and the Internet
COM was originally conceived as part of a mechanism for creating compound

documents. In some ways, the web is the ultimate compound document. Thus it is no
surprise that Microsoft has applied COM technology within its internet applications.
4.8.3. ActiveX scripting
When the HTML viewer loads document, that document might contain one or more
scripts. These scripts can make use of programmable objects exposed by the viewer. The
script executes in a component called the scripting engine.
As the script executes, it can invoke methods in the viewer’s objects and receive events
from those objects.
4.8.4. Loading and Downloading ActiveX Controls
Load a Control
In order to load a control that is already present on the system from a web page, use the
OBJECT tag in html. The following sample shows how.
Sample code:
<OBJECT
CLASSID=”clsid:99B42120-6EC7-11CF-A6C7-00AA00A47DD2”
81
ID=label1
WIDTH=150
HEIGHT=500
>
</OBJECT>
4.8.4. ActiveX and JavaBeans
These two technologies are essentially competing with each other. Each reflects the
philosophies and goals of their creators. The following table compares the two
technologies
ActiveX JavaBeans
Windows only Multiple platforms
Multiple languages Java only
Limited to DCOM Can use RMI or CORBA
Faster, since it is native code Slower, but platform independent
Security is based on user’s trust Supports Java’s security model
4.9. .NET Components
4.9.1. Assemblies
Overview
An assembly is sometimes described as a logical. EXE or .DLL, and can be an

application or a library.
An important aspect of assemblies is that they are part of the identity of a type. The
identity of a type is the assembly that houses it combined with the type name. This means
for example, that if assembly A exports a type called T, and assembly B exports a type
called T, the .NET runtime sees these as two completely different types.
Assemblies are also important in .NET with respect to security – many of the security
restrictions are enforced at the assembly boundary.
4.9.2. Application Domains
An AppDomain can be though of as a lightweight process. Multiple AppDomains can

exist inside a win32 process. The primary purpose of the AppDomain is to isolate an
application from other applications.
Win32 processes provide isolation by having distinct memory address spaces. This is
effective, but it is expensive and doesn’t scale well.
82
AppDomain Creation
AppDomains are usally created by hosts. Examples of hosts are the windows shell,
ASP.NET and IE. When you run a .NET application from the command-line, the host is
the shell. The shell creates a new AppDomain for every application.
‘appdomaintest.exe’ for this code to work as –is
using System;
using System.Runtime.Remoting;
public class CAppDomaininfo : MarshalByRefObject{
public string GetAppDomaininfo(){
return “AppDomain=”+AppDomain.CurrentDomain.FriendlyName;}}
public class App {

public static int Main(){
AppDomain ad=AppDomain.CreateDomain(“R C E T”, null,null);
ObjectHandle oh=ad.CreateInstance(“appdomaintest”,”CAppDomaininfo”);
CAppDomaininfo adinfo=(CAppDomaininfo)(oh.Unwrap());
String info= adinfo.GetAppDomaininfo();
Console.WriteLine(“AppDomain info:” +info);
return 0;
}
}
4.9.3. Contexts
“Managed” in the .NET context
The term ‘managed’ is the cause of much confusion. It is used in various places within
.NET, meaning slightly different things.
Managed Code:
The .NET framework provides several core run-time services to the a programs that run
within it- for example exception handling and security.
Managed Classes:
This is usually referred to in the context of managed extensions (ME) for C++. When
using ME C++, a class can be marked with the _gc keyword.
83
4.9.4. Reflection
All .NET compliers produce metadata about the types defined in the modules they
produce. This metadata is packaged along with the module, and can be accessed by a
mechanism called reflection. The System. Reflection namespace contains classes that can
be used to interrogate the types for a module/ assembly.
Reflection can also be used to dynamically invoke methods(System. Type.

InvokeMemeber), or even create types dynamically at run-
time(System.Reflection.Emit.TypeBuilder).
4.9.5. Remoting
.NET remoting working principle
.NET remoting involves sending messages along channels. Two of the standard channels
are HTTP and TCP.
TCP is intended for LAN only – HTTP can be used for LANs or WANs(internet).
Support
Support is provided for multiple message serialization formats.
Examples are,
 Soap (XML – based)

 Binary.
by default,
 HTTP channel uses SOAP

 TCP channel uses binary
But either channel can use either serialization format.
Objects have a default renew time- the lease is renewed when a successful call is made
from the client to the object. The client can also explicitly renew the lease.
84
Summary
 COM is used in application such as the Microsoft office family of products.

 COM is a general architecture for component software.
 Vtable sharing can reduce memory requirement considerably
 AddRef and Release are simple reference counting methods
 COM is designed to let application access components regardless of where
they are running.
 Automation is providing general programmability through COM.
 COM based application excepts a potential error indication on each method
invocation.
 Reflection can also be used to dynamically invoke methods.
85
1. What is an ActiveX control?

2. Why is DOM dependent on Microsoft Technology?
3. How does object activation work in COM?
4. How does OLE 2 facilitate relocation of components?
5. What is the use of COM?
6. Write about IUnknown interface.
7. What is Reflection?
8. What is Application Domain?
9. What is an assembly?
10. What is the application programming interface methods used to generate a component
object model client in VisualC++ ActiveX Template Library?
1. Explain the basic architecture of DCOM.

2. Describe in detail the process of communication in DCOM components.
3. Explain about COM factories.
4. Explain ActiveX controls.
5. Explain DCOM and CORBA
86
UNIT - V COMPONENT FRAMEWORKS AND DEVELOPMENT
Connectors – contexts – EJB containers – CLR context and channels – Black Box
component framework - directory objects – cross – development environment –
component – oriented programming – component design and implementation tools –
testing tools – assembly tools
5.1. Connectors
5.1.1. Introduction
A few years ago, the trend to construct software systems as a collection of cooperating
reusable components emerged and has become widely accepted since. Influenced by the
academic research projects focused on components, several industrial systems on the
market advertise support of component technology.
To describe component interactions, an ADL may encompass the connector concept

typically, a connector is a first class architectural element that reflects the specific
features of interactions among components in a system.
Overview and related work
The following basic approaches to specifying component interactions can be identified.
1. Using implicit connections

2. via Connectors, which can be either built-in or user-defined.
The Darwin language is a typical representative of ADLs that use implicit connections.
The connections among components are specified via direct bindings of their requires and
provides interfaces.
Basic Connector Tasks
To understand the connector concept properly, it is useful to identify and analyze the
basic tasks a connector should perform; here, the taxonomy of software connectors
presented in can be used for guidance.
From the main service categories and the basic connector types of this taxonomy, we
have selected the connector tasks listed below that we generally consider the key ones.
87
Control and data transfer
A connector specifies the mechanisms on which possible control and/or data transfer is
based. Each of these mechanisms has specific characteristics and properties, e.g., a
procedure call can be local or remote.
As to RPC, various kinds of middleware can be used to implement it. Similarly event
handling can be based on an event channel, a centralized event queue, etc.
Connector Architecture
Depending on the internal elements employed, a connector architecture can be simple or

compound. The internal elements of a simple connector architecture are instances of
primitive elements only; some of them can be specified as optional.
For every primitive element type, in addition to functional specification in plain English,
a precise specification of its semantics is given by mappings to underlying environments.
5.2. Contexts
Context is one of the current contextual composition approaches.
Context uses.
1) COM apartments
It is used to separate objects by threading model.

2) MTS Contexts
It is used to separate by transactional domain.

Contexts added these to notions and also added a large number of new context properties.
In COM apartments, the declaration takes the form of registry entries per COM class.
5.3. EJB Container

5.3.1. Overview
 The EJB container is the layer between the bean and the system services of the
operating system or the middleware.
 It is responsible for all lifecycle operations as well as the application of externally
defined policies for transactions, security, and persistence.
88
 By standardizing commonly used design patterns, the application programmer is

free to concentrate on business logic
EJB Home implementation

EJB Home All life cycle services
(Bean identifier) For the bean
Create find remove
Client
Methods Enterprise bean
EJB Object
(Client view)
EJB object provides a client view of the
Enterprises bean. It intercepts all calls and
Performs transaction, state, persistence
and security services for the bean
5.4. CLR Contexts and Channels

The CLR context infrastructure is probably the first attempt to provide a extensible
infrastructure for contextual composition. In CLR contexts properties is not included. So
the third parties can contribute a new properties to this contexts. Within the context
boundary, the context properties can intercept, act on, and manipulate the action of CLR
contexts.
5.4.1. Context Boundary
The CLR contexts offers a opportunity to populate the new context’s boundary with
properties, when need to construct a new context. A particular context property can be
added when some property requested for creating a new context.
CLR Objects
CLR objects come in four types. Such as
I. Values types
II. Pass-by-value types
III. Pass-by-reference types
IV. Context-bound types
5.5. Black Box Component Framework

5.5.1. Overview
The Black Box component framework is part of the Black Box component builder.
 It is the first component frameworks.

 Released in 1994.
89
 Also called as Black Box.

 Formerly known as Oberon/F, Oberon Microsystem.
 A Component oriented rapid development tool.
 Component oriented programming environment.
 Reused by means of object composition.
 A component framework plays a very important role in component
systems.
5.5.3. Characteristics of Black Box
The Black box architecture is based on architecture of Black box. Such as
I. Carrier-ridder-mapper design pattern

II. Cascaded message multicasting services
III. Hierarchical model view separation
IV. Container models
V. Directory objects
5.6. Directory Objects

 Directory objects is the one of the characteristics of black box.
 It is the base for black box architecture.
When abstract interfaces are mode public, the Black box abstraction is considered so
important. The use of language is ruled out, as these require the class name.
Each module introducing a new abstraction also provides a configurable directory object.
It is default for all cases for which no specific directory object is available.
For example, consider the following file system abstraction.
DEFINITION Files;
TYPE
Locator = ….;
Name = ….;
File = ….;
Directory = POINTER TO ABSTRACT RECORD
(d: Directory) This(Path: ARRAY OF CHAR): Locator, NEW, ABSTRACT;
(d: Directory) New(loc : Locator) : File, NEW, ABSTRACT;
(d: Directory) Old(loc : Locator; name: Name) :File, NEW, ABSTRACT;
….
END;
VAR dir-: Directory; (*read-only variable*)
90
END Files.
The above excerpt contains
 Locators are abstract path names.

 Names are file names to open or to create.
 Files are the files to open or to create.
 Directory is pointer to abstract record.
A file directory object can be asked to open an existing “old” file by name or create a
new one that initially has no name.
5.7. Cross – Development environment
Portos IDE
The portos IDE is a Cross – development environment for developing portos

applications. It is an extension of the black box component builder.
Various servers
for remote control,
debugging , etc
PortosCOM PortosJava Portosloader Portoslog
PortosThreads
Commstreams Subset of the
Black box component
frameworks with serial
communication facilities
META
PortosTasks
PortosKernal Minimal portos core
The rectangles represent individual component pascal modules. Rectangles with thicker
outlines are complete subsystems consisting of several modules or open collections of
component implementations.
91
5.8. Component – Oriented Programming
Component – Oriented programming (COP) address the aspects of programming

components.
The definition of COP is
Component – oriented programming requires support of
 Polymorphism
 Modular encapsulation
 Late binding and loading
 Safety
All existing methodologies work only with in a component. The issues regarding
complex interactions can be addressed at the level of programming languages and
approaches. So a proper methodology for COP needs to be found.
5.9. Component design and implementation tools
Component design
It rests on the environment specification that is given by a component framework and

component model.
Component development
Component development was rapid application development (RAD) methods to capture

requirements quickly within a working component system.
Component construction process is guided and helped by the support of the following
 Construction of models (UML)

 Metadata
These models are used to construct a document. In application servers the components
are very helpful to develop a software. By using there models components can be
developed by adding little bit effort of developers.
5.10. Component Testing tools
First Strategy
It avoids the errors wherever possible. For example a compiler or analyzing tools are
allowed to catch substantial errors statically by a safe and expressive language. A
carefully crafted language can rule out entire classes of errors.
92
Second Strategy
It makes 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.
5.11. Component assembly tools
By instantiating and connecting component instances and customizing component

resources the components are assembled.
At runtime component instances may or may not have visual representation.
So, it is useful to assume that all component instances have a visual representation at
assembly time.
Software assembly holds different aspect of assembly processes. When new version of
components released the assembly process can be repeated.
93
Summary
 Connector is a first class architectural element that reflects the specific

features of interactions among components in a system.
 A context is one of the current contextual composition approach.
 The EJB container is the layer between the bean and the system services of
the operating system or the middleware.
 CLR contexts offers a opportunity to populate the new context’s boundary
with properties, when need to construct a new context
 Black Box component framework mainly focuses on visual components.
 Directory objects is the one of the characteristics of Black Box.
94
1. What is meant by ADT?

2. What is the benefit of using inversion of control to the developers in Component
based application framework?
3. What is Communication intercepting?
4. Define Contexts.
5. What is EJB container?
6. Define SOAP and XML.
7. Define Black box component framework.
8. How does object activation work in COM?
9. Write the Characteristics of Black Box
10. Define Connector Architecture.
1. What is ATL? Explain in detail the steps in building and testing a COM
component using ATL.
2. Explain the following concepts with an example:
(i) CLR Contexts and channels (ii) Cross Development Environment.
(i) Component – oriented programming (ii) Assembly and Testing tools.
4. How to create a COM object? Explain with an example.

(i) Component design and implementation tools (ii) Component testing tools.
95

CBT1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CBT1

Uploaded by

Copyright:

Available Formats

COMPONENT BASED TECHNOLOGY

RAJA COLLEGE OF ENGINEERING & TECHNOLOGY, MADURAI-20.

DEPARTMENT OF INFORMATION TECHNOLOGY

COMPONENT BASED TECHNOLOGY STUDY MATERIALS

Software component – objects – fundamental properties of component technology –

Software components are executable units of independent production, acquisition, and

1.1. Software Component

“A component is a binary unit of independent production, acquisition and deployment

1.1.2. Use of Components

 Components are the way to go because all other engineering disciplines

 Components are independent units of deployment.

1.1.3. Benefits of Components

2. Although each bought component is standardized product, the process of component

Two traditional S/W

Custom_Made S/W Standard S/W

Development from Scratch Bought and Parameterized

1.1.4. Characteristics of Components

 Unit of independent deployment

From the above characterization, the following definition can be formed.

“A software component is a unit of compostio0n with contractually specified interfaces

1.1.5. Important Aspects of Components

 Independent deployment: E.g. Executable, Shared library, .class file etc.

1.2.1. Properties of Objects

An object is a unit of instantiation. So it cannot be partially instantiated. As objects are

1.2.2. Prototype Object

1.2.3. Component and Objects

1.3. Fundamental Properties of Component Technology

In traditional software engineering process, module development and testing is followed

iii. Safety Measurements

Abstract Data Type

Modularity is a prerequisite for component technology. But components need to be

An interface is a strongly-typed group of semantically-related functions, also called

Components can be specified separate from interfaces and their specifications.

1.5.1. Attributes of Interfaces

 An interface is not a class

 An interface is not an object

 Interfaces are strongly typed

 Interfaces are immutable

1.5.2. Direct and Indirect interfaces

Example of direct and indirect interfaces

Word processing Component Grammar checking component

Word processor Grammar Checker

Text Services Mediator Component

1.6.1. Callbacks are,

 A feature in library to handle asynchronous events.

 Has to be registered with library

Client Other Party Library

Clients installs callback

Third party calls library

Library invokes callback

Call back queries library

1.6.2. Need of Callback

 Validity of the library states is specified as part of contract.

1.6.3. A Directory Service

The simple directory service interface is grouped into two parts.

 The first part support

 The second part supports registration and unregistration of callbacks. Registered

1.7. Component Architecture

1.7.1. The benefits of components architecture are

a. Interaction between components and their environment is regulated.

1.7.2. Roles of an Architecture

1.7.3. Key Terms in Component Architecture

i. A set of platform decisions