Software Components:

Components are deployable units that provide a business service to their clients.

• Each component provides an interface in the form of operations, properties and

events

• Components can be developed in any language such as JAVA,C++,VB

• Components are frequently organized into application frameworks for vertical

domains

• Component models such as Active X and EJB standardize communication and

allow for prebuilt purchased components

Components Characteristics

Properties Operations Reusability

Shareable Events Distributable

Deployable Self Containment Self Description

Components are operation independent of

• Hardware

• The underlying operating system

• Their Application Server

• The network protocol they use

Component services can be used as a part of business logic of other components. If

multiple clients are using a component simultaneously, the component will provide the

same quality of service to all the clients

Components should provide services to clients running locally or remotely. Components

should only contain the code necessary to implement their services. Infrastructure

services should be injected by the execution environment. Standard infrastructure

services include

• Directory Services

• Distributed transaction management

• Security management

• Concurrent access management

• Persistence management

• Resource pooling (e.g. DB connections)

• Administration interface

• Load Balancing

• Fault tolerance

An application server provides the infrastructure and services to run

components/applications.

Modules:

The module will provide students with a knowledge and understanding of current and

emerging component technologies. The module is focused on two major themes: Object-

Oriented Middleware (OOM) and Message-Oriented Middleware (MOM). In the first

theme we examine the evolution of object-oriented programming into (distributed)

component models such as The Common Object Request Broker Architecture (CORBA),

The Component Object Model (COM), Java Remote Method Invocation (RMI) and Java

Beans. The common underlying requirements of these systems will be studied in detail

such as naming and binding issues and marshalling and un-marshalling of data. The

second theme will explore the emerging field of Message-Oriented Middleware with an

in-depth study into current MOM technologies such as Java Messaging System (JMS).In

their work on Modular Smalltalk [5], Allen Wirfs-Brock and Brian Wilkerson describe

the essential features of modules:

Modules are program units that manage the visibility and accessibility of names...

A module typically groups a set of class definitions and objects to implement some

service or abstraction. A module will frequently be the unit of division of responsibility

within a programming team....

A module provides an independent naming environment that is separate from other

modules within the program....

Modules support team engineering by providing isolated name spaces...

While providing many potential improvements to Smalltalk, the Modular Smalltalk

system does not implement modules as first-class objects. Like many other programming

systems, the Modular Smalltalk system uses modules only for organizational purposes.

This article proposes a different view of modules as a special kind of Smalltalk class.

Modules for Smalltalk

The definition of a normal Smalltalk class includes a reference to a superclass, the name

of the new subclass, and the names of any new instance and class variables added by the

new subclass. Class variables are shared by all the instances of a class, and are visible to

all the methods of the class and its subclasses, if any.

In addition, the new subclass can provide its methods with access to named objects that

are shared on a subscription basis. Certain names in the Smalltalk system dictionary are

bound to global pool dictionaries that contain these sharable named objects. The new

subclass can subscribe to these objects by including selected global names in its list of

pool dictionaries. For example, a File class might be defined using the following

message:

Object subclass: #File

instanceVariableNames: 'directory fileId name'

classVariableNames: 'PageSize'

poolDictionaries: 'CharacterConstants'!

Modules may be added to Smalltalk in a relatively straightforward manner. The details of

how this can be done are presented in a later section. For now, we can say that each

module is a class that contains a name space, called its domain, instead of simply a pool

of class variables.

Their are several new messages for defining modules and the private classes contained in

their domains. The definition of a module for managing an inventory might use the

following message:

Object moduleSubclass: #InventoryManager

instanceVariableNames: ''

classVariableNames: ''

poolDictionaries: ''!

A new private class can be added to the domain of the InventoryManager class using the

message:

Object subclass: #InventoryItem in: InventoryManager

instanceVariableNames: 'partNumber partName quantity'

classVariableNames: ''

poolDictionaries: ''!

In order to add a new private subclass of InventoryItem, we send the name of the private

class (#InventoryItem) as a message to the InventoryManager module:

InventoryManager InventoryItem subclass: #FloorItem

instanceVariableNames: 'storeLocation'

classVariableNames: ''

poolDictionaries: ''!

The issues involved in this breaking of the module encapsulation will be considered

further in a later section.

Modules can be used to create nested subsystems. The following message creates a

nested module for managing the accounts in the InventoryManager module class.

Object moduleSubclass: #AccountManager in: InventoryManager

instanceVariableNames: ''

classVariableNames: ''

poolDictionaries: ''!

Figure 1 depicts the structural relationships between the classes in the InventoryManager

module. Note that the graphic design notation of OMT [3] has been extended slightly to

show what classes are encapsulated inside a module class. The rounded rectangles

represent module domains. Note that the Smalltalk system dictionary is also considered

to be the system domain.

Encapsulating Private

Behavior

Modules provide three ways of

encapsulating private behavior, all of which are based on their ability to encapsulate

private classes:

• Class Groups (Systems)

• Baseline Class Extensions

• Private Methods

Ada encourages the division of code into separate modules called packages. Each

package can contain any combination of items.

Some of the benefits of using packages are:

• package contents are placed in a separate namespace, preventing naming

collisions,

• implementation details of the package can be hidden from the programmer

(information hiding),

• object orientation requires defining a type and its primitive subprograms within a

package, and

• packages can be separately compiled.

Some of the more common package usages are:

• a group of related subprograms along with their shared data, with the data not

visible outside the package,

• one or more data types along with subprograms for manipulating those data types,

and

• a generic package that can be instantiated under varying conditions.

Interfaces:

• a unit is a source code file

• a module (UML and Java package) is a directory of source files, probably

with it's own build script

• a component is a run-time, or at least install-time, thing, generated by a build

process

An individual component is a software package or a module that encapsulates a set of

related functions (or data).

All system processes are placed into separate components so that all of the data and

functions inside each component are semantically related (just as with the contents of

classes). Because of this principle, it is often said that components are modular and

cohesive.

With regard to system-wide co-ordination, components communicate with each other via

interfaces. When a component offers services to the rest of the system, it adopts a

provided interface which specifies the services that can be utilized by other components

and how. This interface can be seen as a signature of the component - the client does not

need to know about the inner workings of the component (implementation) in order to

make use of it. This principle results in components referred to as encapsulated. The

UML illustrations within this article represent provided interfaces by a lollipop-symbol

attached to the outer edge of the component.

However when a component needs to use another component in order to function, it

adopts a used interface which specifies the services that it needs. In the UML illustrations

in this article, used interfaces are represented by an open socket symbol attached to the

outer edge of the component.

An interface is hence a type definition; anywhere an object can be exchanged (in a

function or method call) the type of the object to be exchanged can be defined in terms of

an interface instead of a specific class.

Networked computers are finding their way into a broader range of environments, from

corporate offices to schools, homes, and shirt pockets. This new computing model fosters

the development of distributed software components that communicate with one another

across the underlying networked infrastructure. A distributed software component can be

plugged into distributed applications that may not have existed when it was created. The

intention is that many developers will reuse distributed software components to build new

systems.

An interface definition language usually is used to describe a distributed software

component's interface. However, a notable limitation of current IDLs is that they

generally only describe the names and type signatures of the component's attributes and

operations. Current IDLs don't formally specify the behavior of the software component's

operations. To help solve these problems, the authors have developed Biscotti (behavioral

specification of distributed software component interfaces), a Java extension that

enhances Java remote method invocation interfaces with Eiffel-style preconditions,

postconditions, and invariants.

The software components can represent standard parts designed particularly with regard

to their reuse and their closed functionality published by their contractually specified

interfaces.

Contractually specified interfaces can be clear descriptions of the behavior required, on

the one hand, as well as the offered behavior of software components, on the other hand.

Contractually specified interfaces therefore can reduce the interconnection of the system.

Thus, software components can be developed, maintained, installed, and combined

independently from one another.

Callbacks:

Modern software systems are often developed via composition of independent

components with well-defined interfaces and (formal) behavior specification of some

sort. When reliability of a software system built from components is a critical issue,

formal verification such as program model checking becomes a necessity. Since model

checking of the whole complex ("real-life") system at a time is prone to state explosion,

compositional methods have to be used. A basic idea of compositional model checking is

the checking of (local) properties of isolated components and inferring (global) properties

of the whole system fromthe local properties. This way, state explosion is partially

addressed, since a single isolated component typically triggers a smaller state space

compared to the whole system.

A popular approach to compositional model checking of component applications is based

on the assume-guarantee paradigm: For each component subject to checking, an

assumption is stated on the behavior of the component's environment (e.g. the rest of a

particular component application); similarly, the "guarantee" are the properties to hold if

the component works properly in the assumed environment (e.g. absence of concurrency

errors and compliance with behavior specification). Thus, a successful model checking of

the component against the properties under the specific assumption guarantees the

component to work properly when put into an environment modeled by the assumption.

Specific to program model checkers such as Java PathFinder (JPF) is that they check

only complete programs (featuring main()).

Thus checking of an isolated component (its implementation, i.e. for instance of its Java

code) is not directly possible, since also its environment has to be provided in the form of

a program (code). Thus, program model checking of a primitive component is associated

with the problem of missing environment [14]. A typical solution to it in case of JPF is to

construct an "artificial" environment (Java code) from an assumption formed as a

behavior model as in, where the behavior model is based on LTS defined either directly,

or in the formalism of behavior protocols. Then, JPF is applied to the complete program

composed of the component and environment.

Directory Services

A directory service is the software system that stores, organizes and provides access to

information in a directory. In software engineering, a directory is a map of the differences

between names and values. It allows the lookup of values given a name, similar to a

dictionary. As a word in a dictionary may have multiple definitions, in a directory, a

name may be associated with multiple, different pieces of information. Likewise, as a

word may have different parts of speech and different definitions, a name in a directory

may have many different types of data.

Directories may be very narrow in scope, supporting only a small set of node types and

data types, or they may be very broad, supporting an arbitrary or extensible set of types.

In a telephone directory, the nodes are names and the data items are telephone numbers.

In the DNS the nodes are domain names and the data items are IP addresses (and alias,

mail server names, etc.). In a directory used by a network operating system, the nodes

represent resources that are managed by the OS, including users, computers, printers and

other shared resources. Many different directory services have been used since the advent

of the Internet but this article focuses mainly on those that have descended from the

X.500 directory service.

In some cases, an existing software component version is a prerequisite for a software

component version because, for example, you need to reuse part of the software. In this

case, the software component version upon which the other software component version

depends is referred to as the underlying software component version. The software

component version is only complete with the underlying software component version

upon which it is based.

You define the corresponding software dependency (“based-on” relationship) in the

System Landscape Directory (see: Software Dependencies). Objects of an underlying

software component version are displayed in two places in the navigation area of the

Enterprise Services Repository (Objects tab page). ...

1. In the Basis Objects subtree of the software component version that is based

on the underlying software component version.

2. In the subtree of the underlying software component version (at the same

level as all other software component versions).

This relationship is shown in the figure. In the case illustrated, the software component

version Based-On Component 1.0 is based on the software component version Basis 1.0.

Component Architecture:

What is a component framework?

• A component framework defines a set of abstract interactions that define

protocols by which components communicate.

• Is also defines the packaging for components so that they can be instantiated and

composed into legal configurations by third-party binding.

• Three most used types of component frameworks on the market today:

• Second tired component framework

• Contextual component framework

• Visual component frameworks

Tiered component architectures

• Hierarchal decomposition

• Layering

• Key terms

– Component

– Atomic Component

– Module

– Resource

• Importance of Layers and hierarchal decomposition on today’s component system

• Layers can contain components needed perform a certain service.

• All the layers stacked on top of each other form an architecture.

• Mastering the complexity of a layered architecture by adding the layered

architecture on top of another layered architecture.

• Meta-architecture

• A meta-architecture is forms a layer beneath the component architecture

• In this case layers are called tiers

• First tier is the component architecture

• Second Tier is the meta-architecture (component framework)

• Definition of a component framework

• A component framework is a dedicated and focused architecture usually around a

few key mechanisms, and a fixed set of policies for mechanisms at the component

level.

• The need for a third tier. (another meta-architecture)

• A component framework can become an Island (can communicate only with

instances of specified components)

• Model a component framework as a component.

• Can then be plugged into another architecture.

• The third tier can enable these component framework to communicate

Components and Middleware

Middleware is a computer software that connects software components or applications.

The software consists of a set of services that allows multiple processes running on one

or more machines to interact. This technology evolved to provide for interoperability in

support of the move to coherent distributed architectures, which are most often used to

support and simplify complex, distributed applications. It includes web servers,

application servers, and similar tools that support application development and delivery.

Middleware is especially integral to modern information technology based on XML,

SOAP, Web services, and service-oriented architecture.

Middleware sits "in the middle" between application software that may be working on

different operating systems. It is similar to the middle layer of a three-tier single system

architecture, except that it is stretched across multiple systems or applications. Examples

include EAI software, telecommunications software, transaction monitors, and

messaging-and-queuing software.

The distinction between operating system and middleware functionality is, to some

extent, arbitrary. While core kernel functionality can only be provided by the operating

system itself, some functionality previously provided by separately sold middleware is

now integrated in operating systems. A typical example is the TCP/IP stack for

telecommunications, nowadays included in virtually every operating system.

Types of middleware

• Remote Procedure Call — Client makes calls to procedures running on remote

systems. Can be asynchronous or synchronous.

• Message Oriented Middleware — Messages sent to the client are collected and

stored until they are acted upon, while the client continues with other processing.

• Object Request Broker — This type of middleware makes it possible for

applications to send objects and request services in an object-oriented system.

• SQL-oriented Data Access — middleware between applications and database

servers.

• Embedded Middleware — communication services and integration interface

software/firmware that operates between embedded applications and the real time

operating system.

Functions of Middleware

In all of the above situations, applications use intermediate software that resides on top of

the operating systems and communication protocols to perform the following functions :

• Hiding distribution, i.e. the fact that an application is usually made up of many

interconnected parts running in distributed locations;

• Hiding the heterogeneity of the various hardware components, operating

systems and communication protocols;

• Providing uniform, standard, high-level interfaces to the application developers

and integrators, so that applications can be easily composed, reused, ported, and

made to interoperate;

• Supplying a set of common services to perform various general purpose

functions, in order to avoid duplicating efforts and to facilitate collaboration

between applications.

THREADS

Introduction:

Threading is a facility to allow multiple activities to coexist within a single process. Most

modern operating systems support threads and Java is the first mainstream programming

language to explicitly include threading within the language itself, rather than treating

threading as a facility of the underlying operating system. Threads are sometimes referred

to as lightweight processes. Like processes, threads are independent, concurrent paths of

execution through a program, and each thread has its own stack, its own program counter,

and its own local variables. A process can support multiple threads, which appear to

execute simultaneously and asynchronously to each other.

Every Java program uses threads

Every Java program has at least one thread -- the main thread. When a Java program

starts, the JVM creates the main thread and calls the program's main() method within that

thread. The JVM also creates other threads that are mostly invisible to you -- for

example, threads associated with garbage collection, object finalization, and other JVM

housekeeping tasks. Other facilities create threads too, such as the AWT (Abstract

Windowing Toolkit) or Swing UI toolkits, servlet containers, application servers, and

RMI (Remote Method Invocation).

Why use threads?

Some of the reasons for using threads are that they can help to:

• �Make the UI more responsive

• Take advantage of multiprocessor systems

• Simplify program logic when there are multiple independent entities

• Perform asynchronous (Perform blocking I/O without blocking the entire

program) or background processing

Creating threads

In Java, an object of the Thread class can represent a thread. Thread can be implemented

through any one of two ways:

• Extending the java.lang.Thread Class

• Implementing the java.lang.Runnable Interface

I. Extending the java.lang.Thread Class

For creating a thread a class have to extend the Thread Class. For creating a thread by

this procedure you have to follow these steps:

1. Extend the java.lang.Thread Class.

2. Override the run( ) method in the subclass from the Thread class to define the

code executed by the thread.

3. Create an instance of this subclass. This subclass may call a Thread class

constructor by subclass constructor.

4. Invoke the start( ) method on the instance of the class to make the thread eligible

for running.

The following program demonstrates a single thread creation extending the

"Thread" Class:

class MyThread extends Thread{

String s=null;

MyThread(String s1){

s=s1;

start(); }

public void run(){

System .out.println(s); } }

public class RunThread{

public static void main(String args[]){

MyThread m1=new MyThread("Thread started....");

} }

Output:

C:\j2se6\thread>javac RunThread.java

C:\j2se6\thread>java RunThread

Thread started....

II. Implementing the java.lang.Runnable Interface

The procedure for creating threads by implementing the Runnable Interface is as

follows:

1. A Class implements the Runnable Interface, override the run() method to define

the code executed by thread. An object of this class is Runnable Object.

2. Create an object of Thread Class by passing a Runnable object as argument.

3. Invoke the start( ) method on the instance of the Thread class.

The following program demonstrates the thread creation implementing the

Runnable interface:

class MyThread1 implements Runnable{

Thread t;

String s=null;

MyThread1(String s1){

s=s1;

t=new Thread(this);

t.start();}

public void run(){

System.out.println(s); }

public class RunableThread{

public static void main(String args[]){

MyThread1 m1=new MyThread1("Thread started....");

}}}

There are two reasons for implementing a Runnable interface preferable to extending

the Thread Class:

1. If you extend the Thread Class, that means that subclass cannot extend any other

Class, but if you implement Runnable interface then you can do this.

2. The class implementing the Runnable interface can avoid the full overhead of

Thread class which can be excessive.

Thread Priorities:

In Java, thread scheduler can use the thread priorities in the form of integer value to

each of its thread to determine the execution schedule of threads. Thread gets the ready-

to-run state according to their priorities. The thread scheduler provides the CPU time to

thread of highest priority during ready-to-run state. Priorities are integer values from 1

(lowest priority given by the constant Thread.MIN_PRIORITY) to 10 (highest priority

given by the constant Thread.MAX_PRIORITY). The default priority is

5(Thread.NORM_PRIORITY).

Constant Description

Thread.MIN_PRIORITY The maximum priority of any thread (an int value of 10)

Thread.MAX_PRIORITY The minimum priority of any thread (an int value of 1)

Thread.NORM_PRIORITY The normal priority of any thread (an int value of 5)

The methods that are used to set the priority of thread shown as:

setPriority() This is method is used to set the priority of thread.

getPriority() This method is used to get the priority of thread.

When a Java thread is created, it inherits its priority from the thread that created it. At

any given time, when multiple threads are ready to be executed, the runtime system

chooses the runnable thread with the highest priority for execution. In Java runtime

system, preemptive scheduling algorithm is applied. If at the execution time a thread

with a higher priority and all other threads are runnable then the runtime system chooses

the new higher priority thread for execution. On the other hand, if two threads of the

same priority are waiting to be executed by the CPU then the round-robin algorithm is

applied in which the scheduler chooses one of them to run according to their round of

time-slice.

Thread Scheduler

In the implementation of threading scheduler usually applies one of the two following

strategies:

• Preemptive scheduling – If the new thread has a higher priority then

current running thread leaves the runnable state and higher priority thread

enter to the runnable state.

• Time-Sliced (Round-Robin) Scheduling – A running thread is allowed to

be execute for the fixed time, after completion the time, current thread

indicates to the another thread to enter it in the runnable state.

States and State Transitions of Java Threads:

start

synchronized

resume

suspend

synchronize notified

suspend

wait

stop, destroy

new

When a thread is in the "New Thread" state, it is merely an empty Thread object. No

system resources have been allocated for it yet. Thus when a thread is in this state, you

suspended

runnable

running

wait for lock

wait for

notify

new

terminated

sch

edu

le

pre

-em

pt

can only start the thread or stop it. Calling any method besides start() or stop() when a

thread is in this state makes no sense and causes an IllegalThreadStateException.

Runnable

The start() method creates the system resources necessary to run the thread, schedules the

thread to run, and calls the thread's run() method. At this point the thread is in the

"Runnable" state. This state is called "Runnable" rather than "Running" because the

thread might not actually be running when it is in this state. Many computers have a

single processor, making it impossible to run all "Runnable" threads at the same time. So,

the Java runtime system must implement a scheduling scheme that shares the processor

between all "Runnable" threads. (See Thread Priority for more information about

scheduling.) However, for most purposes you can think of the "Runnable" state as simply

"Running". When a thread is running--it's "Runnable" and is the current thread--the

instructions in its run() method are executing sequentially.

Not Runnable

A thread enters the "Not Runnable" state when one of these four events occurs:

• Someone invokes its sleep() method.

• Someone invokes its suspend() method.

• The thread uses its wait() method to wait on a condition variable.

• The thread is blocking on I/O.

• If a thread has been put to sleep, then the specified number of milliseconds

must elapse.

• If a thread has been suspended, then someone must call its resume()

method.

• If a thread is waiting on a condition variable, whatever object owns the

variable must relinquish it by calling either notify() or notifyAll().

• If a thread is blocked on I/O, then the I/O must complete.

Dead

A thread can die in two ways: either from natural causes, or by being killed (stopped). A

thread dies naturally when its run()method exits normally. You can also kill a thread at

any time by calling its stop() method. The following code snippet creates and starts

myThread then puts the current thread to sleep for 10 seconds. The stop() method throws

a ThreadDeath object at the thread to kill it. Thus when a thread is killed in this manner it

dies asynchronously. The thread will die when it actually receives the ThreadDeath

exception. The stop() method causes a sudden termination of a Thread's run() method. If

the run() method performs critical or sensitive calculations, stop() may leave the program

in an inconsistent or awkward state. Normally, you should not call Thread's stop()

method but arrange for a gentler termination such as setting a flag to indicate to the run()

method that it should exit.

The isAlive() Method

A final word about thread state: the programming interface for the Thread class includes

a method called isAlive(). The isAlive() method returns true if the thread has been started

and not stopped. Thus, if the isAlive() method returns false you know that the thread is

either a "New Thread" or "Dead". If the isAlive() method returns true, you know that the

thread is either "Runnable" or "Not Runnable". You cannot differentiate between a "New

Thread" and a "Dead" thread; nor can you differentiate between a "Runnable" thread and

a "Not Runnable" thread.

Joining with threads

The Thread API contains a method for waiting for another thread to complete: the join()

method. When you call Thread.join(), the calling thread will block until the target thread

completes. Thread.join() is generally used by programs that use threads to partition large

problems into smaller ones, giving each thread a piece of the problem. The example at

the end of this section creates ten threads, starts them, then uses Thread.join() to wait for

them all to complete.

Sleeping

The Thread API includes a sleep() method, which will cause the current thread to go into

a wait state until the specified amount of time has elapsed or until the thread is

interrupted by another thread calling Thread.interrupt() on the current thread's Thread

object. When the specified time elapses, the thread again becomes runnable and goes

back onto the scheduler's queue of runnable threads.

If a thread is interrupted by a call to Thread.interrupt(), the sleeping thread will throw an

InterruptedException so that the thread will know that it was awakened by an interrupt

and won't have to check to see if the timer expired. The Thread.yield() method is like

Thread.sleep(), but instead of sleeping, it simply pauses the current thread momentarily

so that other threads can run. In most implementations, threads with lower priority will

not run when a thread of higher priority calls Thread.yield().

Threads - notify() and notifyAll() methods

• the notify() and notifyAll() methods are defined in the Object class

• they can only be used within synchronized code

• notify() wakes up a single thread which is waiting on the object's lock

• if there is more than one thread waiting, the choice is arbitrary ie there is no way

to specify which waiting thread should be re-awakened

• notifyAll() wakes up all waiting threads; the scheduler decides which one will run

• if there are no waiting threads, the notifys are forgotten

• only notifications that occur after a thread has moved to wait state will effect it;

earlier notifies are irrelevant

Daemon threads

We mentioned that a Java program exits when all of its threads have completed, but this

is not exactly correct. What about the hidden system threads, such as the garbage

collection thread and others created by the JVM? We have no way of stopping these. If

those threads are running, how does any Java program ever exit? These system threads

are called daemon threads. A Java program actually exits when all its non-daemon

threads have completed. Any thread can become a daemon thread. You can indicate a

thread is a daemon thread by calling the Thread.setDaemon() method. You might want to

use daemon threads for background threads that you create in your programs, such as

timer threads or other deferred event threads, which are only useful while there are other

non-daemon threads running.

In Java, any thread can be a Daemon thread. Daemon threads are like a service

providers for other threads or objects running in the same process as the daemon thread.

Daemon threads are used for background supporting tasks and are only needed while

normal threads are executing. If normal threads are not running and remaining threads

are daemon threads then the interpreter exits.

setDaemon(true/false) – This method is used to specify that a thread is daemon

thread.

Creating threads and starting threads are not the same

A thread doesn't actually begin to execute until another thread calls the start() method on

the Thread object for the new thread. The Thread object exists before its thread actually

starts, and it continues to exist after its thread exits. This allows you to control or obtain

information about a thread you've created, even if the thread hasn't started yet or has

already completed.

It's generally a bad idea to start() threads from within a constructor. Doing so could

expose partially constructed objects to the new thread. If an object owns a thread, then it

should provide a start() or init() method that will start the thread, rather than starting it

from the constructor.

Ending threads

A thread will end in one of three ways:

• The thread comes to the end of its run() method.

• The thread throws an Exception or Error that is not caught.

• Another thread calls one of the deprecated stop() methods. Deprecated means they

still exist, but you shouldn't use them in new code and should strive to eliminate

them in existing code.

When all the threads within a Java program complete, the program exits.

Thread Synchronization

The monitor

Java uses the monitor concept as the basis of its thread synchronization. A monitor is

an object that can block and revive threads.

Java provides a way to lock the code for a thread which is currently executing it, and

making other threads that wish to use it wait until the first thread is finished. These

other threads are placed in the waiting state. Java is not as fair as the service station

because there is no queue. Any one of the waiting threads may get the monitor next,

regardless of the order they asked for it.

The synchronized keyword

A block of code can be turned into a monitor using the keyword synchronized.

There are two ways to use synchronized

Synchronizing a whole method by adding the word synchronized as a modifier

in the method's header. This is the most common way of doing it. Many of Java's

API methods are synchronized this way. For example, public synchronized

void setLabel(String label) from the Button class. The object referenced in the

method call is the object holding the lock, in this case the Button object.

Synchronizing only a block of code within a method using the synchronized

keyword. The block of code is preceded by the keyword synchronized and an

expression which references the object holding the lock. For example, here is a

code fragment which changes all values in an array to positive and prevents any

other thread from changing any elements before the code has finished making all

the changes.

wait(), notify() and notifyAll()

The methods wait(), notify() and notifyAll() service this need. Note that all three can

only be used within synchronized code. If you try to use them outside of

synchronization you will get a compiler error. Note that these methods belong to the

Object class, not the Thread class.

public final void wait() throws InterruptedException

public final native void wait(long timeout) throws InterruptedException

wait() puts the current thread into the waiting state.

public final native void notify()

notify() looks at the threads in the waiting state, and picks one (which one is

unpredictable) and moves it to the ready state where the scheduler will decide what to

do with it. Any other threads in the waiting state remain there until notify() or

notifyAll() are called again.

public final native void notifyAll()

notifyAll() moves all the threads in the waiting state into the ready state where the

scheduler will decide when they will move to the running state. NotifyAll() is much

more commonly used than notify() because the latter could conceivably leave a thread

waiting for a very long time if it were unlucky.

Some important thread problems

• race conditions

• starvation

• deadlock

Java Beans:

• JavaBeans components are Java classes that can be easily reused and composed

together into applications.

• JavaBeans™ is a portable, platform-independent component model written in the

Java programming language. The JavaBeans architecture was built through a

collaborative industry effort and enables developers to write reusable components

in the Java programming language.

• Using JavaBeans-compliant application builder tools, you can combine these

components into applets, applications, or composite components.

• A Java Bean is a reusable software component (actually, a Java class) that can be

manipulated visually in a builder tool

• Examples of "builder tools":

� BeanBox (part of Sun's basic Beans Development Kit (BDK) - available

free from java.sun.com)

� Sun Java Workshop

� IBM VisualAge for Java

� Symantec Visual Cafe

� Borland JBuilder

JavaBean components are known as beans. Beans are dynamic in that they can be

changed or customized. Through the design mode of a builder tool, you use the property

sheet or bean customizer to customize the bean and then save (persist) your customized

beans.

JavaBeans Concepts

The JavaBeans™ architecture is based on a component model which enables

developers to create software units called components. Components are self-contained,

reusable software units that can be visually assembled into composite components,

applets, applications, and servlets using visual application builder tools. JavaBean

components are known as beans.

A set of APIs describes a component model for a particular language. The JavaBeans

API specification describes the core detailed elaboration for the JavaBeans component

architecture.

Beans are dynamic in that they can be changed or customized. Through the design

mode of a builder tool you can use the Properties window of the bean to customize the

bean and then save (persist) your beans using visual manipulation. You can select a

bean from the toolbox, drop it into a form, modify its appearance and behavior, define

its interaction with other beans, and combine it and other beans into an applet,

application, or a new bean.

The following list briefly describes key bean concepts:

• Builder tools discover a bean's features (that is, its properties, methods, and

events) by a process known as introspection. Beans support introspection in two

ways:

o By adhering to specific rules, known as design patterns, when naming bean

features. The Introspector class examines beans for these design patterns to

discover bean features. The Introspector class relies on the core reflection API.

The trail The Reflection API is an excellent place to learn about reflection.

o By explicitly providing property, method, and event information with a related

bean information class. A bean information class implements the BeanInfo

interface. A BeanInfo class explicitly lists those bean features that are to be

exposed to application builder tools.

• Properties are the appearance and behavior characteristics of a bean that can be

changed at design time. Builder tools introspect on a bean to discover its

properties and expose those properties for manipulation.

• Beans expose properties so they can be customized at design time. Customization

is supported in two ways: by using property editors, or by using more

sophisticated bean customizers.

• Beans use events to communicate with other beans. A bean that is to receive

events (a listener bean) registers with the bean that fires the event (a source bean).

Builder tools can examine a bean and determine which events that bean can fire

(send) and which it can handle (receive).

• Persistence enables beans to save and restore their state. After changing a bean's

properties, you can save the state of the bean and restore that bean at a later time

with the property changes intact. The JavaBeans architecture uses Java Object

Serialization to support persistence.

• A bean's methods are no different from Java methods, and can be called from

other beans or a scripting environment. By default all public methods are

exported.

Beans vary in functionality and purpose. You have probably met some of the following

beans in your programming practice:

• GUI (graphical user interface)

• Non-visual beans, such as a spelling checker

• Animation applet

• Spreadsheet application

Events and Connections

Manipulating Events

Event passing is the means by which components communicate with each other.

Components broadcast events, and the underlying framework delivers the events to the

components that are to be notified. The notified components usually perform some

action based on the event that took place.

The event model was designed to accommodate the JavaBeans™ architecture. To

understand how events and event handling work in the JavaBeans component model,

you must understand the concepts of events, listeners, and sources. To refresh your

knowledge in these areas, read the Writing Event Listeners lesson of the Swing

tutorial.

The event model that is used by the JavaBeans architecture is a delegation model. This

model is composed of three main parts: sources, events, and listeners.

The source of an event is the object that originates or fires the event. The source must

define the events it will fire, as well as the methods for registering listeners of those

events. A listener is an object that indicates that it is to be notified of events of a

particular type. Listeners register for events using the methods defined by the sources

of those events.

From the Properties lesson you discovered two event listeners. The

PropertyChangeListener(in the API reference documentation) interface provides a

notification whenever a bound property value is changed and the

VetoableChangeListener(in the API reference documentation) creates a notification

whenever a bean changes a constrained property value.

Simple Event Example

This example represents an application that performs an action when a button is clicked.

Button components are defined as sources of an event type called ActionEvent.

Listeners of events of this type must register for these events using the

addActionListener method.

Therefore, the addActionListener method is used to register the ButtonHandler

object as a listener of the ActionEvent event that is fired by the button.

In addition, according to the requirements of the ActionListener class, you must

define an actionPerformed method, which is the method that is called when the button

is clicked.

import java.awt.event.ActionEvent;

import java.awt.event.ActionListener;

import javax.swing.JTextArea;

import java.awt.BorderLayout;

import javax.swing.JButton;

import javax.swing.JFrame;

import javax.swing.WindowConstants;

public class ButtonHandler implements ActionListener {

/**

* Component that will contain messages about

* events generated.

*/

private JTextArea output;

/**

* Creates an ActionListener that will put messages in

* JTextArea everytime event received.

*/

public ButtonHandler( JTextArea output )

{

this.output = output;

}

/**

* When receives action event notification, appends

* message to the JTextArea passed into the constructor.

*/

public void actionPerformed( ActionEvent event )

{

this.output.append( "Action occurred: " + event + '\n' );

}

}

class ActionTester {

public static void main(String args[]) {

JFrame frame = new JFrame( "Button Handler" );

JTextArea area = new JTextArea( 6, 80 );

JButton button = new JButton( "Fire Event" );

button.addActionListener( new ButtonHandler( area ) );

frame.add( button, BorderLayout.NORTH );

frame.add( area, BorderLayout.CENTER );

frame.pack();

frame.setDefaultCloseOperation(

WindowConstants.DISPOSE_ON_CLOSE );

frame.setLocationRelativeTo( null );

frame.setVisible( true );

}

}

Bean Properties

A bean property is a named attribute of a bean that can affect its behavior or

appearance. Examples of bean properties include color, label, font, font size, and

display size. The JavaBeans specification defines the following types of bean

properties:

Simple – A bean property with a single value whose changes are independent of

changes in any other property. To add simple properties to a bean, add appropriate

getXXX and setXXX methods (or isXXX and setXXX methods for a boolean property).

To add simple properties to a bean, add appropriate getXXX and setXXX methods (or

isXXX and setXXX methods for a boolean property). The names of these methods follow

specific rules called design patterns. These design pattern-based method names provide

the following features:

• Discover a bean's properties

• Determine the properties' read/write attributes

• Determine the properties' types

• Locate the appropriate property editor for each property type

• Display the properties (usually in the Properties window)

• Alter the properties (at design time)

Indexed – A bean property that supports a range of values instead of a single value.

An indexed property is an array of properties or objects that supports a range of values

and enables the accessor to specify an element of a property to read or write. Indexed

properties are specified by the following methods:

//Methods to access individual values

public PropertyElement getPropertyName(int index)

public void setPropertyName(int index, PropertyElement element)

//Methods to access the entire indexed property array

public PropertyElement[] getPropertyName()

public void setPropertyName(PropertyElement element[])

• Note that the distinction between the get and set methods for indexed properties is

subtle. The get method either has an argument that is the array index of the

property, or returns an array. The set method either has two arguments, namely an

integer array index and the property element object that is being set, or has the

entire array as an argument.

Bound – A bean property for which a change to the property results in a notification

being sent to some other bean. Bound properties support the

PropertyChangeListener class.

Sometimes when a Bean property changes, another object might need 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.

The accessor methods for a bound property are defined in the same way as those for

simple properties. However, you also need to provide the event listener registration

methods forPropertyChangeListener classes and fire a PropertyChangeEvent event to

the PropertyChangeListener objects by calling their propertyChange methods

The convenience PropertyChangeSupport class enables your bean to implement these

methods. Your bean can inherit changes from the PropertyChangeSupportclass, or use it

as an inner class.

In order to listen for property changes, an object must be able to add and remove itself

from the listener list on the bean containing the bound property. It must also be able to

respond to the event notification method that signals a property change.

The PropertyChangeEvent class encapsulates property change information, and is sent

from the property change event source to each object in the property change listener list

with the propertyChange method.

Implementing Bound Property Support Within a Bean

To implement a bound property in your application, follow these steps:

• Import the java.beans package. This gives you access to the

PropertyChangeSupport class.

• Instantiate a PropertyChangeSupport object. This object maintains the property

change listener list and fires property change events. You can also make your

class a PropertyChangeSupport subclass.

• Implement methods to maintain the property change listener list. Since a

PropertyChangeSupport subclass implements these methods, you merely wrap

calls to the property-change support object's methods.

• Modify a property's set method to fire a property change event when the property

is changed.

Constrained – A bean property for which a change to the property results in validation

by another bean. The other bean may reject the change if it is not appropriate. A bean

property is constrained if the bean supports the VetoableChangeListener and

PropertyChangeEvent classes, and if the set method for this property throws a

PropertyVetoException.

Constrained properties are more complicated than bound properties because they also

support property change listeners which happen to be vetoers. The following operations

in the setXXX method for the constrained property must be implemented in this order:

1. Save the old value in case the change is vetoed.

2. Notify listeners of the new proposed value, allowing them to veto the change.

3. If no listener vetoes the change (no exception is thrown), set the property to the new value.

The accessor methods for a constrained property are defined in the same way as those

for simple properties, with the addition that the setXXX method throws a

PropertyVetoException exception. The syntax is as follows:

public void setPropertyName(PropertyType pt)

throws PropertyVetoException {code}

Handling Vetoes

If a registered listener vetoes a proposed property change by throwing a

PropertyVetoException exception, the source bean with the constrained property is

responsible for the following actions:

1. Catching exceptions.

2. Reverting to the old value for the property.

3. Issuing a new VetoableChangeListener.vetoableChange call to all listeners to

report the reversion.

The VetoableChangeListener class throws a PropertyVetoException and handles the

PropertyChangeEvent event fired by the bean with the constrained property. The

VetoableChangeSupport provides the following operations:

1. Keeping track of VetoableChangeListener objects.

2. Issuing the vetoableChange method on all registered listeners.

3. Catching any vetoes (exceptions) thrown by listeners.

4. Informing all listeners of a veto by calling vetoableChange again, but with

the old property value as the proposed "new" value.

Bean properties can also be classified as follows:

Writable – A bean property that can be changed

� Standard

� Expert

� Preferred

Read Only – A bean property that cannot be changed.

• Hidden – A bean property that can be changed. However, these properties are not

disclosed with the BeanInfo class.

• A Javabean is just a Java class with the following requirements:

i) It has a public no-args constructor

ii) It has 'set' and 'get' methods for its properties.

iii) It may have any general functions.

iv) If required it must be Serializable.

Introspection

Introspection is the automatic process of analyzing a bean's design patterns to reveal the

bean's properties, events, and methods. This process controls the publishing and

discovery of bean operations and properties. This lesson explains the purpose of

introspection, introduces the Introspection API, and gives an example of introspection

code.

Purpose of Introspection

The way in which introspection is implemented provides great advantages, including:

Portability - Everything is done in the Java platform, so you can write components once,

reuse them everywhere. There are no extra specification files that need to be maintained

independently from your component code. There are no platform-specific issues to

contend with. Your component is not tied to one component model or one proprietary

platform. You get all the advantages of the evolving Java APIs, while maintaining the

portability of your components.

Reuse - By following the JavaBeans design conventions, implementing the appropriate

interfaces, and extending the appropriate classes, you provide your component with reuse

potential that possibly exceeds your expectations.

Introspection API

The JavaBeans API architecture supplies a set of classes and interfaces to provide

introspection.

The BeanInfo interface of the java.beans package defines a set of methods that allow

bean implementors to provide explicit information about their beans. By specifying

BeanInfo for a bean component, a developer can hide methods, specify an icon for the

toolbox, provide descriptive names for properties, define which properties are bound

properties, and much more.

The getBeanInfo(beanName) of the Introspector class can be used by builder tools and

other automated environments to provide detailed information about a bean. The

getBeanInfo method relies on the naming conventions for the bean's properties, events,

and methods. A call to getBeanInfo results in the introspection process analyzing the

bean’s classes and superclasses.

The Introspector class provides descriptor classes with information about properties,

events, and methods of a bean. Methods of this class locate any descriptor information

that has been explicitly supplied by the developer through BeanInfo classes. Then the

Introspector class applies the naming conventions to determine what properties the bean

has, the events to which it can listen, and those which it can send.

The following figure represents a hierarchy of the FeatureDescriptor classes:

Each class represented in this group describes a particular attribute of the bean. For

example, the isBound method of the PropertyDescriptor class indicates whether a

PropertyChangeEvent event is fired when the value of this property changes.

JAR Files

The JavaTM Archive (JAR) file format enables you to bundle multiple files into a single

archive file. Typically a JAR file contains the class files and auxiliary resources

associated with applets and applications. The JAR file format provides many benefits:

• Security: You can digitally sign the contents of a JAR file. Users who recognize your

signature can then optionally grant your software security privileges it wouldn't

otherwise have.

• Decreased download time: If your applet is bundled in a JAR file, the applet's class

files and associated resources can be downloaded to a browser in a single HTTP

transaction without the need for opening a new connection for each file.

• Compression: The JAR format allows you to compress your files for efficient

storage.

• Packaging for extensions: The extensions framework provides a means by which

you can add functionality to the Java core platform, and the JAR file format defines

the packaging for extensions. Java 3D and JavaMail are examples of extensions

developed by SunTM. By using the JAR file format, you can turn your software into

extensions as well.

• Package Sealing: Packages stored in JAR files can be optionally sealed so that the

package can enforce version consistency. Sealing a package within a JAR file means

that all classes defined in that package must be found in the same JAR file.

• Package Versioning: A JAR file can hold data about the files it contains, such as

vendor and version information.

• Portability: The mechanism for handling JAR files is a standard part of the Java

platform's core API.

Using JAR Files: The Basics

JAR files are packaged with the ZIP file format, so you can use them for tasks such as

lossless data compression, archiving, decompression, and archive unpacking. These tasks

are among the most common uses of JAR files, and you can realize many JAR file

benefits using only these basic features.

To perform basic tasks with JAR files, you use the Java Archive Tool provided as part

of the Java Development Kit. Because the Java Archive tool is invoked by using the jar

command, this tutorial refers to it as 'the Jar tool'. As a synopsis and preview of some of

the topics to be covered in this section, the following table summarizes common JAR

file operations:

Creating a JAR File

The basic format of the command for creating a JAR file is:

jar cf jar-file input-file(s)

The options and arguments used in this command are:

• The c option indicates that you want to create a JAR file.

• The f option indicates that you want the output to go to a file rather than to stdout.

• jar-file is the name that you want the resulting JAR file to have. You can use any

filename for a JAR file. By convention, JAR filenames are given a .jar extension,

though this is not required.

• The input-file(s) argument is a space-separated list of one or more files that you

want to include in your JAR file. The input-file(s) argument can contain the

wildcard * symbol. If any of the "input-files" are directories, the contents of those

directories are added to the JAR archive recursively.

This command will generate a compressed JAR file and place it in the current directory.

The command will also generate a default manifest file for the JAR archive. The

metadata in the JAR file, such as the entry names, comments, and contents of the

manifest, must be encoded in UTF8.

Viewing the Contents of a JAR File

The basic format of the command for viewing the contents of a JAR file is:

jar tf jar-file

Let's look at the options and argument used in this command:

• The t option indicates that you want to view the table of contents of the JAR file.

• The f option indicates that the JAR file whose contents are to be viewed is specified

on the command line.

• The jar-file argument is the path and name of the JAR file whose contents you

want to view.

This command will display the JAR file's table of contents to stdout.

Extracting the Contents of a JAR File

The basic command to use for extracting the contents of a JAR file is:

jar xf jar-file [archived-file(s)]

Let's look at the options and arguments in this command:

• The x option indicates that you want to extract files from the JAR archive.

• The f options indicates that the JAR file from which files are to be extracted is

specified on the command line, rather than through stdin.

• The jar-file argument is the filename (or path and filename) of the JAR file from

which to extract files.

• archived-file(s) is an optional argument consisting of a space-separated list of

the files to be extracted from the archive. If this argument is not present, the Jar tool

will extract all the files in the archive.

When extracting files, the Jar tool makes copies of the desired files and writes them to the

current directory, reproducing the directory structure that the files have in the archive.

The original JAR file remains unchanged.

Updating a JAR File

The Jar tool provides a u option which you can use to update the contents of an existing

JAR file by modifying its manifest or by adding files. The basic command for adding

files has this format:

jar uf jar-file input-file(s)

In this command:

• The u option indicates that you want to update an existing JAR file.

• The f option indicates that the JAR file to update is specified on the command line.

• jar-file is the existing JAR file that's to be updated.

• input-file(s) is a space-deliminated list of one or more files that you want to

add to the Jar file.

Any files already in the archive having the same pathname as a file being added will be

overwritten.

Working with Manifest Files: The Basics

JAR files support a wide range of functionality, including electronic signing, version

control, package sealing, and others. What gives a JAR file this versatility? The answer is

the JAR file's manifest. The manifest is a special file that can contain information about

the files packaged in a JAR file. By tailoring this "meta" information that the manifest

contains, you enable the JAR file to serve a variety of purposes.

Understanding the Default Manifest

When we create a JAR file, it automatically receives a default manifest file. There can be

only one manifest file in an archive, and it always has the pathname

META-INF/MANIFEST.MF

When we create a JAR file, the default manifest file simply contains the following:

Manifest-Version: 1.0

Created-By: 1.6.0 (Sun Microsystems Inc.)

These lines show that a manifest's entries take the form of "header: value" pairs. The

name of a header is separated from its value by a colon. The default manifest conforms

to version 1.0 of the manifest specification and was created by the 1.6.0 version of the

JDK.

The manifest can also contain information about the other files that are packaged in the

archive. Exactly what file information should be recorded in the manifest depends on

how you intend to use the JAR file. The default manifest makes no assumptions about

what information it should record about other files. Digest information is not included in

the default manifest.

Modifying a Manifest File

We use the m command-line option to add custom information to the manifest during

creation of a JAR file. This section describes the m option.

The Jar tool automatically puts a default manifest with the pathname META-

INF/MANIFEST.MF into any JAR file we create. We can enable special JAR file

functionality, such as package sealing, by modifying the default manifest. Typically,

modifying the default manifest involves adding special-purpose headers to the manifest

that allow the JAR file to perform a particular desired function.

To modify the manifest, you must first prepare a text file containing the information we

wish to add to the manifest. We then use the Jar tool's m option to add the information in

our file to the manifest.

The text file from which you are creating the manifest must end with a new line or

carriage return. The last line will not be parsed properly if it does not end with a new

line or carriage return. The basic command has this format:

jar cfm jar-file manifest-addition input-file(s)

Let's look at the options and arguments used in this command:

• The c option indicates that you want to create a JAR file.

• The m option indicates that you want to merge information from an existing file into

the manifest file of the JAR file you're creating.

• The f option indicates that you want the output to go to a file (the JAR file you're

creating) rather than to standard output.

• manifest-addition is the name (or path and name) of the existing text file whose

contents you want to add to the contents of JAR file's manifest.

• jar-file is the name that you want the resulting JAR file to have.

• The input-file(s) argument is a space-separated list of one or more files that you

want to be placed in your JAR file.

The m and f options must be in the same order as the corresponding arguments. The

contents of the manifest must be encoded in UTF8.

The Reflection API

Uses of Reflection

Reflection is commonly used by programs which require the ability to examine or

modify the runtime behavior of applications running in the Java virtual machine. This

is a relatively advanced feature and should be used only by developers who have a

strong grasp of the fundamentals of the language. With that caveat in mind, reflection

is a powerful technique and can enable applications to perform operations which would

otherwise be impossible.

Java's Reflection API's makes it possible to inspect classes, interfaces, fields and

methods at runtime, without knowing the names of the classes, methods etc. at compile

time. It is also possible to instantiate new objects, invoke methods and get/set field

values using reflection.

Java Reflection is a quite powerful and can be very useful. For instance, when mapping

objects to tables in a database at runtime, like Butterfly Persistence does. Or, when

mapping the statements in a script language to method calls on real objects at runtime,

like Butterfly Container does when parsing its configuration scripts.

Reflection is a feature in the Java programming language. It allows an executing Java

program to examine or "introspect" upon itself, and manipulate internal properties of the

program. For example, it's possible for a Java class to obtain the names of all its members

and display them.

The ability to examine and manipulate a Java class from within itself may not sound like

very much, but in other programming languages this feature simply doesn't exist. For

example, there is no way in a Pascal, C, or C++ program to obtain information about the

functions defined within that program.

One tangible use of reflection is in JavaBeans, where software components can be

manipulated visually via a builder tool. The tool uses reflection to obtain the properties of

Java components (classes) as they are dynamically loaded.

Extensibility Features

An application may make use of external, user-defined classes by creating instances of

extensibility objects using their fully-qualified names.

Class Browsers and Visual Development Environments

A class browser needs to be able to enumerate the members of classes. Visual

development environments can benefit from making use of type information available

in reflection to aid the developer in writing correct code.

Debuggers and Test Tools

Debuggers need to be able to examine private members on classes. Test harnesses can

make use of reflection to systematically call a discoverable set APIs defined on a class,

to insure a high level of code coverage in a test suite.

Drawbacks of Reflection

Reflection is powerful, but should not be used indiscriminately. If it is possible to

perform an operation without using reflection, then it is preferable to avoid using it. The

following concerns should be kept in mind when accessing code via reflection.

Performance Overhead

Because reflection involves types that are dynamically resolved, certain Java virtual

machine optimizations can not be performed. Consequently, reflective operations have

slower performance than their non-reflective counterparts, and should be avoided in

sections of code which are called frequently in performance-sensitive applications.

Security Restrictions

Reflection requires a runtime permission which may not be present when running under

a security manager. This is in an important consideration for code which has to run in a

restricted security context, such as in an Applet.

Exposure of Internals

Since reflection allows code to perform operations that would be illegal in non-

reflective code, such as accessing private fields and methods, the use of reflection can

result in unexpected side-effects, which may render code dysfunctional and may

destroy portability. Reflective code breaks abstractions and therefore may change

behavior with upgrades of the platform.

Java Reflection Classes

Every object is either a reference or primitive type. Reference types all inherit from

java.lang.Object. Classes, enums, arrays, and interfaces are all reference types. There is a

fixed set of primitive types: boolean, byte, short, int, long, char, float, and double.

Examples of reference types include java.lang.String, all of the wrapper classes for

primitive types such as java.lang.Double, the interface java.io.Serializable, and the enum

javax.swing.SortOrder.

For every type of object, the Java virtual machine instantiates an immutable instance of

java.lang.Class which provides methods to examine the runtime properties of the object

including its members and type information. Class also provides the ability to create

new classes and objects. Most importantly, it is the entry point for all of the Reflection

APIs. This lesson covers the most commonly used reflection operations involving

classes:

• Retrieving Class Objects describes the ways to get a Class

• Examining Class Modifiers and Types shows how to access the class declaration

information

• Discovering Class Members illustrates how to list the constructors, fields, methods,

and nested classes in a class

• Troubleshooting describes common errors encountered when using Class

Retrieving Class Objects

The entry point for all reflection operations is java.lang.Class. With the exception of

java.lang.reflect.ReflectPermission, none of the classes in java.lang.reflect have public

constructors. To get to these classes, it is necessary to invoke appropriate methods on

Class. There are several ways to get a Class depending on whether the code has access to

an object, the name of class, a type, or an existing Class.

Object.getClass()

If an instance of an object is available, then the simplest way to get its Class is to invoke

Object.getClass(). Of course, this only works for reference types which all inherit from

Object. Some examples follow:

Class c = "foo".getClass();

Returns the Class for String

Class c = System.console().getClass();

There is a unique console associated with the virtual machine which is returned by the

static method System.console(). The value returned by getClass() is the Class

corresponding to java.io.Console.

enum E { A, B }

Class c = A.getClass();

A is is an instance of the enum E; thus getClass() returns the Class corresponding to the

enumeration type E.

byte[] bytes = new byte[1024];

Class c = bytes.getClass();

Since arrays are Objects, it is also possible to invoke getClass() on an instance of an

array. The returned Class corresponds to an array with component type byte.

import java.util.HashSet;

import java.util.Set;

Set<String> s = new HashSet<String>();

Class c = s.getClass();

In this case, java.util.Set is an interface to an object of type java.util.HashSet. The value

returned by getClass() is the class corresponding to java.util.HashSet.

The .class Syntax

If the type is available but there is no instance then it is possible to obtain a Class by

appending ".class" to the name of the type. This is also the easiest way to obtain the Class

for a primitive type.

boolean b;

Class c = b.getClass(); // compile-time error

Class c = boolean.class; // correct

Note that the statement boolean.getClass() would produce a compile-time error because a

boolean is a primitive type and cannot be dereferenced. The .class syntax returns the

Class corresponding to the type boolean.

Class c = java.io.PrintStream.class;

The variable c will be the Class corresponding to the type java.io.PrintStream.

Class c = int[][][].class;

The .class syntax may be used to retrieve a Class corresponding to a multi-dimensional

array of a given type.

Class.forName()

If the fully-qualified name of a class is available, it is possible to get the corresponding

Class using the static method Class.forName(). This cannot be used for primitive types.

The syntax for names of array classes is described by Class.getName(). This syntax is

applicable to references and primitive types.

Class c = Class.forName("com.duke.MyLocaleServiceProvider");

This statement will create a class from the given fully-qualified name.

Class cDoubleArray = Class.forName("[D");

Class cStringArray = Class.forName("[[Ljava.lang.String;");

The variable cDoubleArray will contain the Class corresponding to an array of primitive

type double (i.e. the same as double[].class). The cStringArray variable will contain the

Class corresponding to a two-dimensional array of String (i.e. identical to

String[][].class).

TYPE Field for Primitive Type Wrappers

The .class syntax is a more convenient and the preferred way to obtain the Class for a

primitive type; however there is another way to acquire the Class. Each of the primitive

types and void has a wrapper class in java.lang that is used for boxing of primitive types

to reference types. Each wrapper class contains a field named TYPE which is equal to the

Class for the primitive type being wrapped.

Class c = Double.TYPE;

There is a class java.lang.Double which is used to wrap the primitive type double

whenever an Object is required. The value of Double.TYPE is identical to that of

double.class.

Class c = Void.TYPE;

Void.TYPE is identical to void.class.

Methods that Return Classes

There are several Reflection APIs which return classes but these may only be accessed if

a Class has already been obtained either directly or indirectly.

Class.getSuperclass()

Returns the super class for the given class.

Class c = javax.swing.JButton.class.getSuperclass();

The super class of javax.swing.JButton is javax.swing.AbstractButton.

Class.getClasses()

Returns all the public classes, interfaces, and enums that are members of the class

including inherited members.

Class<?>[] c = Character.class.getClasses();

Character contains two member classes Character.Subset and

Character.UnicodeBlock.

Class.getDeclaredClasses()

Returns all of the classes interfaces, and enums that are explicitly declared in this class.

Class<?>[] c = Character.class.getDeclaredClasses();

Character contains two public member classes Character.Subset and

Character.UnicodeBlock and one private class Character.CharacterCache.

{ Class, java.lang.reflect. { Field, Method, Constructor }

}.getDeclaringClass()

Returns the Class in which these members were declared. Anonymous classes will not

have a declaring class but will have an enclosing class.

import java.lang.reflect.Field;

Field f = System.class.getField("out");

Class c = f.getDeclaringClass();

The field out</CODE< a> is declared in System.

public class MyClass {

static Object o = new Object() { public void m() {} };

static Class<c> = o.getClass().getEnclosingClass(); }

The declaring class of the anonymous class defined by o is null.

Class.getEnclosingClass()

Returns the immediately enclosing class of the class.

Class c = Thread.State.class().getEnclosingClass();

The enclosing class of the enum Thread.State is Thread.

public class MyClass {

static Object o = new Object() { public void m() {} };

static Class<c> = o.getClass().getEnclosingClass(); }

The anonymous class defined by o is enclosed by MyClass.

Examining Class Modifiers and Types

A class may be declared with one or more modifiers which affect its runtime behavior:

• Access modifiers: public, protected, and private

• Modifier requiring override: abstract

• Modifier restricting to one instance: static

• Modifier prohibiting value modification: final

• Modifier forcing strict floating point behavior: strictfp

• Annotations

Not all modifiers are allowed on all classes, for example an interface cannot be final

and an enum cannot be abstract. java.lang.reflect.Modifier contains declarations

for all possible modifiers. It also contains methods which may be used to decode the set

of modifiers returned by Class.getModifiers().

Discovering Class Members

There are two categories of methods provided in Class for accessing fields, methods, and

constructors: methods which enumerate these members and methods which search for

particular members. Also there are distinct methods for accessing members declared

directly on the class versus methods which search the superinterfaces and superclasses for

inherited members. The following table provides a summary of all the member-locating

methods and their characteristics.

Member Class API

Field getDeclaredField()

getField()

getDeclaredFields()

getFields()

Method getDeclaredMethod()

getMethod()

getDeclaredMethods()

getMethods()

Constructor getDeclaredConstructor()

getConstructor()

getDeclaredConstructors()

getConstructors()

A Simple Example

To see how reflection works, consider this simple example:

import java.lang.reflect.*;

public class DumpMethods {

public static void main(String args[])

{

try {

Class c = Class.forName(args[0]);

Method m[] = c.getDeclaredMethods();

for (int i = 0; i < m.length; i++)

System.out.println(m[i].toString());

}

catch (Throwable e) {

System.err.println(e);

} } }

For an invocation of: java DumpMethods java.util.Stack

the output is:

public java.lang.Object java.util.Stack.push(

java.lang.Object)

public synchronized

java.lang.Object java.util.Stack.pop()

public synchronized

java.lang.Object java.util.Stack.peek()

public boolean java.util.Stack.empty()

public synchronized

int java.util.Stack.search(java.lang.Object)

This program loads the specified class using class.forName, and then calls

getDeclaredMethods to retrieve the list of methods defined in the class.

java.lang.reflect.Method is a class representing a single class method.

Setting Up to Use Reflection

The reflection classes, such as Method, are found in java.lang.reflect. There are three

steps that must be followed to use these classes. The first step is to obtain a

java.lang.Class object for the class that you want to manipulate. java.lang.Class

is used to represent classes and interfaces in a running Java program.

One way of obtaining a Class object is to say:

Class c = Class.forName("java.lang.String");

to get the Class object for String. Another approach is to use:

Class c = int.class;

or

Class c = Integer.TYPE;

to obtain Class information on fundamental types. The latter approach accesses the

predefined TYPE field of the wrapper (such as Integer) for the fundamental type. The

second step is to call a method such as getDeclaredMethods, to get a list of all the

methods declared by the class. Once this information is in hand, then the third step is to

use the reflection API to manipulate the information. For example, the sequence:

Class c = Class.forName("java.lang.String");

Method m[] = c.getDeclaredMethods();

System.out.println(m[0].toString());

will display a textual representation of the first method declared in String.

Summary

Java reflection is useful because it supports dynamic retrieval of information about

classes and data structures by name, and allows for their manipulation within an

executing Java program. This feature is extremely powerful and has no equivalent in

other conventional languages such as C, C++, Fortran, or Pascal.

Object Serialization

We all know the Java platform allows us to create reusable objects in memory. However,

all of those objects exist only as long as the Java virtual machine remains running. It

would be nice if the objects we create could exist beyond the lifetime of the virtual

machine, wouldn't it? Well, with object serialization, you can flatten your objects and

reuse them in powerful ways.

Object serialization is the process of saving an object's state to a sequence of bytes, as

well as the process of rebuilding those bytes into a live object at some future time. The

Java Serialization API provides a standard mechanism for developers to handle object

serialization. The API is small and easy to use, provided the classes and methods are

understood.

The Default Mechanism

Let's start with the basics. To persist an object in Java, we must have a persistent object.

An object is marked serializable by implementing the java.io.Serializable

interface, which signifies to the underlying API that the object can be flattened into

bytes and subsequently inflated in the future.

Let's look at a persistent class we'll use to demonstrate the serialization mechanism:

import java.io.Serializable;

import java.util.Date;

import java.util.Calendar;

public class PersistentTime implements Serializable

{

private Date time;

public PersistentTime() {

time = Calendar.getInstance().getTime(); }

public Date getTime(){

return time; } }

As you can see, the only thing we had to do differently from creating a normal class is

implement the java.io.Serializable interface. The completely empty

Serializable is only a marker interface -- it simply allows the serialization

mechanism to verify that the class is able to be persisted. Thus, we turn to the first rule

of serialization:

Rule #1: The object to be persisted must implement the Serializable interface or

inherit that implementation from its object hierarchy.

The next step is to actually persist the object. That is done with the

java.io.ObjectOutputStream class. That class is a filter stream--it is wrapped

around a lower-level byte stream (called a node stream) to handle the serialization

protocol for us. Node streams can be used to write to file systems or even across

sockets. That means we could easily transfer a flattened object across a network wire

and have it be rebuilt on the other side!

Take a look at the code used to save the PersistentTime object:

import java.io.ObjectOutputStream;

import java.io.FileOutputStream;

import java.io.IOException;

public class FlattenTime {

public static void main(String [] args){

String filename = "time.ser";

if(args.length > 0){

filename = args[0];}

PersistentTime time = new PersistentTime();

FileOutputStream fos = null;

ObjectOutputStream out = null;

try {

fos = new FileOutputStream(filename);

out = new ObjectOutputStream(fos);

out.writeObject(time);

out.close(); }

catch(IOException ex){

ex.printStackTrace();} } }

When we call the ObjectOutputStream.writeObject() method, which kicks off the

serialization mechanism and the object is flattened (in that case to a file). To restore the

file, we can employ the following code:

import java.io.ObjectInputStream;

import java.io.FileInputStream;

import java.io.IOException;

import java.util.Calendar;

public class InflateTime {

public static void main(String [] args) {

String filename = "time.ser";

if(args.length > 0) {

filename = args[0]; }

PersistentTime time = null;

FileInputStream fis = null;

ObjectInputStream in = null;

try {

fis = new FileInputStream(filename);

in = new ObjectInputStream(fis);

time = (PersistentTime)in.readObject();

in.close(); }

catch(IOException ex) {

ex.printStackTrace(); }

catch(ClassNotFoundException ex) {

ex.printStackTrace(); }

// print out restored time

System.out.println("Flattened time: " + time.getTime());

System.out.println();

// print out the current time

System.out.println("Current time: " +

Calendar.getInstance().getTime()); } }

The object's restoration occurs with the ObjectInputStream.readObject() method

call. The method call reads in the raw bytes that we previously persisted and creates a

live object that is an exact replica of the original. Because readObject() can read any

serializable object, a cast to the correct type is required. With that in mind, the class

file must be accessible from the system in which the restoration occurs. In other words,

the object's class file and methods are not saved; only the object's state is saved.

Later, we simply call the getTime() method to retrieve the time that the original

object flattened. The flatten time is compared to the current time to demonstrate that

the mechanism indeed worked as expected.

Create Your Own Protocol: the Externalizable Interface

Our discussion would be incomplete not to mention the third option for serialization:

create your own protocol with the Externalizable interface. Instead of implementing the

Serializable interface, you can implement Externalizable, which contains two methods:

public void writeExternal(ObjectOutput out) throws IOException;

public void readExternal(ObjectInput in) throws IOException,

ClassNotFoundException;

Just override those methods to provide your own protocol. Unlike the previous two

serialization variations, nothing is provided for free here, though. That is, the protocol is

entirely in your hands. Although it's the more difficult scenario, it's also the most

controllable. An example situation for that alternate type of serialization: read and write

PDF files with a Java application. If you know how to write and read PDF (the sequence

of bytes required), you could provide the PDF-specific protocol in the writeExternal and

readExternal methods.

Just as before, though, there is no difference in how a class that implements

Externalizable is used. Just call writeObject() or readObject and, voila, those

externalizable methods will be called automatically.

Caching Objects in the Stream

First, consider the situation in which an object is written to a stream and then written

again later. By default, an ObjectOutputStream will maintain a reference to an object

written to it. That means that if the state of the written object is written and then

written again, the new state will not be saved! Here is a code snippet that shows that

problem in action:

ObjectOutputStream out = new ObjectOutputStream(...);

MyObject obj = new MyObject(); // must be Serializable

obj.setState(100);

out.writeObject(obj); // saves object with state = 100

obj.setState(200);

out.writeObject(obj); // does not save new object state

There are two ways to control that situation. First, you could make sure to always close

the stream after a write call, ensuring the new object is written out each time. Second,

you could call the ObjectOutputStream.reset() method, which would tell the stream to

release the cache of references it is holding so all new write calls will actually be

written. Be careful, though -- the reset flushes the entire object cache, so all objects

that have been written could be rewritten.

Enterprise Java Bean(EJB)

Enterprise Java Bean architecture is the component architecture for the development and

deployment of robust, world class component-based distributed application using the java

language. One of Java's most important features is platform independence. Since its

arrival, Java has been depicted as "write once, run anywhere". They are not only platform

independent but also implementation independent. That is, EJBs can run in any

application server that implements the EJB specifications.

Enterprise JavaBeans - An Introduction

Enterprise JavaBeans (EJB) is a comprehensive technology that provides the

infrastructure for building enterprise-level server-side distributed Java components. The

EJB technology provides a distributed component architecture that integrates several

enterprise-level requirements such as distribution, transactions, security, messaging,

persistence, and connectivity to mainframes and Enterprise Resource Planning (ERP)

systems. When compared with other distributed component technologies such as Java

RMI and CORBA, the EJB architecture hides most the underlying system-level semantics

that are typical of distributed component applications, such as instance management,

object pooling, multiple threading, and connection pooling. Secondly, unlike other

component models, EJB technology provides us with different types of components for

business logic, persistence, and enterprise messages.

Thus, an Enterprise Java Bean is a remote object with semantics specified for creation,

invocation and deletion. The EJB container is assigned the system-level tasks mentioned

above. What a web container does for Java servlets and JSPs in a web server, the EJB

container is for EJBs.

EJB Architecture

Any distributed component technology should have the following requirements:

1. There should be a mechanism to create the client-side and server-side proxy objects. A

client-side proxy represents the server-side object on the client-side. As far as the client is

concerned, the client-side proxy is equivalent to the server-side object. On the other hand,

the purpose of the server-side proxy is to provide the basic infrastructure to receive client

requests and delegate these request to the actual implementation object

2. We need to obtain a reference to client-side proxy object. In order to communicate

with the server-side object, the client needs to obtain a reference to the proxy.

3. There should be a way to inform the distributed component system that a specific

component is no longer in use by the client.

In order to meet these requirements, the EJB architecture specifies two kinds of interfaces

for each bean. They are home interface and remote interface. These interfaces specify the

bean contract to the clients. However, a bean developer need not provide implementation

for these interfaces. The home interface will contain methods to be used for creating

remote objects. The remote interface should include business methods that a bean is able

to serve to clients. One can consider using the home interface to specify a remote object

capable of creating objects conforming to the remote interface. That is, a home interface

is analogous to a factory of remote objects. These are regular Java interfaces extending

the javax.ejb.EJBHome and javax.ejb.EJBObject interfaces respectively.

As discussed below, the EJB architecture specifies three types of beans - session beans,

entity beans, and message-driven beans. A bean developer has to specify the home and

remote interfaces and also he has to implement one of these bean interfaces depending

upon the type of the bean. For instance, for session beans, he has to implement the

javax.ejb.SessionBean interface. The EJB architecture expects him to implement the

methods specified in the bean interface and the methods specified in the home and remote

interfaces. During the deployment time, he should specify the home and remote interfaces

and bean implementation class to define a bean. The EJB container relies on specific

method names and uses delegation for invoking methods on bean instances.

Thus regarding the first requirement, the EJB container generates the proxy objects for all

beans. For the second one, the EJB container for each bean implement a proxy object to

the home interface and publishes in the JNDI implementation of the J2EE platform. One

can use JNDI to look for this and obtain a reference. As this object implements the home

interface only, he can use one of the creation methods of the home object to get a proxy

to the remote interface of the bean. When one invokes a creation method on the home

proxy object, the container makes sure that a bean instance is created on the EJB

container runtime and its proxy is returned to the client. Once the client gets hold of the

proxy for the remote interface, it can directly access the services of the bean.

Finally, once the client decides to stop accessing the services of the bean, it can inform

the EJB container by calling a remote method on the bean. This signals the EJB container

to disassociate the bean instance from the proxy and that bean instance is ready to service

any other clients.

Types of EJBs

The EJB architecture is based on the concept that in an enterprise computing system,

database persistence-related logic should be independent of the business logic that relies

on the data. This happens to be a very useful technique for separating business logic

concerns from database concerns. This makes that business logic can deal with the

business data without worrying about how the data is stored in a relational database.

Enterprise JavaBeans server-side components come in two fundamentally different types:

entity beans and session beans.

Basically entity beans model business concepts that can be expressed as nouns. For

example, an entity bean might represent a customer, a piece of equipment, an item in

inventory. Thus entity beans model real-world objects. These objects are usually

persistent records in some kind of database.

Session beans are for managing processes or tasks. A session bean is mainly for

coordinating particular kinds of activities. That is, session beans are plain remote objects

meant for abstracting business logic. The activity that a session bean represents is

fundamentally transient. A session bean does not represent anything in a database, but it

can access the database.

Thus an entity bean has persistent state whereas a session bean models interactions but

does not have persistent state.

Session beans are transaction-aware. In a distributed component environment, managing

transactions across several components mandates distributed transaction processing. The

EJB architecture allows the container to manage transactions declaratively. This

mechanism lets a bean developer to specify transactions across bean methods. Session

beans are client-specific. That is, session bean instances on the server side are specific to

the client that created them on the client side. This eliminates the need for the developer

to deal with multiple threading and concurrency.

Unlike session beans, entity beans have a client-independent identity. This is because an

entity bean encapsulates persistent data. The EJB architecture lets a developer to register

a primary key class to encapsulate the minimal set of attributes required to represent the

identity of an entity bean. Clients can use these primary key objects to accomplish the

database operations, such as create, locate, or delete entity beans. Since entity beans

represent persistent state, entity beans can be shared across different clients. Similar to

session beans, entity beans are also transactional, except for the fact that bean instances

are not allowed to programmatically control transactions.

These two types of beans are meant for synchronous invocation. That is, when a client

invokes a method on one of the above types, the client thread will be blocked till the EJB

container completes executing the method on the bean instance. Also these beans are

unable to service the messages which comes asynchronously over a messaging service

such as JMS. To overcome this deficiency, the EJB architecture has introduced a third

type of bean called message-driven bean. A message-driven bean is a bean instance that

can listen to messages from the JMS.

Unlike other types of beans, a message-driven bean is a local object without home and

remote interfaces. In a J2EE platform, message-driven beans are registered against JMS

destinations. When a JMS message receives a destination, the EJB container invokes the

associated message-driven bean. Thus message-driven beans do not require home and

remote interfaces as instances of these beans are created based on receipt of JMS

messages. This is an asynchronous activity and does not involve clients directly. The

main purpose of message-driven beans is to implement business logic in response to JMS

messages. For instance, take a B2B e-commerce application receiving a purchase order

via a JMS message as an XML document. On receipt of such a message in order to

persist this data and perform any business logic, one can implement a message-driven

bean and associate it with the corresponding JMS destination. Also these beans are

completely decoupled from the clients that send messages.

Session Beans: Stateful and Stateless

Session beans can be either stateful or stateless. Stateful session beans maintain

conversational state when used by a client. Conversational state is not written to a

database but can store some state in private variables during one method call and a

subsequent method call can rely on this state. Maintaining a conversational state allows a

client to carry on a conversation with a bean. As each method on the bean is invoked, the

state of the session bean may change and that change can affect subsequent method calls.

Stateless session beans do not maintain any conversational state. Each method is

completely independent and uses only data passed in its parameters. One can specify

whether a bean is stateful or not in the bean's deployment descriptor.

Entity Beans: Container and Bean Managed Persistence

An example entity bean in a B2B application is given as follows. A purchase order is a

business identity and requires persistence store such as a relational database. The various

purchase order attributes can be defined as the attributes of an entity bean. Since database

operations involve create, update, load, delete, and find operations, the EJB architecture

requires entity beans to implement these operations. Entity beans should implement the

javax.ejb.EntityBean interface that specifies the load and delete operations among others.

In addition, the bean developer should specify the appropriate create and find methods on

the home interface, and provide their implementation in an entity bean.

There are two types of entity beans and they are distinguished by how they manage

persistence. Container-managed beans have their persistence automatically managed by

the EJB container. This is a more sophisticated approach and here the bean developer

does not implement the persistence logic. The developer relies on the deployment

descriptor to specify attributes whose persistence should be managed by the container.

The container knows how a bean instance's fields map to the database and automatically

takes care of inserting, updating, and deleting the data associated with entities in the

database.

Beans using bean-managed persistence do all this work explicitly: the bean developer has

to write the code to manipulate the database. The EJB container tells the bean instance

when it is safe to insert, update, and delete its data from the database, but it provides no

other help. The bean instance has to do the persistence work itself.

EJB Container: The environment that surrounds the beans on the EJB server is often

referred to as the container. The container acts as an intermediary between the bean class

and the EJB server. The container manages the EJB objects and EJB homes for a

particular type of bean and helps these constructs to manage bean resources and apply the

primary services relevant to distributed systems to bean instances at run time. An EJB

server can have more than one container and each container in turn can accommodate

more than one enterprise bean. Container means a pre developed software. EJB’s cannot

survive outside containers.

Remote Interface: This interface for an enterprise bean defines the enterprise bean's

business methods that clients for this bean can access. The remote interface extends

javax.ejb.EJBObject, which in turn extends java.rmi.Remote.

Home interface: This interface defines the bean's life cycle methods such as creation of

new beans, removal of beans, and locating beans. The home interface extends

javax.ejb.EJBHome, which in turn extends java.rmi.Remote.

Bean Class: This class has to implement the bean's business methods in the remote

interface apart from some other callback methods. An entity bean must implement

javax.ejb.EntityBean and a session bean must implement javax.ejb.SessionBean. Both

EntityBean and Session Bean extend javax.ejb.EnterpriseBean.

Primary Key: This is a very simple class that provides a reference into the database.

This class has to implement java.io.Serializable. Only entity beans need a primary key.

Deployment Descriptors: Much of the information about how beans are managed at

runtime is not supplied in the interfaces and classes mentioned above. There are some

common primary services related with distributed systems apart from some specific

services such as security, transactions, naming that are being handled automatically by

EJB server. But still EJB server needs to know beforehand how to apply the primary

services to each bean class at runtime. Deployment descriptors exactly do this all

important task.

JAR Files: Jar files are ZIP files that are used specifically for packaging Java classes that

are ready to be used in some type of application. A Jar file containing one or more

enterprise beans includes the bean classes, remote interfaces, home interfaces, and

primary keys for each bean. It also contains one deployment descriptor.

Deployment is the process of reading the bean's JAR file, changing or adding properties

to the deployment descriptor, mapping the bean to the database, defining access control

in the security domain, and generating vendor-specific classes needed to support the bean

in the EJB environment. Every EJB server product comes with its own deployment tools

containing a graphical user interface and a set of command-line programs.

For clients like enterprise bean itself, Java RMI or CORBA client, to locate enterprise

beans on the net, Java EJB specifications specify the clients to use Java Naming and

Directory Interface (JNDI). JNDI is a standard Java extension that provides a uniform

Application Programming Interface (API) for accessing a wide range of naming and

directory services. The communication protocol may be Java RMI-IIOP or CORBA's

IIOP

There are some special integrated application development tools such as Inprise's

JBuilder, Sun's Forte and IBM's VisualAge, for designing EJBs in the market.

Why EJB (Enterprise Java Beans)?

Enterprise Java Beans or EJB for short is the server-side component architecture for

the Java 2 Platform, Enterprise Edition (J2EE) platform. EJB technology enables rapid

and simplified development of distributed, transactional, secure and portable applications

based on Java technology.

Sun Microsystems in the beginning put forward Java Remote Method Invocation

(RMI) API as a distributed object computing technology. RMI specifies how to write

objects so that they can talk to each other no matter where on the network they are found.

At its core, however, RMI is nothing more than an API to which our distributed objects

must conform. RMI says nothing about about other characteristics normally required of

an enterprise-class distributed environment. For example, it does not say anything about

how a client might perform a search for RMI objects matching some criteria. It also does

not specify how those distributed objects work together to construct a single transaction.

Thus there is a realization for a need of a distributed component model.

A component model is a standard that defines how components are written so that

systems can be built from components by different developers with little or no

customization. There is already a component model called as JavaBeans in Java. It is a

component model that defines how we write user interface components so that they may

be plugged into third-party applications. The magic thing about JavaBeans is that there is

very little API behind the specification; we neither implement nor extend any special

classes and we need not call any special methods.

Enterprise JavaBeans is a more complex extension of this concept. While there are API

elements behind Enterprise JavaBeans, it is more than an API. It is a standard way of

writing distributed components so that the written components can be used with the

components we write in someone else's system. RMI does not support this ability for

several reasons listed below. Here comes the features that are not available with RMI.

1. Security - RMI does not worry about security. RMI alone basically leaves our system

wide open. Any one who has access to our RMI interfaces can forge access to the

underlying objects. If we do not impose complex security restrictions to authenticate

clients and verify access by writing extra code, we will have no security at all. Thus our

components are therefore unlikely to interoperate with other's components unless we

agree to some sort of security model.

2. Searching - RMI provides the ability to do a lookup only for a specific, registry-bound

object. It specifies nothing about how we find unbound objects or perform searches for a

group of objects meeting certain requirements. For example, writing a banking

application, we might want to support the ability to find all accounts with negative

balances. In order to do this in an RMI environment, we would have to write our own

search methods in bound objects. Our custom approach to handling searches will not

work with someone's else custom approach to searching without forcing clients to deal

with both search models.

3. Transactions - The most important feature for a distributed component model is

transactions. RMI does not support transactions. If we develop an RMI-based application,

we need to address how we will support transactions. That is, we need to keep track of

when a client begins a transaction, what RMI objects that client changes, and commit and

roll back those changes when the client is done. This is further compounded by the fact

that most distributed object systems support more than one client at a time. Different

transaction models are much more incompatible than different searching or security

models. While client coders can get around differences in search and security models by

being aware of those differences, transaction models can almost never be made to work

together.

4. Persistence - RMI does not care about how RMI objects persist across time. There is a

persistence utility that supports saving RMI objects to a database using JDBC. But it is

very difficult to integrate with RMI objects designed to use some other persistence model

because the other persistence model may have different persistence requirements.

Enterprise JavaBeans addresses all of these points so that we can literally pick and choose

the best designed business components from different vendors and make them work and

play well with one another in the same environment. EJB is now the standard component

model for capturing distributed business components. It hides from us the details we

might have to worry about ourself if we were writing an RMI application.

Application Servers

1. BEA WebLogic Server

2. iPlanet

3. Oracle

4. Orion Server

5. WebSphere

6. NetDynamics

7. JRun Server

8. Tomcat

9. JOnAS

10. Pramati Server

11. Power Tier for J2EE

BEA WebLogic Server JMS

• provides the environment in which a bean executes

• generates Home Object

• generates EJB Object

• manages individual bean instances

Enterprise JavaBeans Model

EJB is Sun’s J2EE transactional, vendor-neutral, enterprise component architecture

providing:

• Modelling of business entities as well as synchronous and asynchronous processes

• Persistence via explicit code (bean-managed) or via services of the EJB server

(container-managed)

• Vendor neutrality and inter operability

• XML driven deployment and configuration

Difference between EJBs and Java Beans:

EJB Java Beans

EJBs need a Container

EJBs are deployable components JBs are development components

EJBs are assembled to form a complete

application

JBs are classes with no argument

constructor

EJBs are based on RMI IIOP and JNDI

technologies

JBs have a get and a set method on them

EJB Overview

EJB simplified distributed development

• Develop EJB implementation logic

• Define Home/Local Remote/Local interfaces

• Container delegates client calls

• Container manages resources/lifecycle/callbacks

Java Naming and Directory Interface (JNDI)

Provides a standardized way of accessing resources in a distributed environment

Protocol and naming service agnostic

• DNS

• NDIS

• LDAP

• X.500

Implemented by the javax.naming package and three other packages below it

javax.naming.InitialContext is the entry point to the EJB Server

• bind – associates a name with an object

• lookup – finds an object given the name

EJB Specification

The EJB specification defines interfaces between

• the EJB and its container

• the container and the application server

• the container and the client

EJB Roles

• Service & Tool Provider provides Server, Container and integrates with

distributed facilities

• EJB Provider creates EJB components

• Application Assembler assembles apps from per-built EJB components

• Deployment Specialist deploys apps and understands architecture issues

EJB Design Approaches

EJB model is based on three basic design approaches for building distributed component

systems:

1. Stateless server approach

2. Session-oriented approach

3. Persistent Object approach

The EJB specification provides these as

• Stateless session Beans

• Stateful session Beans

• Entity Beans

• Message driven beans

RMI

Java Remote Method Invocation

Java Remote Method Invocation (Java RMI) enables you to create distributed Java

technology-based applications that can communicate with other such applications.

Methods of remote Java objects can be invoked from other Java virtual machines,

possibly on different hosts.

With RMI we can write distributed programs in the Java programming language. RMI is

easy to use, you don't need to learn a separate interface definition language (IDL), and

you get Java's inherent "write once, run anywhere" benefit. Clients, remote interfaces,

and servers are written entirely in Java. RMI uses the Java Remote Method Protocol

(JRMP) for remote Java object communication. RMI lacks interoperability with other

languages because it does not use CORBA-IIOP as the communication protocol.

RMI uses object serialization to marshal and unmarshal parameters and does not truncate

types, supporting object-oriented polymorphism. The RMI registry is a lookup service for

ports.

The RMI implementation

The RMI implementation consists of three abstraction layers.

These abstraction layers are:

1. The Stub and Skeleton layer, which intercepts method calls made by the client to

the interface reference variable and redirects these calls to a remote RMI service.

2. The Remote Reference layer understands how to interpret and manage references

made from clients to the remote service objects.

3. The bottom layer is the Transport layer, which is based on TCP/IP connections

between machines in a network. It provides basic connectivity, as well as some

firewall penetration strategies.

On top of the TCP/IP layer, RMI uses a wire-level protocol called Java Remote Method

Protocol (JRMP), which works like this:

1. Objects that require remote behavior should extend the RemoteObject class,

typically through the UnicastRemoteObject subclass.

a. The UnicastRemoteObject subclass exports the remote object to make it

available for servicing incoming RMI calls.

b. Exporting the remote object creates a new server socket, which is bound to

a port number.

c. A thread is also created that listens for connections on that socket. The

server is registered with a registry.

d. A client obtains details of connecting to the server from the registry.

e. Using the information from the registry, which includes the hostname and

the port details of the server's listening socket, the client connects to the

server.

2. When the client issues a remote method invocation to the server, it creates a

TCPConnection object, which opens a socket to the server on the port specified

and sends the RMI header information and the marshalled arguments through this

connection using the StreamRemoteCall class.

3. On the server side:

a. When a client connects to the server socket, a new thread is assigned to

deal with the incoming call. The original thread can continue listening to

the original socket so that additional calls from other clients can be made.

b. The server reads the header information and creates a RemoteCall object

of its own to deal with unmarshalling the RMI arguments from the socket.

c. The serviceCall() method of the Transport class services the incoming call

by dispatching it

d. The dispatch() method calls the appropriate method on the object and

pushes the result back down the wire.

e. If the server object throws an exception, the server catches it and marshals

it down the wire instead of the return value.

4. Back on the client side:

a. The return value of the RMI is unmarshalled and returned from the stub

back to the client code itself.

b. If an exception is thrown from the server, that is unmarshalled and thrown

from the stub.

Understanding distributed garbage collection (DGC)

The RMI subsystem implements reference counting based distributed garbage collection

(DGC) to provide automatic memory management facilities for remote server objects.

When the client creates (unmarshalls) a remote reference, it calls dirty() on the server

side Distributed Garbage Collector. After it has finished with the remote reference, it

calls the corresponding clean() method.

A reference to a remote object is leased for a period of time by the client holding the

reference. The lease period starts when the dirty call is received. The client has to renew

the leases, by making additional dirty calls, on the remote references it holds before such

leases expire. If the client does not renew the lease before it expires, the distributed

garbage collector assumes that the remote object is no longer referenced by that client.

DGCClient implements the client side of the RMI distributed garbage collection system.

The external interface to DGCClient is the registerRefs() method. When a LiveRef to a

remote object enters the JVM, it must be registered with the DGCClient to participate in

distributed garbage collection. When the first LiveRef to a particular remote object is

registered, a dirty call is made to the server-side distributed garbage collector for the

remote object, which returns a lease guaranteeing that the server-side DGC will not

collect the remote object for a certain period of time. While LiveRef instances to remote

objects on a particular server exist, the DGCClient periodically sends more dirty calls to

renew its lease. The DGCClient tracks the local availability of registered LiveRef

instances using phantom references. When the LiveRef instance for a particular remote

object is garbage collected locally, a clean() call is made to the server-side distributed

garbage collector, indicating that the server no longer needs to keep the remote object

alive for this client. The RenewCleanThread handles the asynchronous client-side DGC

activity by renewing the leases and making clean calls. So this thread waits until the next

lease renewal or until any phantom reference is queued for generating clean requests as

necessary.

A Simple Java RMI example

The client program(RmiClient.class) sends a message to the server

program(RmiServer.class). The server program print out the message on the console.

This example consists of the following files:

� MessageReceiverInterface.java

� This part defines the RMI interface. The method (receiveMessage) of the

server class, which implements this interface, is called from the remote

client. In the remote client program, the type of the server class (which is the

remote class in this client class) is this interface.

� RmiServer.java

� This is the server program(class). In this class, the method

“receiveMessage”, which is called from the remote client, is defined. This

class is the implementation of the RMI interface.

� RmiClient.java

� This is the client program(class). The remote method is called from this

class.

� Execution outline

� RmiServer creates the “registry”. This is a kind of dictionary. Its key is a name

(which is the ID of a remote object) and its content is an object. This object is

looked up from a remote program by the name. This registry is accessed from a

remote object by the IP address (or host name) and the port number.

� RmiServer binds the name “rmiServer” and it-self(RmiServer.class) in the

registry.

� RmiClient looks up the remote object (RmiServer) by the name “rmiServer”.

� RmiClient calls the method “receiveMessage” of the RmiServer class.

� The method “receiveMessage” of the RmiServer class prints out the message.

registry

“rmiServer”-RmiServer

RmiClient RmiServer

receiveMessage(…)

registry

“rmiServer”-RmiServer

RmiClient

rmiServer.

RmiServer

receiveMessage(…)

� Compile

� javac RmiServer.java

� rmic RmiServer

� javac RmiClient.java

� Execution

� (at one host,) java RmiServer

� (at another host) java RmiClient <server’s address> 3232 <message text>

� The source codes

ReceiveMessageInterface.java

import java.rmi.*;

public interface ReceiveMessageInterface extends Remote

{

void receiveMessage(String x) throws RemoteException;

}

RmiServer.java

import java.rmi.*;

import java.rmi.registry.*;

import java.rmi.server.*;

import java.net.*;

public class RmiServer extends java.rmi.server.UnicastRemoteObject

implements ReceiveMessageInterface

{

int thisPort;

String thisAddress;

Registry registry; // rmi registry for lookup the remote objects.

registry

“rmiServer”-RmiServer

RmiClient

rmiServer.receiveMessage(…)

RmiServer

receiveMessage(…)

// This method is called from the remote client by the RMI.

// This is the implementation of the “ReceiveMessageInterface”.

public void receiveMessage(String x) throws RemoteException

{

System.out.println(x);

}

public RmiServer() throws RemoteException

{

try{

// get the address of this host.

thisAddress= (InetAddress.getLocalHost()).toString();

}

catch(Exception e){

throw new RemoteException("can't get inet address.");

}

thisPort=3232; // this port(registry’s port)

System.out.println("this address="+thisAddress+",port="+thisPort);

try{

// create the registry and bind the name and object.

registry = LocateRegistry.createRegistry( thisPort );

registry.rebind("rmiServer", this);

}

catch(RemoteException e){ throw e; } }

static public void main(String args[])

{

try{

RmiServer s=new RmiServer(); }

catch (Exception e) {

e.printStackTrace();

System.exit(1); } }

RmiClient.java

import java.rmi.*;

import java.rmi.registry.*;

import java.net.*;

public class RmiClient

{

static public void main(String args[])

{

ReceiveMessageInterface rmiServer;

Registry registry;

String serverAddress=args[0];

String serverPort=args[1];

String text=args[2];

System.out.println("sending "+text+" to "+ serverAddress + ":" +

serverPort);

try{

// get the “registry”

registry=LocateRegistry.getRegistry(

serverAddress, (new Integer (serverPort)).intValue());

// look up the remote object

rmiServer=

(ReceiveMessageInterface) (registry.lookup("rmiServer"));

// call the remote method

rmiServer.receiveMessage(text);

}

catch(RemoteException e){

e.printStackTrace();

}

catch(NotBoundException e){

e.printStackTrace(); } } }

RMI-IIOP

RMI-IIOP adds CORBA (Common Object Request Broker Architecture) capability to

Java RMI, providing standards-based interoperability and connectivity to many other

programming languages and platforms. RMI-IIOP enables distributed Web-enabled Java

applications to transparently invoke operations on remote network services using the

industry standard IIOP defined by the Object Management Group. Runtime components

include a Java ORB for distributed computing using IIOP communication.

RMI-IIOP is for Java programmers who want to program to the RMI interfaces, but use

IIOP as the underlying transport. RMI-IIOP provides interoperability with other

CORBA objects implemented in various languages - but only if all the remote interfaces

are originally defined as Java RMI interfaces. It is of particular interest to programmers

using Enterprise JavaBeans (EJB), since the remote object model for EJBs is RMI-

based.

Other options for creating distributed applications are:

• Java Interface Definition Language (IDL)

Java IDL is for CORBA programmers who want to program in the Java

programming language based on interfaces defined in CORBA Interface

Definition Language (IDL).

• JavaTM

Remote Method Invocation (RMI)

The Java RMI system allows an object running in one Java Virtual Machine

(VM) to invoke methods on an object running in another Java VM. RMI

provides for remote communication between programs written in the Java

programming language via the Java Remote Method Protocol (JRMP).

The Hello World Application

The distributed Hello World example uses a client application to make a remote method

call via IIOP to a server running on the host from which the client was downloaded.

When the client runs, "Hello from MARS!" is displayed.

Writing the Source Files

1. Define the functions of the remote class as an interface written in the Java

programming language

2. Write the implementation class

3. Write the server class

4. Write a client program that uses the remote service

The source files are:

• HelloInterface.java - a remote interface

• HelloImpl.java - a remote object implementation that implements HelloInterface

• HelloServer.java - an RMI server that creates an instance of the remote object

implementation and binds that instance to a name in the Naming Service

• HelloClient.java - a client application that invokes the remote method, sayHello()

Remote interfaces have the following characteristics:

• The remote interface must be declared public. Otherwise, a client will get an error

when attempting to load a remote object that implements the remote interface,

unless that client is in the same package as the remote interface.

• The remote interface extends the java.rmi.Remote interface.

• Each method must declare java.rmi.RemoteException (or a superclass of

RemoteException) in its throws clause, in addition to any application-specific

exceptions.

• The data type of any remote object that is passed as an argument or return value

(either directly or embedded within a local object) must be declared as the remote

interface type (for example, HelloInterface) not the implementation class

(HelloImpl).

Create the file HelloInterface.java. The following code is the interface definition

for the remote interface, HelloInterface, which contains just one method, sayHello:

//HelloInterface.java

import java.rmi.Remote;

public interface HelloInterface extends java.rmi.Remote {

public void sayHello( String from ) throws java.rmi.RemoteException; }

Because remote method invocations can fail in different ways from local method

invocations (due to network-related communication problems and server problems),

remote methods will report communication failures by throwing a

java.rmi.RemoteException.

The Implementation Class

At a minimum, a remote object implementation class, HelloImpl.java must:

• Declare that it implements at least one remote interface

• Define the constructor for the remote object

• Provide implementations for the methods that can be invoked remotely

//HelloImpl.java

import javax.rmi.PortableRemoteObject;

public class HelloImpl extends PortableRemoteObject implements HelloInterface

{

public HelloImpl() throws java.rmi.RemoteException {

super(); // invoke rmi linking and remote object initialization }

public void sayHello( String from ) throws java.rmi.RemoteException {

System.out.println( "Hello from " + from + "!!" );

System.out.flush(); } }

Implement a remote interface

In the Java programming language, when a class declares that it implements an

interface, a contract is formed between the class and the compiler. By entering into this

contract, the class is promising that it will provide method bodies, or definitions, for

each of the method signatures declared in that interface. Interface methods are implicitly

public and abstract, so if the implementation class doesn't fulfill its contract, it becomes

by definition an abstract class, and the compiler will point out this fact if the class was

not declared abstract.

The implementation class in this example is HelloImpl. The implementation class

declares which remote interface(s) it is implementing. Here is the HelloImpl class

declaration:

public class HelloImpl extends PortableRemoteObject

implements HelloInterface{

As a convenience, the implementation class can extend a remote class, which in this

example is javax.rmi.PortableRemoteObject. By extending PortableRemoteObject, the

HelloImpl class can be used to create a remote object that uses IIOP-based transport for

communication.

Define the constructor for the remote object

The constructor for a remote class provides the same functionality as the constructor for a

non-remote class: it initializes the variables of each newly created instance of the class,

and returns an instance of the class to the program which called the constructor.

In addition, the remote object instance will need to be "exported". Exporting a remote

object makes it available to accept incoming remote method requests, by listening for

incoming calls to the remote object on an anonymous port. When you extend

javax.rmi.PortableRemoteObject, your class will be exported automatically upon

creation.

Because the object export could potentially throw a java.rmi.RemoteException, you

must define a constructor that throws a RemoteException, even if the constructor does

nothing else. If you forget the constructor, javac will produce the following error

message:

HelloImpl.java:3: unreported exception java.rmi.RemoteException;

must be caught or declared to be thrown.

public class HelloImpl extends PortableRemoteObject implements HelloInterface{

^

1 error

To review: The implementation class for a remote object needs to:

• Implement a remote interface

• Export the object so that it can accept incoming remote method calls

• Declare its constructor(s) to throw at least a java.rmi.RemoteException

Here is the constructor for the HelloImpl class:

public HelloImpl() throws java.rmi.RemoteException {

super();

}

Note the following:

• The super method call invokes the no-argument constructor of

javax.rmi.PortableRemoteObject, which exports the remote object.

• The constructor must throw java.rmi.RemoteException, because RMI's attempt to

export a remote object during construction might fail if communication resources

are not available.

Provide an implementation for each remote method

The implementation class for a remote object contains the code that implements each of

the remote methods specified in the remote interface. For example, here is the

implementation for the sayHello() method, which returns the string "Hello from

MARS!!" to the caller:

public void sayHello( String from ) throws java.rmi.RemoteException {

System.out.println( "Hello from " + from + "!!");

System.out.flush(); }

Arguments to, or return values from, remote methods can be any data type for the Java

platform, including objects, as long as those objects implement the interface

java.io.Serializable. Most of the core classes in java.lang and java.util implement the

Serializable interface. In RMI:

• By default, local objects are passed by copy, which means that all data members

(or fields) of an object are copied, except those marked as static or transient.

Please refer to the Java Object Serialization Specification for information on how

to alter the default serialization behavior.

• Remote objects are passed by reference. A reference to a remote object is actually

a reference to a stub, which is a client-side proxy for the remote object. Stubs are

described fully in the Java Remote Method Invocation Specification. We'll create

them later in this tutorial in the section: Use rmic to generate stubs and skeletons.

Write The Server Class

A server class is the class which has a main method that creates an instance of the

remote object implementation, and binds that instance to a name in the Naming Service.

The class that contains this main method could be the implementation class itself, or

another class entirely. In this example, the main method is part of HelloServer.java,

which does the following:

• Creates an instance of the servant

• Publishes the object reference

Create the file HelloServer.java. The source code for this file follows. An

explanation of each of the preceding steps follows the source code:

//HelloServer.java

import javax.naming.InitialContext;

import javax.naming.Context;

public class HelloServer {

public static void main(String[] args) {

try {

// Step 1: Instantiate the Hello servant

HelloImpl helloRef = new HelloImpl();

// Step 2: Publish the reference in the Naming Service using JNDI API

Context initialNamingContext = new InitialContext();

initialNamingContext.rebind("HelloService", helloRef );

System.out.println("Hello Server: Ready..."); }

catch (Exception e) {

System.out.println("Trouble: " + e);

e.printStackTrace(); } } }

Create an instance of a remote object

The main method of the server needs to create an instance of the remote object

implementation, or Servant. For example:

HelloImpl helloRef = new HelloImpl();

The constructor exports the remote object, which means that once created, the remote

object is ready to accept incoming calls.

Publish the object reference

For a caller (client, peer, or client application) to be able to invoke a method on a remote

object, that caller must first obtain a reference to the remote object. Once a remote object

is registered on the server, callers can look up the object by name (using a naming

service), obtain a remote object reference, and then remotely invoke methods on the

object. In this example, we use the Naming Service that is part of the Object Request

Broker Daemon (orbd). For example, the following code binds the name "HelloService"

to a reference for the remote object:

// Step 2: Publish the reference in the Naming Service using JNDI API

Context initialNamingContext = new InitialContext();

initialNamingContext.rebind("HelloService", helloRef );

Note the following about the arguments to the rebind method call:

• The first argument, "HelloService", is a java.lang.String, representing the name of

the remote object to bind

• The second argument, helloRef is the object id of the remote object to bind

Write a client program that uses the remote service

The client application in this example remotely invokes the sayHello method in order

to get the string "Hello from MARS!!" to display when the client application runs.

Create the file HelloClient.java. Here is the source code for the client application:

//HelloClient.java

import java.rmi.RemoteException;

import java.net.MalformedURLException;

import java.rmi.NotBoundException;

import javax.rmi.*;

import java.util.Vector;

import javax.naming.NamingException;

import javax.naming.InitialContext;

import javax.naming.Context;

public class HelloClient {

public static void main( String args[] ) {

Context ic;

Object objref;

HelloInterface hi;

try {

ic = new InitialContext();

// STEP 1: Get the Object reference from the Name Service

// using JNDI call.

objref = ic.lookup("HelloService");

System.out.println("Client: Obtained a ref. to Hello server.");

// STEP 2: Narrow the object reference to the concrete type and

// invoke the method.

hi = (HelloInterface) PortableRemoteObject.narrow(

objref, HelloInterface.class);

hi.sayHello( " MARS " );

} catch( Exception e ) {

System.err.println( "Exception " + e + "Caught" );

e.printStackTrace( );

return; } } }

First, the client application gets a reference to the remote object implementation

(advertised as "HelloService") from the Naming Service using Java Naming and

Directory Interface [TM] (JNDI) calls. Like the Naming.rebind method, the

Naming.lookup method takes java.lang.String value representing the name of the

object to look up. You supply Naming.lookup() the name of the object you want to

look up, and it returns the object bound to that name. Naming.lookup() returns the

stub for the remote implementation of the Hello interface to its caller (HelloClient).

The client application invokes the remote sayHello() method on the server's remote

object, causing the string "Hello from MARS!!" to be displayed on the command line.

Compile the Example

The source code for this example is now complete and the directory contains four files:

• HelloInterface.java contains the source code for the remote interface

• HelloImpl.java contains the source code for the remote object implementation

• HelloServer.java contains the source code for the server

• HelloClient.java contains the source code for the client application

In this section, you compile the remote object implementation file, HelloImpl.java, in

order to create the .class files needed to run rmic. You then run the rmic compiler to

create stubs and skeletons. A stub is a client-side proxy for a remote object which

forwards RMI-IIOP calls to the server-side dispatcher, which in turn forwards the call to

the actual remote object implementation. The last task is to compile the remaining .java

source files to create .class files. The following tasks will be completed in this section:

1. Compile the remote object implementation

2. Use rmic to generate stubs and skeletons

3. Compile the source files

Compile the remote object implementation

To create stub and skeleton files, the rmic compiler must be run on the fully-qualified

package names of compiled class files that contain remote object implementations. In

this example, the file that contains the remote object implementations is HelloImpl.java.

To generate the stubs and skeletons:

Compile HelloImpl.java, as follows:

javac -d . -classpath . HelloImpl.java

The "-d ." option indicates that the generated files should be placed in the directory from

which you are running the compiler. The "-classpath ." option indicates that files on

which HelloImpl.java is dependent can be found in this directory.

Use rmic to generate skeletons and stubs

To create CORBA-compatible stub and skeleton files, run the rmic compiler with the -

iiop option. The rmic -iiop command takes one or more class names as an argument and

produces class files of the form _HelloImpl_Tie.class and _HelloInterface_Stub.class.

The remote implementation file, HelloImpl.class, is the class name to pass in this

example. For an explanation of rmic options, you can refer to the Solaris rmic manual

page or the Windows rmic manual page. To create the stub and skeleton for the

HelloImpl remote object implementation, run rmic like this:

rmic -iiop HelloImpl

The preceding command creates the following files:

• _HelloInterface_Stub.class - the client stub

• _HelloImpl_Tie.class - the server skeleton

Compile the source files

Compile the source files as follows:

javac -d . -classpath . HelloInterface.java HelloServer.java HelloClient.java

This command creates the class files HelloInterface.class, HelloServer.class, and

HelloClient.class. These are the remote interface, the server, and the client application

respectively.

Run the Example

The following tasks will be completed in this section:

1. Start the Naming Service

2. Start the server

3. Run the client application

Start the Naming Service

For this example, we will use the Object Request Broker Daemon, orbd, which includes

both a Transient and a Persistent Naming Service, and is available with every download

of J2SE 1.4 and higher. For a caller (client, peer, or client application) to be able to

invoke a method on a remote object, that caller must first obtain a reference to the remote

object. Once a remote object is registered on the server, callers can look up the object by

name, obtain a remote object reference, and then remotely invoke methods on the object.

Start the Naming Service by running orbd from the command line. For this example, on

the Solaris operating system:

orbd -ORBInitialPort 1050&

or, on the Windows operating system:

start orbd -ORBInitialPort 1050

You must specify a port on which to run orbd. For this example the port of 1050 is

chosen because in the Solaris operating environment, a user must become root to start a

process on a port under 1024.

You must stop and restart the server any time you modify a remote interface or use

modified/additional remote interfaces in a remote object implementation. Otherwise,

the type of the object reference bound in the Naming Service will not match the

modified class.

Start the server

Open another terminal window and change to the directory containing the source files

for this example. The command for running the client has been spread out below to

make it easier to read, but should be typed without returns between the lines. The

following command shows how to start the HelloServer server. If you used a port other

than 1050 or a host other than localhost when starting the orbd tool, replace those values

in the command below with the actual values used to start orbd. Start the Hello server,

as follows:

java -classpath .

-Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory

-Djava.naming.provider.url=iiop://localhost:1050

HelloServer

The output should look like this:

Hello Server: Ready ...

Run the client application

Once the Naming Service and server are running, the client application can be run. From

a new terminal window, go to the source code directory, and run the client application

from the command line, as shown below. The command for running the client has been

spread out below to make it easier to read, but should be typed without returns between

the lines. If you used a port other than 1050 or a host other than localhost when starting

the orbd tool, replace those values in the command below with the actual values used to

start orbd. Start the client application, as follows:

java -classpath . -Djava.naming.factory.initial = com.sun.jndi.cosnaming.

CNCtxFactory -Djava.naming.provider.url=iiop://localhost:1050 HelloClient

After running the client application, you will see output similar to the following on your

display:

Client: Obtained a ref. to Hello server.

Hello from MARS

ORBD and the Hello server will continue to run until they are explicitly stopped. On

Solaris, you can stop these processes using the pkill orbd and pkill HelloServer

commands from a terminal window. On Windows, you can type Ctrl+C in a prompt

window to kill the process.

CORBA

CORBA, or Common Object Request Broker Architecture, is a standard architecture for

distributed object systems. It allows a distributed, heterogeneous collection of objects to

interoperate. CORBA is a specification that defines how distributed objects can

interoperate. Until the explosion in popularity of the World Wide Web and in particular,

the java programming language, CORBA was basically a high-end, distributed-object

solution primarily used by c++ developers.

The Common Object Request Broker Architecture (CORBA) is an emerging open

distributed object computing infrastructure being standardized by the Object

Management Group (OMG). CORBA automates many common network programming

tasks such as object registration, location, and activation; request demultiplexing; framing

and error-handling; parameter marshalling and demarshalling; and operation dispatching.

Common Object Request Broker Architecture (CORBA) is an open, vendor-independent

specification for distributed computing. It is published by the Object Management Group

(OMG).

Using the Internet Inter-ORB Protocol (IIOP), CORBA allows objects on different

architectures, operating systems, and networks to interoperate. This interoperability is

obtained by the use of the Interface Definition Language (IDL), which specifies the

syntax that is used to invoke operations on objects. IDL is programming-language

independent.

Developers define the hierarchy, attributes, and operations of objects in IDL, then use an

IDL compiler (such as IDLJ for Java™) to map the definition onto an implementation in

a programming language. The implementation of an object is encapsulated. Clients of the

object can see only its external IDL interface.

OMG have produced specifications for mappings from IDL to many common

programming languages, including C, C++, and Java. Central to the CORBA

specification is the Object Request Broker (ORB). The ORB routes requests from client

to remote object, and responses to their destinations. Java contains an implementation of

the ORB that communicates by using IIOP.

CORBA Architecture

CORBA defines an architecture for distributed objects. The basic CORBA paradigm is

that of a request for services of a distributed object. Everything else defined by the OMG

is in terms of this basic paradigm. The following figure illustrates the primary

components in the OMG Reference Model architecture.

Figure 1. OMG Reference Model Architecture

• Object Services -- These are domain-independent interfaces that are used by

many distributed object programs. For example, a service providing for the

discovery of other available services is almost always necessary regardless of the

application domain. Two examples of Object Services that fulfill this role are:

o The Naming Service -- which allows clients to find objects based on

names;

o The Trading Service -- which allows clients to find objects based on their

properties.

There are also Object Service specifications for lifecycle management, security,

transactions, and event notification, as well as many others.

• Common Facilities -- Like Object Service interfaces, these interfaces are also

horizontally-oriented, but unlike Object Services they are oriented towards end-

user applications. An example of such a facility is the Distributed Document

Component Facility (DDCF), a compound document Common Facility based on

OpenDoc. DDCF allows for the presentation and interchange of objects based on

a document model, for example, facilitating the linking of a spreadsheet object

into a report document.

• Domain Interfaces -- These interfaces fill roles similar to Object Services and

Common Facilities but are oriented towards specific application domains. For

example, one of the first OMG RFPs issued for Domain Interfaces is for Product

Data Management (PDM) Enablers for the manufacturing domain. Other OMG

RFPs will soon be issued in the telecommunications, medical, and financial

domains.

• Application Interfaces - These are interfaces developed specifically for a given

application. Because they are application-specific, and because the OMG does not

develop applications (only specifications), these interfaces are not standardized.

However, if over time it appears that certain broadly useful services emerge out of

a particular application domain, they might become candidates for future OMG

standardization.

CORBA ORB Architecture The following figure illustrates the primary components in the CORBA ORB

architecture. Descriptions of these components are available below the figure.

Figure 2. CORBA ORB Architecture

• Object -- This is a CORBA programming entity that consists of an identity, an

interface, and an implementation, which is known as a Servant.

• Servant -- This is an implementation programming language entity that defines

the operations that support a CORBA IDL interface. Servants can be written in a

variety of languages, including C, C++, Java, Smalltalk, and Ada.

• Client -- This is the program entity that invokes an operation on an object

implementation. Accessing the services of a remote object should be transparent

to the caller. Ideally, it should be as simple as calling a method on an object, i.e.,

obj->op(args). The remaining components in Figure 2 help to support this level

of transparency.

• Object Request Broker (ORB) -- The ORB provides a mechanism for

transparently communicating client requests to target object implementations. The

ORB simplifies distributed programming by decoupling the client from the details

of the method invocations. This makes client requests appear to be local

procedure calls. When a client invokes an operation, the ORB is responsible for

finding the object implementation, transparently activating it if necessary,

delivering the request to the object, and returning any response to the caller.

• ORB Interface -- An ORB is a logical entity that may be implemented in various

ways (such as one or more processes or a set of libraries). To decouple

applications from implementation details, the CORBA specification defines an

abstract interface for an ORB. This interface provides various helper functions

such as converting object references to strings and vice versa, and creating

argument lists for requests made through the dynamic invocation interface

described below.

• CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as

the ``glue'' between the client and server applications, respectively, and the ORB.

The transformation between CORBA IDL definitions and the target programming

language is automated by a CORBA IDL compiler. The use of a compiler reduces

the potential for inconsistencies between client stubs and server skeletons and

increases opportunities for automated compiler optimizations.

• Dynamic Invocation Interface (DII) -- This interface allows a client to directly

access the underlying request mechanisms provided by an ORB. Applications use

the DII to dynamically issue requests to objects without requiring IDL interface-

specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style

requests), the DII also allows clients to make non-blocking deferred synchronous

(separate send and receive operations) and oneway (send-only) calls.

• Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the

client side's DII. The DSI allows an ORB to deliver requests to an object

implementation that does not have compile-time knowledge of the type of the

object it is implementing. The client making the request has no idea whether the

implementation is using the type-specific IDL skeletons or is using the dynamic

skeletons.

• Object Adapter -- This assists the ORB with delivering requests to the object and

with activating the object. More importantly, an object adapter associates object

implementations with the ORB. Object adapters can be specialized to provide

support for certain object implementation styles (such as OODB object adapters

for persistence and library object adapters for non-remote objects).

Interface Definition Language (IDL)

The services that an object provides are given by its interface. Interfaces are defined in

OMG's Interface Definition Language (IDL). Distributed objects are identified by object

references, which are typed by IDL interfaces.

Developers use the Interface Definition Language (IDL) to describe the interface to a

CORBA object. An IDL schema can then be used to generate Java code for the client and

server that will use the object. The same IDL schema could be used to generate either a

client or server in C++, Ada, or any other language that supports CORBA. You don't

write your implementation of a CORBA service in IDL - so you can continue to write in

pure Java code if you so wish.

The figure below graphically depicts a request. A client holds an object reference to a

distributed object. The object reference is typed by an interface. In the figure below the

object reference is typed by the Rabbit interface. The Object Request Broker, or ORB,

delivers the request to the object and returns any results to the client. In the figure, a jump

request returns an object reference typed by the AnotherObject interface.

The Common Object Request Broker Architecture (CORBA) from the Object

Management Group (OMG) provides a platform-independent, language-independent

architecture for writing distributed, object-oriented applications.

CORBA objects can reside in the same process, on the same machine, down the hall, or

across the planet. The Java language is an excellent language for writing CORBA

programs. Some of the features that account for this popularity include the clear mapping

from OMG IDL to the Java programming language, and the Java runtime environment's

built-in garbage collection.

The ORB

The ORB is the distributed service that implements the request to the remote object. It

locates the remote object on the network, communicates the request to the object, waits

for the results and when available communicates those results back to the client.

The ORB implements location transparency. Exactly the same request mechanism is used

by the client and the CORBA object regardless of where the object is located. It might be

in the same process with the client, down the hall or across the planet. The client cannot

tell the difference.

The ORB implements programming language independence for the request. The client

issuing the request can be written in a different programming language from the

implementation of the CORBA object. The ORB does the necessary translation between

programming languages. Language bindings are defined for all popular programming

languages.

Introduction to CORBA IDL

The first step in developing a CORBA application is to define the interfaces to the objects

required in your distributed system. To define these interfaces, we use CORBA IDL. IDL

allows us to define interfaces to objects without specifying the implementation of those

interfaces. To implement an IDL interface, we define a C++ class that can be accessed

through that interface and then we create objects of that class within an Orbix server

application.

In fact, we can implement IDL interfaces using any programming language for which an

IDL mapping is available. An IDL mapping specifies how an interface defined in IDL

corresponds to an implementation defined in a programming language. CORBA

applications written in different programming languages are fully interoperable. CORBA

defines standard mappings from IDL to several programming languages, including C++,

Java, and Smalltalk. The Orbix IDL compiler converts IDL definitions to corresponding

C++ definitions, in accordance with the standard IDL to C++ mapping.

IDL Modules and Scoping

An IDL module defines a naming scope for a set of IDL definitions. Modules allow you

to group interface and other IDL type definitions in logical name spaces. When writing

IDL definitions, always use modules to avoid possible name clashes. The following

example illustrates the use of modules in IDL:

// IDL module BankSimple { interface Bank { ... }; interface Account { ... }; };

The interfaces Bank and Account are scoped within the module BankSimple. IDL

definitions are available directly within the scope in which you define them. In other

naming scopes, you must use the scoping operator (::) to access these definitions. For

example, the fully scoped name of interfaces Bank and Account are BankSimple::Bank

and BankSimple::Account respectively.

IDL modules can be reopened. For example, a module declaration can appear several

times in a single IDL specification if each declaration contains different data types. In

most IDL specifications, this feature of modules is not required.

Defining IDL Interfaces

An IDL interface describes the functions that an object supports in a distributed

application. Interface definitions provide all of the information that clients need to access

the object across a network. Consider the example of an interface that describes objects

which implement bank accounts in a distributed application. The IDL interface definition

is as follows:

//IDL module BankSimple { // Define a named type to represent money. typedef float CashAmount; // Forward declaration of interface Account. interface Account; interface Bank { ... }; interface Account { // The account owner and balance. readonly attribute string name; readonly attribute CashAmount balance; // Operations available on the account. void deposit (in CashAmount amount); void withdraw (in CashAmount amount); }; };

The definition of interface Account includes both attributes and operations. These are

the main elements of any IDL interface definition.

Attributes in IDL Interface Definitions

Conceptually, attributes correspond to variables that an object implements. Attributes

indicate that these variables are available in an object and that clients can read or write

their values.

In general, attributes map to a pair of functions in the programming language used to

implement the object. These functions allow client applications to read or write the

attribute values. However, if an attribute is preceded by the keyword readonly, then

clients can only read the attribute value.

For example, the Account interface defines the attributes name and balance. These

attributes represent information about the account which the object implementation can

set, but which client applications can only read.

Operations in IDL Interface Definitions

IDL operations define the format of functions, methods, or operations that clients use to

access the functionality of an object. An IDL operation can take parameters and return a

value, using any of the available IDL data types. For example, the Account interface

defines the operations deposit() and withdraw() as follows:

//IDL module BankSimple { typedef float CashAmount; ... interface Account { // Operations available on the account. void deposit(in CashAmount amount); void withdraw(in CashAmount amount); ... }; };

Each operation takes a parameter and has a void return type. Each parameter definition

must specify the direction in which the parameter value is passed. The possible parameter

passing modes are as follows:

in The parameter is passed from the caller of the operation to the object. out The parameter is passed from the object to the caller. inout The parameter is passed in both directions.

Parameter passing modes clarify operation definitions and allow an IDL compiler to map

operations accurately to a target programming language.

Raising Exceptions in IDL Operations

IDL operations can raise exceptions to indicate the occurrence of an error. CORBA

defines two types of exceptions:

• System exceptions are a set of standard exceptions defined by CORBA.

• User-defined exceptions are exceptions that you define in your IDL specification.

Implicitly, all IDL operations can raise any of the CORBA system exceptions. No

reference to system exceptions appears in an IDL specification. To specify that an

operation can raise a user-defined exception, first define the exception structure and then

add an IDL raises clause to the operation definition. For example, the operation

withdraw() in interface Account could raise an exception to indicate that the withdrawal

has failed, as follows:

// IDL module BankExceptions { typedef float CashAmount; ... interface Account {

exception InsufficientFunds { string reason; }; void withdraw(in CashAmount amount) raises(InsufficientFunds); ... }; };

An IDL exception is a data structure that contains member fields. In the preceding

example, the exception InsufficientFunds includes a single member of type string.

The raises clause follows the definition of operation withdraw() to indicate that this

operation can raise exception InsufficientFunds. If an operation can raise more then

one type of user-defined exception, include each exception identifier in the raises clause

and separate the identifiers using commas.

Invocation Semantics for IDL Operations

By default, IDL operations calls are synchronous, that is a client calls an operation and

blocks until the object has processed the operation call and returned a value. The IDL

keyword oneway allows you to modify these invocation semantics.

If you precede an operation definition with the keyword oneway, a client that calls the

operation will not block while the object processes the call. For example, you could add a

oneway operation to interface Account that sends a notice to an Account object, as

follows:

module BankSimple {

... interface Account { oneway void notice(in string text); ... }; };

Orbix does not guarantee that a oneway operation call will succeed; so if a oneway

operation fails, a client may never know. There is only one circumstance in which Orbix

indicates failure of a oneway operation. If a oneway operation call fails before Orbix

transmits the call from the client address space, then Orbix raises a system exception. A

oneway operation can not have any out or inout parameters and can not return a value.

In addition, a oneway operation can not have an associated raises clause.

Passing Context Information to IDL Operations

CORBA context objects allow a client to map a set of identifiers to a set of string values.

When defining an IDL operation, you can specify that the operation should receive the

client mapping for particular identifiers as an implicit part of the operation call. To do

this, add a context clause to the operation definition.

Consider the example of an Account object, where each client maintains a set of

identifiers, such as sys_time and sys_location that map to information that the

operation deposit() logs for each deposit received. To ensure that this information is

passed with every operation call, extend the definition of deposit() as follows:

// IDL module BankSimple { typedef float CashAmount; ... interface Account { void deposit(in CashAmount amount) context("sys_time", "sys_location"); ... }; };

A context clause includes the identifiers for which the operation expects to receive

mappings.

Inheritance of IDL Interfaces

IDL supports inheritance of interfaces. An IDL interface can inherit all the elements of

one or more other interfaces. For example, the following IDL definition illustrates two

interfaces, called CheckingAccount and SavingsAccount, that inherit from interface

Account:

// IDL module BankSimple{ interface Account { ... }; interface CheckingAccount : Account { readonly attribute overdraftLimit; boolean orderChequeBook (); }; interface SavingsAccount : Account {

float calculateInterest (); }; };

Interfaces CheckingAccount and SavingsAccount implicitly include all elements of

interface Account. An object that implements CheckingAccount can accept invocations

on any of the attributes and operations of this interface, and on any of the elements of

interface Account. However, a CheckingAccount object may provide different

implementations of the elements of interface Account to an object that implements

Account only. The following IDL definition shows how to define an interface that

inherits both CheckingAccount and SavingsAccount:

// IDL module BankSimple { interface Account { ... }; interface CheckingAccount : Account { ... }; interface SavingsAccount : Account { ... }; interface PremiumAccount : CheckingAccount, SavingsAccount { ... }; };

Interface PremiumAccount is an example of multiple inheritance in IDL. Figure 3.1

illustrates the inheritance hierarchy for this interface. If you define an interface that

inherits from two interfaces which contain a constant, type, or exception definition of the

same name, you must fully scope that name when using that constant, type, or exception.

An interface can not inherit from two interfaces that include operations or attributes that

have the same name.

Figure 3.1: Multiple Inheritance of IDL Interfaces

The Object Interface Type

IDL includes the pre-defined interface Object, which all user-defined interfaces inherit

implicitly. While interface Object is never defined explicitly in your IDL specification,

the operations of this interface are available through all your interface types. In addition,

you can use Object as an attribute or operation parameter type to indicate that the

attribute or operation accepts any interface type, for example:

// IDL interface ObjectLocator { void getAnyObject (out Object obj); };

Note that it is not legal IDL syntax to inherit interface Object explicitly.

Forward Declaration of IDL Interfaces

In an IDL definition, you must declare an IDL interface before you reference it. A

forward declaration declares the name of an interface without defining it. This feature of

IDL allows you to define interfaces that mutually reference each other. For example, IDL

interface Bank includes an operation of IDL interface type Account, to indicate that Bank

stores a reference to an Account object. If the definition of interface Account follows the

definition of interface Bank, you must forward declare Account as follows:

// IDL module BankSimple { // Forward declaration of Account. interface Account; interface Bank { Account create_account (in string name); Account find_account (in string name); }; // Full definition of Account. interface Account { ... }; };

The syntax for a forward declaration is the keyword interface followed by the interface

identifier.

Overview of the IDL Data Types

In addition to IDL module, interface, and exception types, there are three general

categories of data type in IDL:

• Basic types.

• Complex types.

• Pseudo object types

IDL Basic Types

The following table lists the basic types supported in IDL.

IDL Type Range of Values Short -2 15...2 15-1 (16-bit) unsigned short 0...2 16-1 (16-bit) Long -2 31...2 31-1 (32-bit) unsigned long 0...2 32-1 (32-bit) long long -2 63...2 63-1 (64-bit) unsigned long long

0...-2 64 (64-bit)

Float IEEE single-precision floating point numbers. Double IEEE double-precision floating point numbers. Char An 8-bit value. Boolean TRUE or FALSE. Octet An 8-bit value that is guaranteed not to undergo any conversion

during transmission. Any The any type allows the specification of values that can express an

arbitrary IDL type.

The any data type allows you to specify that an attribute value, an operation parameter, or

an operation return value can contain an arbitrary type of value to be determined at

runtime.

IDL Complex Types

This section describes the IDL data types enum, struct, union, string, sequence, array, and

fixed.

Enum

An enumerated type allows you to assign identifiers to the members of a set of values, for

example:

// IDL module BankSimple { enum Currency {pound, dollar, yen, franc}; interface Account { readonly attribute CashAmount balance; readonly attribute Currency balanceCurrency; ... }; };

In this example, attribute balanceCurrency in interface Account can take any one of the

values pound, dollar, yen, or franc.

Struct A struct data type allows you to package a set of named members of various types, for

example:

// IDL module BankSimple{ struct CustomerDetails { string name; short age; }; interface Bank { CustomerDetails getCustomerDetails (in string name); ... }; };

In this example, the struct CustomerDetails has two members. The operation

getCustomerDetails() returns a struct of type CustomerDetails that includes values

for the customer name and age.

Union

A union data type allows you to define a structure that can contain only one of several

alternative members at any given time. A union saves space in memory, as the amount of

storage required for a union is the amount necessary to store its largest member. All IDL

unions are discriminated. A discriminated union associates a label value with each

member. The value of the label indicates which member of the union currently stores a

value. For example, consider the following IDL union definition:

// IDL struct DateStructure { short Day; short Month; short Year; }; union Date switch (short) { case 1: string stringFormat; case 2: long digitalFormat; default: DateStructure structFormat; };

The union type Date is discriminated by a short value. For example, if this short value is

1, then the union member stringFormat stores a date value as an IDL string. The default

label associated with the member structFormat indicates that if the short value is not 1

or 2, then the structFormat member stores a date value as an IDL struct.

Note that the type specified in parentheses after the switch keyword must be an integer,

char, boolean or enum type and the value of each case label must be compatible with this

type.

String An IDL string represents a character string, where each character can take any value of

the char basic type. If the maximum length of an IDL string is specified in the string

declaration, then the string is bounded. Otherwise the string is unbounded. The following

example shows how to declare bounded and unbounded strings:

// IDL module BankSimple { interface Account { // A bounded string with maximum length 10. attribute string<10> sortCode; // An unbounded string. readonly attribute string name; ... }; };

Sequence In IDL, you can declare a sequence of any IDL data type. An IDL sequence is similar to a

one-dimensional array of elements. An IDL sequence does not have a fixed length. If the

sequence has a fixed maximum length, then the sequence is bounded. Otherwise, the

sequence is unbounded. For example, the following code shows how to declare bounded

and unbounded sequences as members of an IDL struct:

// IDL module BankSimple { interface Account { ... }; struct LimitedAccounts { string bankSortCode<10>; // Maximum length of sequence is 50. sequence<Account, 50> accounts; }; struct UnlimitedAccounts { string bankSortCode<10>; // No maximum length of sequence. sequence<Account> accounts; }; };

A sequence must be named by an IDL typedef declaration before it can be used as the

type of an IDL attribute or operation parameter. The following code illustrates this:

// IDL module BankSimple { typedef sequence<string> CustomerSeq; interface Account { void getCustomerList(out CustomerSeq names); ... }; };

Arrays In IDL, you can declare an array of any IDL data type. IDL arrays can be multi-

dimensional and always have a fixed size. For example, you can define an IDL struct

with an array member as follows:

// IDL module BankSimple { ...

interface Account { ... }; struct CustomerAccountInfo { string name; Account accounts[3]; }; interface Bank { getCustomerAccountInfo (in string name, out CustomerAccountInfo accounts); ... }; };

In this example, struct CustomerAccountInfo provides access to an array of Account

objects for a bank customer, where each customer can have a maximum of three

accounts. An array must be named by an IDL typedef declaration before it can be used

as the type of an IDL attribute or operation parameter. The IDL typedef declaration

allows you define an alias for a data type. The following code illustrates this:

// IDL module BankSimple { interface Account { ... }; typedef Account AccountArray[100]; interface Bank { readonly attribute AccountArray accounts; ... }; };

Note that an array is a less flexible data type than an IDL sequence, because an array

always has a fixed length. An IDL sequence always has a variable length, although it may

have an associated maximum length value.

Fixed The fixed data type allows you to represent number in two parts: a digit and a scale. The

digit represents the length of the number, and the scale is a non-negative integer that

represents the position of the decimal point in the number, relative to the rightmost digit.

module BankSimple { typedef fixed<10,4> ExchangeRate; struct Rates { ExchangeRate USRate; ExchangeRate UKRate; ExchangeRate IRRate; }; };

In this case, the ExchangeRate type has a digit of size 10, and a scale of 4. This means

that it can represent numbers up to (+/-)999999.9999. The maximum value for the digits

is 31, and scale cannot be greater than digits. The maximum value that a fixed type can

hold is equal to the maximum value of a double. Scale can also be a negative number.

This means that the decimal point is moved scale digits in a rightward direction, causing

trailing zeros to be added to the value of the fixed. For example, fixed <3,-4> with a

numeric value of 123 actually represents the number 1230000. This provides a

mechanism for storing numbers with trailing zeros in an efficient manner. Note: Fixed

<3, -4> can also be represented as fixed <7, 0>. Constant fixed types can also be

declared in IDL. The digits and scale are automatically calculated from the constant

value. For example:

module Circle { const fixed pi = 3.142857; };

This yields a fixed type with a digits value of 7, and a scale value of 6.

IDL Pseudo Object Types

CORBA defines a set of pseudo object types that ORB implementations use when

mapping IDL to some programming languages. These object types have interfaces

defined in IDL but do not have to follow the normal IDL mapping for interfaces and are

not generally available in your IDL specifications. You can use only the following

pseudo object types as attribute or operation parameter types in an IDL specification:

CORBA::NamedValue CORBA::Principal CORBA::TypeCode

To use any of these three types in an IDL specification, include the file orb.idl in the

IDL file as follows:

// IDL #include <orb.idl> ...

This statement indicates to the IDL compiler that types NamedValue, Principal, and

TypeCode may be used. The file orb.idl should not actually exist in your system. Do

not name any of your IDL files orb.idl.

Defining Data Type Names and Constants

IDL allows you to define new data type names and constants. This section describes how

to use each of these features of IDL.

Data Type Names

The typedef keyword allows you define a meaningful or more simple name for an IDL

type. The following IDL provides a simple example of using this keyword:

// IDL module BankSimple { interface Account { ... };

typedef Account StandardAccount; };

The identifier StandardAccount can act as an alias for type Account in subsequent IDL

definitions. Note that CORBA does not specify whether the identifiers Account and

StandardAccount represent distinct IDL data types in this example.

Constants IDL allows you to specify constant data values using one of several basic data types. To

declare a constant, use the IDL keyword const, for example:

// IDL module BankSimple { interface Bank { const long MaxAccounts = 10000; const float Factor = (10.0 - 6.5) * 3.91; ... }; };

The value of an IDL constant cannot change. You can define a constant at any level of

scope in your IDL specification.

System Object Model System Object Model (SOM) is an object-oriented shared library system developed by

IBM. DSOM, a distributed version based on CORBA, allowed objects on different

computers to communicate.

SOM (System Object Model) is a library packaging technology that enables languages to

share class libraries regardless of the language they were written in. This ability to share

class libraries between various object oriented languages solves many interoperability

and re-use problems between object oriented and non object oriented languages as well.

Key characteristics of SOM in support of these key commercial requirements include:

• the ability to create portable shrink wrapped binaries

• the ability to create class libraries in one language that can be accessed and used by other languages

• the ability to subclass from binaries even if they were written in a different language

• the ability to add new methods and relocate existing methods without re-compilation of the application

• the ability to insert new classes into the inheritance hierarchy without recompiling the application.

Objects

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.

Operations

The interface to a 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 objects behavior.

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.

Messages

Messages are not explicitly identified in SOM.

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. The semantics of

the operations on an object are defined by the methods that implement these operations.

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.

The "offset resolution" mechanism implies a static scheme for typing objects and is

roughly equivalent to the C++ virtual function concept. It offers the best performance

characteristics for SOM method resolution at a cost of some loss in flexibility.

This form of method resolution supports polymorphism that is based on the derivation of

the object's class. Name resolution supports access to objects whose class is not known at

compile time, and permits polymorphism based on the protocols that an object supports,

rather than its derivation.

The "dispatch function" resolution is a feature of SOM that permits method resolution to

be based on arbitrary rules known only in the domain of the receiving object. Dispatch

function resolution is a completely dynamic mechanism that permits run time type

checking, and open-ended forms of polymorphism. A distinguishing feature of SOM is

that all 3 forms of method resolution are complementary and can be intermixed within

client programs.

State

The state of SOM objects is accessed through published interfaces to an object. Invoking

operations on objects may cause state changes.

Object lifetime

SOM objects are created by invoking a create operation on a factory object in the SOM

run time. Once created, the object will exist until explicitly deleted or until the process

that created it no longer exists. A SOM object would need to make use of a persistence

mechanism in order to exist beyond the life of the process that created it. A persistence

mechanism is beyond the scope of this object model discussion, however, SOM could be

and has been used as the basis for building a variety of persistence frameworks.

Behavior/state grouping

SOM uses the classical object model in that a target object must be specified for each

operation.

Communication model

Since SOM is a basic mechanism, its run-time model is one where an operation occurs on

a single thread within a single process. However, SOM code permits concurrent

execution by multiple threads on systems where SOM supports the underlying threads

model, therefore, multi-threaded programs can use mutual exclusion mechanisms to

serialize updates to SOM objects with confidence that critical sections in SOM are thread

safe.

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 thread, single

process model. A class library based on SOM is used to provide SOM with distributed

access to remote SOM objects.

Binding

SOM provides support for both early and late binding. These binding choices are on a per

method bases.

Polymorphism

The polymorphism provided by SOM depends on the method dispatching scheme

selected. If "offset resolution" is used then a static scheme for typing objects is used and

polymorphism is based strictly on class inheritance. If the "name resolution" method

dispatching is used then methods are located dynamically and polymorphism is based on

the actual protocols that objects honor.

Encapsulation

Access to the state of SOM objects is through the operations that makeup the objects

interface. Invoking operations on SOM objects can have side effects. SOM objects do

have private data that is not accessible by invoking external operations. In addition, it is

possible to define class attributes on SOM objects. These attributes are accessed via set

and get functions implemented for each attribute and are invoked in the same way as

methods.

Identity, Equality, Copy

When a SOM object is created the SOM run-time returns a pointer to the object. It is left

to higher level abstractions which build on SOM to define object identity, equality and

copy operations.

Types and Classes

The SOM description for "types and classes" is essentially the same as that described in

the OODBTG Reference Model entry in this section in that a "type" defines a protocol

shared by a group of objects, called "instances" of the type and a class defines an

implementation shard by a group of objects.

In SOM, all objects are derived from a SOM root object which defines the essential

behavior common to all SOM objects. In addition, SOM has a root class for all SOM

meta classes which defines the essential behavior common to all SOM classes. The SOM

meta classes define factory methods that manufacture objects of any class for which they

are the meta class.

Inheritance and Delegation

A class defines both an interface and an implementation for objects. The interface defines the

signature of the methods supported by objects of the class, and the implementation defines what

instance variables implement the object's state and what procedures implement its methods. New

classes are derived by sub-classing from previously existing classes through inheritance and

specialization. Subclasses inherit their interfaces and implementations from their parent classes

unless they are overridden. SOM supports multiple inheritance. That is, a class may be derived

from multiple parent classes.

Noteworthy Objects

SOM has three important objects which exist as part of the run time environment. The first is a

root object from which all SOM objects are derived. This root object defines the essential

behavior common to all SOM objects.

The second object is the root class object which defines the essential behavior common to all

SOM classes. All SOM classes are expected to have this class object or some class derived from

it as their meta class. This object carries the methods which serve as factory objects. The third

object is a class manager. It serves as a run time registry for all SOM class objects that have been

created or dynamically loaded by the current process.

Attributes

SOM classes support attributes. An attribute can be thought of as an instance variable that

has accompanying "get" and "set” methods. The get and set methods are invoked the

same way as other methods.

Literals

SOM literal types are characters and integers.

Containment

SOM is a basic technology and therefore does not have a notion of one object containing

another. However, since SOM is a library packaging technology it supports the

construction of SOM objects which can contain other SOM objects.

Aggregates

Aggregation is used in SOM to represent collections of basic data types. The aggregation

types as expressed in C are struct, union and enum.

Extensibility

In SOM, all new classes are defined in terms of a previously existing class. New methods

can be added and old methods can be overridden. Methods can also be relocated upward

in the hierarchy without requiring-compilation of the application. Source code is not

required for sub-classing since the binaries can be used for this purpose. This sub-

classing from binaries even extends to languages other than the one the binaries were

written in.

Dynamic

SOM is dynamic in that the class binaries can be replaced without having to re-compiled

the application.

Metaclasses/metaobject protocol

In SOM all classes are real objects. SOM supports a class object which represents the

meta class for the creation of all SOM classes. The SOM meta class defines the behavior

common to all class objects. Since it inherits from the root SOM object it exists at run

time and contains the methods for manufacturing object instances. It also has the methods

used to dynamically obtain information about a class and its methods at run time.

Object Languages

SOM is designed to work with a variety of programming languages. SOM supports an

interface definition language to define interfaces and data. The IDL is then compiled

(pre-compiler) and linked with the application. This does not preclude the use of a

languages' object model in the same application. The use of SOM with a procedural

language provides that language with object oriented capabilities.

Portable Object Adapter (POA) The CORBA object responsible for splitting the server side remote invocation handler

into the remote Object and its Servant. The object is exposed for the remote invocations,

while the servant contains the methods that are actually handling the requests. The

Servant for each object can be chosen either statically (once) or dynamically (for each

remote invocation), in both cases allowing the call forwarding to another server.

On the server side, the POAs form a tree-like structure, where each POA is responsible

for one or more objects being served. The branches of this tree can be independently

activated/deactivated, have the different code for the servant location or activation and

the different request handling policies.

An object adapter is the mechanism that connects a request using an object reference

with the proper code to service that request. The Portable Object Adapter, or POA, is a

particular type of object adapter that is defined by the CORBA specification. The POA is

designed to meet the following goals:

• Allow programmers to construct object implementations that are portable between

different ORB products.

• Provide support for objects with persistent identities.

• Provide support for transparent activation of objects.

• Allow a single servant to support multiple object identities simultaneously.

Creating and Using the POA

The steps for creating and using a POA will vary according to the specific application

being developed. The following steps generally occur during the POA life cycle:

1. Get the root POA

2. Define the POA's policies

3. Create the POA

4. Activate the POAManager

5. Activate the servants, which may include activating the Tie

6. Create the object reference from the POA

Step 1: Get the root POA The first step is to get the first POA, which is called the rootPOA. The root POA is

managed by the ORB and provided to the application using the ORB initialization

interface under the initial object name "RootPOA". An example of code that will get the

root POA object and cast it to a POA is:

ORB orb = ORB.init( args, null ); POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));

Step 2: Define the POA's Policies The Portable Object Adapter (POA) is designed to provide an object adapter that can be

used with multiple ORB implementations with no rewriting needed to deal with different

vendors' implementations.

The POA is also intended to allow persistent objects -- at least, from the client's

perspective. That is, as far as the client is concerned, these objects are always alive, and

maintain data values stored in them, even though physically, the server may have been

restarted many times. The POA allows the object implementer a lot more control over the

object's identity, state, storage, and life cycle. You can create a POA without defining any

policies and the default values will be used. The root POA has the following policies by

default:

• Thread Policy: ORB_CTRL_MODEL

• Lifespan Policy: TRANSIENT

• Object Id Uniqueness Policy: UNIQUE_ID

• Id Assignment Policy: SYSTEM_ID

• Servant Retention Policy: RETAIN

• Request Processing Policy: USE_ACTIVE_OBJECT_MAP_ONLY

• Implicit Activation Policy: IMPLICIT_ACTIVATION

The following code snippet shows how policies are set in the RMI-IIOP (with POA)

example:

Policy[] tpolicy = new Policy[3]; tpolicy[0] = rootPOA.create_lifespan_policy( LifespanPolicyValue.TRANSIENT ); tpolicy[1] = rootPOA.create_request_processing_policy( RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY ); tpolicy[2] = rootPOA.create_servant_retention_policy( ServantRetentionPolicyValue.RETAIN);

Step 3: Create the POA Creating a new POA allows the application developer to declare specific policy choices

for the new POA and to provide a different adapter activator and servant manager (these

are callback objects used by the POA to activate POAs on demand and activate servants).

Creating new POAs also allows the application developer to partition the name space of

objects, as Object Ids are interpreted relative to a POA. Finally, by creating new POAs,

the developer can independently control request processing for multiple sets of objects. A

POA is created as a child of an existing POA using the create_POA operation on the

parent POA. To create a new POA, pass in the following information:

• Name of the POA - The POA is given a name that must be unique with respect to

all other POAs with the same parent. In the following example, the POA is named

childPOA.

• POA Manager - Specify the POA Manager to be associated with the new POA.

If, as is shown in the following example, null is passed for this parameter, a new

POA Manager will be created. The user can also choose to pass the POA Manager

of another POA.

• Policy List - Specify the policy list to be associated with the POA to control its

behavior. In the following example, a persistent lifespan policy has already been

defined for this POA.

The following code snippet shows how the POA is created :

// Create a POA by passing the Persistent Policy

POA persistentPOA = rootPOA.create_POA("childPOA", null,

persistentPolicy );

Step 4: Activate the POAManager Each POA object has an associated POAManager object that controls the processing state

of the POAs with which it is associated, such as whether requests to the POA are queued

or discarded. The POAManager can also deactivate the POA. A POA Manager may be

associated with one or more POA objects. The POAManager can have the following states:

• Holding - In this state, associated POAs will queue incoming requests.

• Active - In this state, associated POAs will start processing requests.

• Discarding - In this state, associated POAs will discard incoming requests.

• Inactive - In this state, associated POAs will reject the requests that have not

begun executing as well as as any new requests.

POA Managers are not automatically activated when they are created. The following

code snippet shows how the POAManager is activated . If the POA Manager is not

activated in this way, all calls to the Servant will hang because, by default, the POA

Manager is in the HOLD state.

// Activate PersistentPOA's POAManager. Without this step, // all calls to Persistent Server will hang because POAManager // will be in the 'HOLD' state. persistentPOA.the_POAManager().activate( );

Step 5: Activate the servants

At any point in time, a CORBA object may or may not be associated with an active

servant. If the POA has the RETAIN policy, the servant and its associated Object Id are

entered into the Active Object Map of the appropriate POA. This type of activation can

be accomplished in one of the following ways.

• The server application itself explicitly activates individual objects (via the

activate_object or activate_object_with_id operations).

• The server application instructs the POA to activate objects on demand by having the

POA invoke a user-supplied servant manager. The server application registers this

servant manager with set_servant_manager.

• Under some circumstances (when the IMPLICIT_ACTIVATION policy is also in effect

and the language binding allows such an operation), the POA may implicitly activate

an object when the server application attempts to obtain a reference for a servant that

is not already active (that is, not associated with an Object Id).

If the USE_DEFAULT_SERVANT policy is also in effect, the server application instructs the

POA to activate unknown objects by having the POA invoke a single servant no matter

what the Object Id is. The server application registers this servant with set_servant.

If the POA has the NON_RETAIN policy, for every request, the POA may use either a

default servant or a servant manager to locate an active servant. From the POA's point of

view, the servant is active only for the duration of that one request. The POA does not

enter the servant-object association into the Active Object Map.

When using RMI-IIOP technology, your implementations use delegation (known as the

Tie model) to associate your implementation with the interface. When you create an

instance of your implementation, you also need to create a Tie object to associate it with

a CORBA interface. The following code snippet shows how to activate the Tie, if the

POA policy is USE_ACTIVE_OBJECT_MAP_ONLY. This sample code is from the RMI-IIOP

with POA example.

_HelloImpl_Tie tie = (_HelloImpl_Tie)Util.getTie( helloImpl ); String helloId = "hello"; byte[] id = helloId.getBytes(); tPOA.activate_object_with_id( id, tie );

Step 6: Create the object reference

Object references are created in servers. Once created, they may be exported to clients.

Object references encapsulate object identity information and information required by the

ORB to identify and locate the server and the POA with which the object is associated.

References are created in the following ways:

• Explicitly activate a servant and associate it with an object reference.

The following example is from Hello World: Persistent Server. This example uses

the servant_to_reference operation to map an activated servant to its

corresponding object reference.

// Resolve Root Naming context and bind a name for the // servant. org.omg.CORBA.Object obj = orb.resolve_initial_references( "NameService" ); NamingContextExt rootContext = NamingContextExtHelper.narrow( obj ); NameComponent[] nc = rootContext.to_name( "PersistentServerTutorial" ); rootContext.rebind( nc, persistentPOA.servant_to_reference( servant ) );

• Server application directly creates a reference.

The following example is from the RMI-IIOP with POA example. In this

example, the following code directly creates a reference. In doing so, they bring

the abstract object into existence, but do not associate it with an active servant.

// Publish the object reference using the same object id // used to activate the Tie object. Context initialNamingContext = new InitialContext(); initialNamingContext.rebind("HelloService", tPOA.create_reference_with_id(id, tie._all_interfaces(tPOA,id)[0]) );

• Server application causes a servant to implicitly activate itself.

The behavior can occur only if the POA has been created with the

IMPLICIT_ACTIVATION policy, which is the default behavior. Once an reference is

created in the server, it can be made available to clients.

The ORB The IBM ORB ships with the JVM and is used by the IBM WebSphere Application

Server. It is one of the enterprise features of the Java 2 Standard Edition. The ORB is a

tool and runtime component that provides distributed computing through the OMG-

defined CORBA IIOP communication protocol. The ORB runtime consists of a Java

implementation of a CORBA ORB. The ORB toolkit provides APIs and tools for both

the RMI programming model and the IDL programming model.

This separation of interface from implementation, enabled by OMG IDL, is the essence

of CORBA - how it enables interoperability, with all of the transparencies we've claimed.

The interface to each object is defined very strictly. In contrast, the implementation of an

object - its running code, and its data - is hidden from the rest of the system (that is,

encapsulated) behind a boundary that the client may not cross. Clients access objects

only through their advertised interface, invoking only those operations that that the object

exposes through its IDL interface, with only

those parameters (input and

output) that are included in the invocation

Figure 1 shows how everything fits together, at least within a single process: You

compile your IDL into client stubs and object skeletons, and write your object (shown on

the right) and a client for it (on the left). Stubs and skeletons serve as proxies for clients

and servers, respectively. Because IDL defines interfaces so strictly, the stub on the

client side has no trouble meshing perfectly with the skeleton on the server side, even if

the two are compiled into different programming languages, or even running on different

ORBs from different vendors.

In CORBA, every object instance has its own unique object reference, an identifying

electronic token. Clients use the object references to direct their invocations, identifying

to the ORB the exact instance they want to invoke (Ensuring, for example, that the books

you select go into your own shopping cart, and not into your neighbor's.) The client acts

as if it's invoking an operation on the object instance, but it's actually invoking on the

IDL stub which acts as a proxy. Passing through the stub on the client side, the invocation

continues through the ORB (Object Request Broker), and the skeleton on the

implementation side, to get to the object where it is executed. The CORBAservices

provide standard ways of passing object references around your network of CORBA

objects. Location Transparency keeps your applications flexible.

How do remote invocations work?

Figure 2 diagrams a remote invocation. In order to invoke the remote object instance, the

client first obtains its object reference. (There are many ways to do this, but we won't

detail any of them here. Easy ways include the Naming Service and the Trader Service.)

To make the remote invocation, the client uses the same code that it used in the local

invocation we just described, substituting the object reference for the remote instance.

When the ORB examines the object reference and discovers that the target object is

remote, it routes the invocation out over the network to the remote object's ORB. (Again

we point out: for load balanced servers, this is an oversimplification.)

How does this work?

OMG has standardized this process at two key levels: First, the client knows the type of

object it's invoking (that it's a shopping cart object, for instance), and the client stub and

object skeleton are generated from the same IDL. This means that the client knows

exactly which operations it may invoke, what the input parameters are, and where they

have to go in the invocation; when the invocation reaches the target, everything is there

and in the right place. We've already seen how OMG IDL accomplishes this. Second, the

client's ORB and object's ORB must agree on a common protocol - that is, a

representation to specify the target object, operation, all parameters (input and output) of

every type that they may use, and how all of this is represented over the wire. OMG has

defined this also - it's the standard protocol IIOP. (ORBs may use other protocols besides

IIOP, and many do for various reasons. But virtually all speak the standard protocol IIOP

for reasons of interoperability, and because it's required by OMG for compliance.)

Although the ORB can tell from the object reference that the target object is remote, the

client can not. (The user may know that this also, because of other knowledge - for

instance, that all accounting objects run on the mainframe at the main office in Tulsa.)

There is nothing in the object reference token that the client holds and uses at invocation

time that identifies the location of the target object. This ensures location transparency -

the CORBA principle that simplifies the design of distributed object computing

applications.That ORB/Skeleton Architecture on the Server side doesn't look very

scalable. What did you leave out?

Using the ORB

To use the ORB, you need to understand the properties that the ORB contains. These

properties change the behavior of the ORB.

How the ORB works

This description explains the client side, and describes what the ORB does under the

cover and transparently to the client. Then, the important role of the ORB in the server

side is explained. This section describes a basic, typical RMI-IIOP session in which a

client accesses a remote object on a server implementing an interface named Sample. The

client then invokes a simple method called message(). The method returns a "Hello

World" string.

The client side

The client side operation of the ORB is described.

1. Stub creation:

In a simple distributed application, the client needs to know (in almost all the

cases) what object it is going to contact, and which method of this object it needs

to call. Because the ORB is a general framework, you must give it general

information about the method that you want to call.

2. ORB initialization:

In a stand-alone Java application, the client has to create an instance of the ORB.

3. Obtaining the remote object

Several methods exist by which the client can get a reference for the remote

object.

4. Remote method invocation:

The client holds a reference to the remote object that is an instance of the stub

class. The next step is to call the method on that reference. The stub implements

the Sample interface and therefore contains the message() method that the client

has called.

Stub creation

In a simple distributed application, the client needs to know (in almost all the cases) what

object it is going to contact, and which method of this object it needs to call. Because the

ORB is a general framework, you must give it general information about the method that

you want to call. For this reason, you implement a Java interface, Sample, which contains

the signatures of the methods that can be called in the remote object.

The client relies on the existence of a server that contains an object that is that Sample

interface. You must, therefore, create a proxy. This proxy is an object, called stub that

acts as an interface between client application and ORB.To create the stub, run the RMIC

compiler on the Java interface:

rmic -iiop Sample

This command generates a file and object named _Sample_Stub.class.

The presence of a stub is not always mandatory for a client application to operate. When

you use particular CORBA features such as the DII (Dynamic Invocation Interface), you

do not require a stub. The reason is that the proxy code is implemented directly by the

client application. You can also upload a stub from the server to which you are trying to

connect. See the CORBA specification for further details

ORB initialization

In a stand-alone Java application, the client has to create an instance of the ORB. This

instance is created by calling the static method init(...); for example:

ORB orb = ORB.init(args,props);

The parameters that are passed to the method are:

• A string array that contains property-value pairs

• A Java Properties object

For an applet, a similar method is used in which a Java Applet is passed instead of the

string array. The first step of the ORB initialization is the processing of the ORB

properties. The properties are processed in the following sequence:

1. Check in the applet parameter or application string array

2. Check in the properties parameter (if the parameter exists)

3. Check in the system properties

4. Check in the orb.properties file that is in the <user-home> directory (if the file

exists)

5. Check in the orb.properties file that is in the <java-home>/lib directory (if the file

exists)

6. Fall back on a hardcoded default behavior

The two properties ORBClass and ORBSingletonClass determine which ORB class has

to be instantiated. After this, the ORB starts and initializes the TCP transport layer. If the

ListenerPort property was set, the ORB also opens a server socket that is listening for

incoming requests, as a server-side ORB usually does. At the end of the init() method, the

ORB is fully functional and ready to support the client application.

Obtaining the remote object

Several methods exist by which the client can get a reference for the remote object.

Typically, this reference is a string, called an IOR (Interoperable Object Reference). For

example:

IOR:000000000000001d524d493a5......

This reference contains all the information needed to find the remote object. It also

contains some details of the settings of the server to which the object belongs. The client

ORB is not supposed to understand the details of the IOR, but to use it as a key. In other

words, the IOR is a reference to the remote object. However, when client and server are

both using an IBM ORB, extra features are coded in the IOR. For example, the IBM

ORB adds a proprietary field into the IOR, called IBM_PARTNER_VERSION. This

field holds a value like the following example:

49424d0a 00000008 00000000 1400 0005 where:

• The three initial bytes (from left to right) are the ASCII code for IBM, followed

by 0x0A, which specifies that the following bytes handle the partner version.

• The next 4 bytes encode the length of the remaining data (in this case 8 bytes)

• The next 4 null bytes are for future use.

• The 2 bytes for the Partner Version Major field (0x1400 in this example) define

the release of the ORB that is being used (1.4.0 in this case).

• The Minor field (0x0005) distinguishes in the same release, service refreshes that

contain changes that have affected the compatibility with earlier versions.

Because the IOR is not visible to application-level ORB programmers and the client ORB

does not know where to look for it, there is one more step, called the bootstrap process.

Basically, the client application needs to tell the ORB where the remote object reference

is located.

A typical example of bootstrapping is if you use a naming service: the client calls the

ORB method resolve_initial_references("NameService"), which returns (after narrowing)

a reference to the name server in the form of a NamingContext object. The ORB looks

for a name server in the local machine at the port 2809 (as default). If no name server

exists, or the name server is listening on another port, the ORB returns an exception. The

client application can specify a different host, port, or both by using the -ORBInitRef

and -ORBInitPort options.

Using the NamingContext and the name with which the Remote Object has been bound

in the name service, the client can retrieve a reference to the remote object. The reference

to the remote object that the client holds is always an instance of a Stub object; for

example _Sample_Stub.

ORB.resolve_initial_references() causes much system activity. The ORB starts by

creating a remote communication with the name server. This communication might

include several requests and replies. Typically, the client ORB first checks whether a

name server is listening, then asks for the specified remote reference. In an application

where performance is considered important, caching the remote reference is a better

alternative to repetitive use of the naming service. However, because the naming service

implementation is a transient type, the validity of the cached reference is tied to the time

in which the naming service is running. The IBM ORB implements an Interoperable

Naming Service as described in the CORBA 2.3 specification. This service includes a

new string format that can be passed as a parameter to the ORB methods

string_to_object() and resolve_initial_references(). By calling the previous two methods

where the string parameter has a corbaloc (or corbaname) format as, for example:

corbaloc:iiop:1.0@aserver.aworld.aorg:1050/AService

the client ORB uses GIOP 1.0 to send a request with a simple object key of AService to

port 1050 at host aserver.aworld.aorg. There, the client ORB expects to find a server for

the Aservice that is requested, and returns a reference to itself. You can then use this

reference to look for the remote object. This naming service is transient. It means that the

validity of the contained references expires when the name service or the server for the

remote object is stopped.

Remote method invocation

The client holds a reference to the remote object that is an instance of the stub class. The

next step is to call the method on that reference. The stub implements the Sample

interface and therefore contains the message() method that the client has called.

First, the stub code determines whether the implementation of the remote object is

located on the same ORB instance. If so, the object can be accessed without using the

Internet.

If the implementation of the remote object is located on the same ORB instance, the

performance improvement can be significant because a direct call to the object

implementation is done. If no local servant can be found, the stub first asks the ORB to

create a request by calling the _request() method, specifying the name of the method to

call and whether a reply is expected or not.

The CORBA specification imposes an extra layer of indirection between the ORB code

and the stub. This layer is commonly known as delegation. CORBA imposes the layer

using an interface named Delegate. This interface specifies a portable API for ORB-

vendor-specific implementation of the org.omg.CORBA.Object methods. Each stub

contains a delegate object, to which all org.omg.CORBA.Object method invocations are

forwarded. The delegate object allows a stub that is generated by the ORB from one

vendor to work with the delegate from the ORB of another vendor.

When creating a request, the ORB first checks whether the enableLocateRequest property

is set to true, in which case, a LocateRequest is created. The steps of creating this request

are like the full Request case.

The ORB obtains the IOR of the remote object (the one that was retrieved by a naming

service, for example) and passes the information that is contained in the IOR (Profile

object) to the transport layer.

The transport layer uses the information that is in the IOR (IP address, port number, and

object key) to create a connection if it does not exist. The ORB TCP/IP transport has an

implementation of a table of cached connections for improving performances, because

the creation of a new connection is a time-consuming process. The connection is not an

open communication channel to the server host. It is only an object that has the potential

to create and deliver a TCP/IP message to a location on the Internet. Typically, that

involves the creation of a Java™ socket and a reader thread that is ready to intercept the

server reply. The ORB.connect() method is called as part of this process.

When the ORB has the connection, it proceeds to create the Request message. The

message contains the header and the body of the request. The CORBA 2.3 specification

specifies the exact format. The header contains these items, for example:

• Local IP address

• Local port

• Remote IP address

• Remote port

• Message size

• Version of the CORBA stream format

• Byte sequence convention

• Request types

• Ids

The body of the request contains several service contexts and the name and parameters of

the method invocation. Parameters are typically serialized. A service context is some

extra information that the ORB includes in the request or reply, to add several other

functions. CORBA defines a few service contexts, such as the codebase and the codeset

service contexts. The first is used for the callback feature which is described in the

CORBA specification, the second is used to specify the encoding of strings.

In the next step, the stub calls _invoke(). Again, it is the delegate invoke() method that is

executed. The ORB in this chain of events calls the send() method on the connection that

writes the request to the socket buffer and then flushes it away. The delegate invoke()

method waits for a reply to arrive. The reader thread that was spun during the connection

creation gets the reply message, demarshals it, and returns the correct object.

The server side

Typically, a server is an application that makes available one of its implemented objects

through an ORB instance.

Servant implementation

The implementations of the remote object can either inherit from

javax.rmi.PortableRemoteObject, or implement a remote interface and use the

exportObject() method to register themselves as a servant object. In both cases, the

servant has to implement the Sample interface. Here, the first case is described. From

now, the servant is called SampleImpl.

Tie generation

Again, you must put an interfacing layer between the servant and the ORB code. In the

old RMI(JRMP) naming convention, skeleton was the name given to the proxy that was

used on the server side between ORB and the object implementation. In the RMI-IIOP

convention, the proxy is called a Tie.

You generate the RMI-IIOP tie class at the same time as the stub, by calling the rmic

compiler. These classes are generated from the compiled Java™ programming language

classes that contain remote object implementations. For example, the command:

rmic -iiop SampleImpl

Servant binding

The steps required to bind the servant are described. The server implementation is

required to do the following tasks:

1. Create an ORB instance; that is, ORB.init(...)

2. Create a servant instance; that is, new SampleImpl(...)

3. Create a Tie instance from the servant instance; that is, Util.getTie(...)

4. Export the servant by binding it to a naming service

As described for the client side, you must create the ORB instance by calling the ORB

static method init(...). The typical steps for that method are:

1. Retrieve properties

2. Get the system class loader

3. Load and instantiate the ORB class as specified in the ORBClass property

4. Initialize the ORB as determined by the properties

Then, the server needs to create an instance of the servant class SampleImpl.class.

Something more than the creation of an instance of a class happens under the cover.

Remember that the servant SampleImpl extends the PortableRemoteObject class, so the

constructor of PortableRemoteObject is executed. This constructor calls the static method

exportObject(...) with the parameter that is the same servant instance that you try to

instantiate. If the servant does not inherit from PortableRemoteObject, the application

must call exportObject() directly.

The exportObject() method first tries to load an RMI-IIOP tie. The ORB implements a

cache of classes of ties for improving performance. If a tie class is not already cached, the

ORB loads a tie class for the servant. If it cannot find one, it goes up the inheritance tree,

trying to load the parent class ties. The ORB stops if it finds a PortableRemoteObject

class or the java.lang.Object, and returns a null value. Otherwise, it returns an instance of

that tie from a hashtable that pairs a tie with its servant. If the ORB cannot get hold of the

tie, it guesses that an RMI (JRMP) skeleton might be present and calls the exportObject()

method of the UnicastRemoteObject class. A null tie is registered in the cache and an

exception is thrown. The servant is now ready to receive remote methods invocations.

However, it is not yet reachable.

In the next step, the server code has to get hold of the tie itself (assuming the ORB has

already got hold of the tie) to be able to export it to a naming service. To do that, the

server passes the newly created instance of the servant into the static method

javax.rmi.CORBA.Util.getTie(). This method, in turn, fetches the tie that is in the

hashtable that the ORB created. The tie contains the pair of tie-servant classes.

When in possession of the tie, the server must get hold of a reference for the naming

service and bind the tie to it. As in the client side, the server calls the ORB method

resolve_initial_references("NameService"). The server then creates a NameComponent,

which is a directory tree object identifying the path and the name of the remote object

reference in the naming service. The server binds the NameComponent together with the

tie. The naming service then makes the IOR for the servant available to anyone

requesting. During this process, the server code sends a LocateRequest to get hold of the

naming server address. It also sends a Request that requires a rebind operation to the

naming server.

Processing a request

The server ORB uses a single listener thread, and a reader thread for each connection or

client, to process an incoming message. During the ORB initialization, a listener thread

was created. The listener thread is listening on a default port (the next available port at

the time the thread was created). You can specify the listener port by using the

com.ibm.CORBA.ListenerPort property. When a request comes in through that port, the

listener thread first creates a connection with the client side. In this case, it is the TCP

transport layer that takes care of the details of the connection. As seen for the client side,

the ORB caches all the connections that it creates.

By using the connection, the listener thread spawns a reader thread to process the

incoming message. When dealing with multiple clients, the server ORB has a single

listener thread and one reader thread for each connection or client.

The reader thread does not fully read the request message, but instead creates an input

stream for the message to be piped into. Then, the reader thread picks up one of the

worker threads in the implemented pool (or creates one if none is present), and delegates

the reading of the message. The worker threads read all the fields in the message and

dispatch them to the tie, which unmarshals any parameters and calls the remote method.

The service contexts are then created and written to the response output stream with the

return value. The reply is sent back with a similar mechanism, as described in the client

side. After that, the connection is removed from the reader thread which eventually stops.

Additional features of the ORB

Portable object adapter, fragmentation, portable interceptors, and Inoperable Naming

Service are described. This section describes:

• Portable object adapter

• Fragmentation

• Portable interceptors

• Interoperable Naming Service (INS)

Portable object adapter

An object adapter is the primary method for an object to access ORB services such as

object reference generation. An object adapter exports a public interface to the object

implementation and a private interface to the skeleton.

The main responsibilities of an object adapter are:

• Generation and interpretation of object references

• Method invocation

• Object and implementation activation and deactivation

• Mapping object references to the corresponding object implementations

In CORBA 2.1 and below, all ORB vendors had to implement an object adapter, which

was known as the basic object adapter. Because the basic object adapter was never

completely specified with a standard CORBA IDL, vendors implemented it in many

different ways. Therefore, for example, programmers could not write server

implementations that could be truly portable between different ORB products. A first

attempt to define a standard object adapter interface was done in CORBA 2.1. With

CORBA v.2.3, the OMG group released the final corrected version for a standard

interface for the object adapter. This adapter is known as the portable object adapter

(POA). Some of the main features of the POA specification are:

• Allow programmers to construct object and server implementations that are

portable between different ORB products.

• Provide support for persistent objects; that is, objects that have a lifetime span of

multiple server lifetimes.

• Support transparent activation of objects and the ability to associate policy

information to objects.

• Allow multiple distinct instances of the POA to exist in one ORB.

Since IBM® SDK for Java v1.4, the ORB supports both the POA specification and the

proprietary basic object adapter that is already present in previous IBM ORB versions. As

default, the rmic compiler, when used with the -iiop option, generates RMI-IIOP ties for

servers. These ties are based on the basic object adapter. When a server implementation

uses the POA interface, you must add the -poa option to the rmic compiler to generate

the relevant ties.

If you want to implement an object that is using the POA, the server application must

obtain a POA object. When the server application calls the ORB method

resolve_initial_reference("RootPOA"), the ORB returns the reference to the main POA

object that contains default policies (see the CORBA specification for a complete list of

all the POA policies). You can create new POAs as child objects of the RootPOA, and

these child objects can contain different policies. This in turn allows you to manage

different sets of objects separately, and to partition the namespace of objects IDs.

Ultimately, a POA handles Object IDs and active servants. An active servant is a

programming object that exists in memory and has been registered with the POA by use

of one or more associated object identities. The ORB and POA cooperate to determine on

which servant the client-requested operation should be started. By using the POA APIs,

you can create a reference for the object, associate an object ID, and activate the servant

for that object. A map of object IDs and active servants is stored inside the POA. A POA

also provides a default servant that is used when no active servant has been registered.

You can register a particular implementation of this default servant and also of a servant

manager, which is an object for managing the association of an object ID with a

particular servant.

The POA Manager is an object that encapsulates the processing state of one or more

POAs. You can control and change the state of all POAs by using operations on the POA

manager. The adapter activator is an object that an application developer uses to activate

child POAs.

Fragmentation

The CORBA specification introduced the concept of fragmentation to handle the growing

complexity and size of marshalled objects in GIOP messages. Graphs of objects are

linearized and serialized inside a GIOP message under the IDL specification of

valuetypes. Fragmentation specifies the way a message can be split into several smaller

messages (fragments) and sent over the net.

The system administrator can set the ORB properties FragmentSize and

FragmentTimeout to obtain best performance in the existing net traffic. As a general

rule, the default value of 1024 bytes for the fragment size is a good trade-off in almost all

conditions. The fragment timeout must not be set to too low a value, or time-outs might

occur unnecessarily.

Portable interceptors

For some time, CORBA implementations have had non-standard mechanisms that allow

users to insert their own code into the ORB's flow of execution. This code, known as

interceptors, is called at particular stages during the processing of requests. It can directly

inspect and even manipulate requests. Because this message filtering mechanism is

extremely flexible and powerful, the OMG standardized interceptors in the CORBA 2.4.2

specification under the name "portable interceptors".

The idea of a portable interceptor is to define a standard interface to register and execute

application-independent code that, among other things, takes care of passing service

contexts. These interfaces are stored in the package org.omg.PortableInterceptor.* . The

implementation classes are in the com.ibm.rmi.pi.* package of the IBM® ORB. All the

interceptors implement the Interceptor interface.

Two classes of interceptors are defined: request interceptors and IOR (Interoperable

Object Reference) interceptors. Request interceptors are called during request mediation.

IOR interceptors are called when new object references are created so that service-

specific data can be added to the newly-created IOR in the form of tagged components.

The ORB calls request interceptors on the client and the server side to manipulate service

context information. Interceptors must register with the ORB for those interceptor points

that are to be executed.

Five interception points are on the client side:

• send_request (sending request)

• send_poll (sending request)

• receive_reply (receiving reply)

• receive_exception (receiving reply)

• receive_other (receiving reply)

Five interception points are on the server side:

• receive_request_service_contexts (receiving request)

• receive_request (receiving request)

• send_reply (sending reply)

• send_exception (sending reply)

• send_other (sending reply)

The only interceptor point for IOR interceptors is establish_component. The ORB calls

this interceptor point on all its registered IOR interceptors when it is assembling the set of

components that is to be included in the IOP profiles for a new object reference.

Registration of interceptors is done using the interface ORBInitializer.

Example: public class MyInterceptor extends org.omg.CORBA.LocalObject implements ClientRequestInterceptor, ServerRequestInterceptor {

public String name() { return "MyInterceptor"; } public void destroy() {} // ClientRequestInterceptor operations public void send_request(ClientRequestInfo ri) { logger(ri, "send_request"); } public void send_poll(ClientRequestInfo ri) { logger(ri, "send_poll"); } public void receive_reply(ClientRequestInfo ri) { logger(ri, "receive_reply"); } public void receive_exception(ClientRequestInfo ri) { logger(ri, "receive_exception"); } public void receive_other(ClientRequestInfo ri) { logger(ri, "receive_other"); } // Server interceptor methods public void receive_request_service_contexts(ServerRequestInfo ri) { logger(ri, "receive_request_service_contexts"); } public void receive_request(ServerRequestInfo ri) { logger(ri, "receive_request"); } public void send_reply(ServerRequestInfo ri) { logger(ri, "send_reply"); } public void send_exception(ServerRequestInfo ri) { logger(ri, "send_exception"); } public void send_other(ServerRequestInfo ri) { logger(ri, "send_other"); } // Trivial Logger public void logger(RequestInfo ri, String point) { System.out.println("Request ID:" + ri.request_id() + " at " + name() + "." + point); } }

The interceptor class extends org.omg.CORBA.LocalObject to ensure that an instance of

this class does not get marshaled, because an interceptor instance is strongly tied to the

ORB with which it is registered. This trivial implementation prints out a message at every

interception point.

You can register the interceptor by using an ORB Initializer. Because interceptors are

intended to be a means by which ORB services access ORB processing, by the time the

init() method call on the ORB class returns an ORB instance, the interceptors have

already been registered. It follows that interceptors cannot be registered with an ORB

instance that is returned from the init() method call.

First, you must create a class that implements the ORBInitializer interface. This class

will be called by the ORB during its initialization:

public class MyInterceptorORBInitializer extends LocalObject

implements ORBInitializer

{

public static MyInterceptor interceptor;

public String name() {

return "";

}

public void pre_init(ORBInitInfo info) {

try {

interceptor = new MyInterceptor();

info.add_client_request_interceptor(interceptor);

info.add_server_request_interceptor(interceptor);

} catch (Exception ex) {}

}

public void post_init(ORBInitInfo info) {}

}

Then, in the server implementation, add the following code:

Properties p = new Properties();

p.put("org.omg.PortableInterceptor.ORBInitializerClass.pi.MyInte

rceptorORBInitializer", "");

orb = ORB.init((String[])null, p);

During the ORB initialization, the ORB runtime obtains the ORB properties that begin

with org.omg.PortableInterceptor.ORBInitializerClass;. The remaining portion is

extracted and the corresponding class is instantiated. Then, the pre_init() and post_init()

methods are called on the initializer object.

Interoperable Naming Service (INS)

The CORBA CosNaming Service observes the OMG Interoperable Naming Service

specification (INS, CORBA 2.3 specification). CosNaming stands for Common Object

Services Naming.

The name service maps names to CORBA object references. Object references are stored

in the namespace by name and each object reference-name pair is called a name binding.

Name bindings can be organized under naming contexts. Naming contexts are themselves

name bindings, and serve the same organizational function as a file system subdirectory

does. All bindings are stored under the initial naming context. The initial naming context

is the only persistent binding in the namespace.

This implementation includes a new string format that can be passed as a parameter to the

ORB methods string_to_object() and resolve_initial_references() such as the corbaname

and corbaloc formats.

Corbaloc URIs allow you to specify object references that can be contacted by IIOP or

found through ORB::resolve_initial_references(). This new format is easier to manipulate

than IOR. To specify an IIOP object reference, use a URI of the form (see the CORBA

2.4.2 specification for full syntax):

corbaloc:iiop:<host>:<port>/<object key>

For example, the following corbaloc URI specifies an object with key MyObjectKey that

is in a process that is running on myHost.myOrg.com listening on port 2809.

corbaloc:iiop:myHost.myOrg.com:2809/MyObjectKey

Corbaname URIs (see the CORBA 2.4.2 specification) cause string_to_object() to look

up a name in a CORBA naming service. They are an extension of the corbaloc syntax:

corbaname:<corbaloc location>/<object key>#<stringified name>

For example:

corbaname::myOrg.com:2050#Personal/schedule

where the portion of the reference up to the hash mark (#) is the URL that returns the root

naming context. The second part is the argument that is used to resolve the object on the

NamingContext. The INS specified two standard command-line arguments that provide a

portable way of configuring ORB::resolve_initial_references():

• -ORBInitRef takes an argument of the form <ObjectId>=<ObjectURI>. For

example, you can use the following command-line arguments:

-ORBInitRef NameService=corbaname::myhost.example.com

resolve_initial_references("NameService") returns a reference to the object with

key NameService available on myhost.example.com, port 2809.

• -ORBDefaultInitRef provides a prefix string that is used to resolve otherwise

unknown names. When resolve_initial_references() cannot resolve a name that

has been specifically configured (with -ORBInitRef), it constructs a string that

consists of the default prefix, a `/' character, and the name requested. The string is

then fed to string_to_object(). So, for example, with a command-line of:

-ORBDefaultInitRef corbaloc::myhost.example.com

a call to resolve_initial_references("MyService") returns the object reference that

is denoted by corbaloc::myhost.example.com/MyService.

CORBA Services

CORBA Naming Service

The Naming Service allows you to associate abstract names with CORBA objects and

allows clients to find those objects by looking up the corresponding names. This service

is both very simple and very useful. A server that holds a CORBA object binds a name

to the object by contacting the Naming Service. To obtain a reference to the object, a

client requests the Naming Service to look up the object associated with a specified

name. This is known as resolving the object name. The Naming Service provides

interfaces defined in IDL that allow servers to bind names to objects and clients to

resolve those names.

Most CORBA applications make some use of the Naming Service. Locating a particular

object is a common requirement in distributed systems and the Naming Service provides

a simple, standard way to do this.

The Interface to the Naming Service

The Naming Service maintains a database of names and the objects associated with them.

An association between a name and an object is called a binding. The IDL interfaces to

the Naming Service provide operations to access the database of bindings. For example,

you can create new bindings, resolve names, and delete existing bindings.

Format of Names in the Naming Service

In the CORBA Naming Service, names can be associated with two types of object: a

naming context or an application object. A naming context is an object in the Naming

Service within which you can resolve the names of other objects.

Naming contexts are organized into a naming graph, which may form a naming hierarchy

much like that of a filing system. Using this analogy, a name bound to a naming context

would correspond to a directory and a name bound to an application object would

correspond to a file.

The full name of an object, including all the associated naming contexts, is known as a

compound name. The first component of a compound name gives the name of a naming

context, in which the second component is accessed. This process continues until the last

component of the compound name has been reached.

The notion of a compound name is common in filing systems. For example, in UNIX,

compound names take the form /aaa/bbb/ccc; in Windows they take the form

C:\aaa\bbb\ccc. A compound name in the Naming Service takes a more abstract form:

an IDL sequence of name components. Name components are not simple strings. Instead,

a name component is defined as an IDL structure, of type CosNaming::NameComponent,

that holds two strings:

// IDL // In module CosNaming. typedef string Istring; struct NameComponent { Istring id; Istring kind; };

A name is a sequence of these structures:

typedef sequence<NameComponent> Name;

The id member of a NameComponent is a simple identifier for the object; the kind

member is a secondary way to differentiate objects and is intended to be used by the

application layer. For example, you could use the kind member to distinguish the type of

the object being referred to. The semantics you choose for this member are not

interpreted by OrbixNames.

Both the id and kind members of a NameComponent are used in name resolution. Two

names that differ only in the kind member of one NameComponent are considered to be

different names.

IDL Interfaces to the Naming Service

The IDL module CosNaming contains two interfaces that allow your applications to

access the Naming Service:

NamingContext Provides the operations that allow you to access the main features of the Naming Service, such as binding and resolving names.

BindingIterator Allows you to read each element in a list of bindings. Such a list may be returned by operations of the NamingContext interface.

CORBA Trader Service

A Trading Object Service allows an object to be registered with a description of its

functionality. This service greatly increases the scalability of distributed systems by

making services easier to locate. An example of a service that a client might search for is

a printer.

How clients and servers use a trader

A trader contains a number of service types that describe a service. For example, a printer

service type might have properties such as pages_per_minute (a long) and location (a

string). Service types are stored in a Service Type Repository. Service offers, or offers,

are instances of these service types.

Figure 1: Typical trading service process

A server can export an offer to the trader, which includes an object reference for one of

its objects and values for properties defined by the service type, for example, "50 pages

per minute, located on the first floor". A client can then query the trading service based

on these properties using a filter called a constraint. For example, a client could search

for a printer where "pages_per_minute > 200". The trader then returns to the client an

offer of a service. The client can then use the object reference in the offer to invoke on

the server.

The Trader Service's Components

The Trader Service functionality is divided into components where each component has

an associated interface as follows:

• Lookup

• Register

• Admin

• Link

• Proxy

The functionality of each kind of trader depends on the interfaces that it supports. The

following is a list of the kinds of traders specified by the OMG:

• The simplest trader is the Query trader, which just supports the Lookup

interface. This could be useful, for example, where a trader is pre-loaded

and optimized for searching.

• The simple trader supports not only the Lookup interface but it also

supports exporting of offers with the Register interface.

• The stand-alone trader supports the interfaces of a simple trader and

additionally supports administration of the trader's configuration settings

using the Admin interface.

• The proxy trader supports the interfaces of a stand-alone trader and

additionally supports the Proxy interface. The proxy trader essentially

exports a lookup interface for delayed evaluation of offers, and can be

used for encapsulating legacy applications, or as a kind of service offer

factory.

• The linked trader supports the interfaces of a stand-alone trader and

additionally supports federation of traders using the Link interface.

• The full-service trader combines the functionality of all component

interfaces. Orbix E2A CORBA Trader Service is a full-service trader.

CORBA Event Service An event originates at a client supplier and is forwarded through an event channel to any

number of client consumers. Suppliers and consumers are completely decoupled; a

supplier has no knowledge of the number of consumers or their identities, and consumers

have no knowledge of which supplier generated a given event.

Service Capabilities

An event channel provides the following capabilities for forwarding events:

• Enables consumers to subscribe to events of certain types.

• Accepts incoming events from client suppliers.

• Forwards supplier-generated events to all connected consumers.

Connections

Suppliers and consumers connect to an event channel and not directly to each other, as

shown in Figure1. From a supplier's perspective, the event channel appears as a single

consumer; from a consumer's perspective, the event channel appears as a single supplier.

In this way, the event channel decouples suppliers and consumers.

Figure 1: Suppliers and Consumers Communicating through an Event Channel

How Many Clients?

Any number of suppliers can issue events to any number of consumers using a single

event channel. There is no correlation between the number of suppliers and the number of

consumers. New suppliers and consumers can be easily added to or removed from the

system. Furthermore, any supplier or consumer can connect to more than one event

channel.

Example

Many documents can be linked to a spreadsheet cell, and must be notified when the cell

value changes. However, the spreadsheet software does not need to know about the

documents linked to its cell. When the cell value changes, the spreadsheet software

should be able to issue an event that is automatically forwarded to each connected

document.

Event Delivery

Figure2 shows a sample implementation of event propagation in a CORBA system. In

this example, suppliers are implemented as CORBA clients; the event channel and

consumers are implemented as CORBA servers. An event occurs when a supplier

invokes a clearly defined IDL operation on an object in the event channel application.

The event channel then propagates the event by invoking a similar operation on objects in

each of the consumer servers.

Figure 2: Event Propagation in a CORBA System

CORBA Notification Service

The notification service extends the concept of event-based messaging with the following

features:

Feature Description

Quality-of-service Properties such as event message priority and lifetime, can

be set on different levels within the event channel.

Persistence Quality-of-service parameters control the availability of

events and channels beyond the lifetime of the service

process, supplier processes, or consumer processes.

Event filtering Filters allow consumers to receive only the events they are

and subscription interested in, and to tell suppliers which events are in

demand.

Event publication Suppliers can inform an event channel which events they

can supply, so consumers can subscribe to new event types

as they become available.

Structured events Header information in structured events let you set

properties and filterable data on event messages.

Multicast event

delivery

Groups of consumers can subscribe to events and receive

them using UDP multicast protocol, which keeps network

traffic to a minimum.

Event Communication

CORBA specifies two approaches to initiating the transfer of events between suppliers

and consumers

• push model: Suppliers initiate transfer of events by sending those events to the

channel. The channel then forwards them to any consumers connected to it.

• pull model: Consumers initiate the transfer of events by requesting them from the

channel. The channel requests events from the suppliers connected to it.

Push Model

In the push model, suppliers generate events and actively pass them to an event channel.

In this model, consumers wait for events to arrive from the channel. Figure3 illustrates a

push model architecture in which push suppliers communicate with push consumers

through the event channel.

Figure 3: The Push Model of Event Transfer

Event Propagation

In this architecture, a supplier initiates event transfer by invoking an IDL operation on an

object in the event channel. The event channel then invokes a similar operation on an

object in each consumer that is connected to the channel.

Pull Model

In the pull model, a consumer actively requests events from the channel. The supplier

waits for a pull request to arrive from the channel. When a pull request arrives, event data

is generated and returned to the channel. Figure4 illustrates a pull model architecture in

which pull consumers communicate with pull suppliers through the event channel.

Figure 4: Pull Model Suppliers and Consumers Communicating through an Event Channel

Event Propagation

In this architecture, the event channel invokes an IDL operation on an object in each

supplier to collect events. When a consumer invokes a similar operation on the event

channel, the channel forwards the events to the consumer that initiated the transfer.

Mixing Push and Pull Models

Because suppliers and consumers are completely decoupled by the event channel, push

and pull models can be mixed in a single system. For example, suppliers can connect to

an event channel using the push model, while consumers connect using the pull model, as

shown in Figure5.

Figure 5: Push Suppliers and Pull Consumers Communicating through an Event Channel

Event Propagation

In this case, both suppliers and consumers participate in initiating event transfer. A

supplier invokes an operation on an object in the event channel to transfer an event to the

channel. A consumer then invokes another operation on an event channel object to

transfer the event data from the channel.

In the case where push consumers and pull suppliers are mixed, the event channel

actively propagates events by invoking IDL operations in objects in both suppliers and

consumers. The pull supplier would wait for the channel to invoke an event transfer

before sending events. Similarly, the push consumer would wait for the event channel to

invoke event transfer before receiving events.

Event Filtering

Filter objects screen events as they pass through the channel, and process those that meet

the filter constraints. The notification service defines two types of filters:

• Forwarding filters are set in a channel by clients that wish to restrict event delivery to

those events that meet certain constraints. These filters implement interface

CosNotifyFilter::Filter.

• Mapping filters are set by consumers to adjust the priority or lifetime settings of those

messages that meet filter constraints. These filters implement interface

CosNotifyFilter::MappingFilter.

CORBA Object Transaction Service

The Object Transaction Service (OTS) is a CORBA service that enables the use of

distributed, two-phase commit transactions in CORBA applications. OTS consists of:

(1) several IDL interfaces (most of which are defined in a module called CosTransactions),

(2) some additional library code that is linked into client and server applications, and

(3) a transaction manager. At first sight, the OTS specification can appear to be overly

complex. There are two reasons for this.

The first reason for the apparent complexity of OTS is because the OTS specification

defines not just the API that is used by “normal” developers; it also defines the lower-

level “plumbing” API that is used by vendors to implement OTS. The reason why the

OTS specification defines the plumbing API is that doing so ensures interoperability

between different implementations of OTS. This means that an OTS client built with one

CORBA product can take part in distributed transactions with OTS servers that are

implemented with different CORBA products.

The second reason for the apparent complexity of OTS is because its API is flexible

enough to allow transactional applications to be written in several different ways. Most

developers use a simple API that allows them to focus on application-level logic, while

leaving OTS to automatically perform several house-keeping tasks. However, OTS does

allow developers to take a more hands-on approach and manually handle the required

house-keeping tasks. The fuller set of “hands-on” APIs makes it possible for developers

to integrate OTS with non-XA-compliant databases or to implement bridges from OTS to

a non-CORBA distributed transactional system.

interface TransactionFactory { Control create(in unsigned long time_out); ... }; interface Control { Terminator get_terminator(); Coordinator get_coordinator(); }; interface Terminator { void commit(...); void rollback(); }; interface Coordinator { RecoveryCoordinator register_resource(in Resource r); ... }; interface RecoveryCoordinator { Status replay_completion(in Resource r); }; interface Resource { Vote prepare(); void rollback(); void commit(); ...

}; local interface Current : CORBA::Current {

void begin(); void commit(); void rollback(); void set_timeout(in unsigned long seconds); unsigned long get_timeout(); Control get_control(); Control suspend(); void resume(in Control which); }; Figure 21.3: A subset of the OTS APIs

The Raw API of OTS

The Resource interface is a CORBA “wrapper” around a resource (database). The

operations defined on this interface are similar to the C-based API of the XA standard.

Implementations of OTS provide an implementation of the Resource interface that trivially

delegates to the underlying XA C-based API. This means that a server developer gets

trivial integration between OTS and an XA-compliant database. If server developers are

using a database that is not XA-compliant then they will have to implement the Resource

interface for that database.

An implementation of OTS provides a transaction manager (TM). The specification does

not state if this should be packaged as, say, a server process or as a library that can be

linked into another application. However, it is common for the TM to be a stand-alone

server process. Regardless of how it is packaged, the TM contains pre-written

implementations of several interfaces: TransactionFactory, Control, Terminator, Coordinator and

RecoveryCoordinator.

The CORBA specification does not state how an OTS client connects to the transaction

factory in the TM, so the mechanism varies from one CORBA product to another.

However, the connection is likely to be made by calling resolve_initial_references(). The OTS

client calls TransactionFactory::create() to begin a transaction. This operation returns a

reference to a Control object.

The client must somehow communicate the Control object reference when invoking an

operation on an OTS-aware object. This could be achieved by explicitly passing the

Control reference as a parameter to the operation. However, it is more commonly

achieved by embedding the Control reference (along with other information) in a service

context that is transmitted with the request. The OTS specification defines a service

context structure for this purpose.

When the client wants to terminate a transaction, it calls Control::get_terminator() to

obtain a reference to the Terminator object and then calls commit() or rollback() on this.

If an OTS server accesses an XA-compliant database then the server invokes an OTS

operation that puts a Resource wrapper around the database. If the server uses a non-XA-

compliant database then the server developer must implement the Resource interface so

that its database can take part in two-phase commit transactions.

In the original OTS specification, an object indicated that it could take part in OTS

transactions by implementing an IDL interface that inherited from

CosTransactions::TransactionalObject. The _is_a() operation (which is provided by the

base Object type) was used by a client application to determine whether or not an object

reference was for a transactionally aware object. However, the OMG decided that this

approach was undesirable. In particular, it can result in a dramatic increase in the number

of IDL interface definitions.2 Eventually, the OMG decided that it would be be better if

whether or not an object was transactionally aware could be expressed as a quality of

service. In modern versions of the OTS, this goal is achieved by defining a new POA

Policy type that, if used, indicates that objects in that POA are transactionally aware. An

IOR interceptor detects the presence of this POA policy and embeds an OTS

TaggedComponent into IORs that originate from that POA. A client application can

check for the presence of this TaggedComponent to determine if an object is

transactionally aware.

When an operation in an OTS-enabled server receives a Control object, it can call

get_coordinator() to gain access to the transaction’s Coordinator object. The Coordinator

interface is a “wrapper” around the coordination logic that implements the two-phase

commit protocol. Its purpose is to interact with the Resource objects in OTS servers. The

server calls register_resource() on the Coordinator to register its resource (this

registration occurs only once per transaction). This informs the TM that the server’s

Resource is taking part in the transaction and so should be included in the two-phase

commit protocol when the transaction commits. This operation returns a reference to a

RecoveryCoordinator object for the transaction. The server stores this object reference in

a persistent storage area so that if the server crashes during the two-phase commit

protocol and is restarted then the server can contact the RecoveryCoordinator to

determine if the transaction should commit or roll-back.

During the two-phase commit, the TM invokes the prepare() operation on all Resource

objects that have taken part in the transaction. The return value of this operation is a Vote

that determines if the transaction will be committed or rolled back.

How OTS Builds on Top of Other Parts of CORBA

This section briefly discusses a simple subset of the API provided by OTS. This simple

subset is used by most OTS developers. The focus of this discussion is not to act as a

tutorial for developers, but rather to show how other aspects of CORBA (such as current

objects, portable interceptors and service contexts) are used as building blocks for more

powerful capabilities, such as OTS.

OTS defines a Current object. This object is accessed by calling

resolve_initial_references("TransactionCurrent"). The OTS Current object lets threads in

both client and server applications know with which transaction they are currently

associated.

An OTS client uses the begin(), commit() and rollback() operations on the Current object

to control the lifetime of a transaction. Internally, the Current object delegates to the

corresponding operations defined on the interfaces in the transaction manager. When a

client invokes an operation on an object, a portable request interceptor provided by OTS

embeds transactional context information obtained from the Current object in a service

context that is then transmitted with the request to the target object. A corresponding

portable request interceptor in the server extracts this transactional context information

from the service context and initializes the server’s Current object before dispatching to

the target operation. This means that the body of the operation executes within the

context of a transaction. Because of this, the operation does not need to begin-and-

commit or resume-and-suspend a transaction. Instead, these details are taken care of by

the portable interceptor and so the body of the operation can focus on using, say,

embedded SQL or JDBC to query/update the database.

The mechanism discussed above provides a simple API for developers and it is powerful

enough for the majority of applications. However, developers can, if they so choose,

avoid using the Current object and its associated portable interceptor, and instead

manually execute their own OTS-infrastructure code. Although this is more complex, it

provides a way for developers to integrate a non-XA-compliant database with OTS.

CORBA Security Service The assets of an enterprise need to be protected against perceived threats. The amount of

protection the enterprise is prepared to pay for depends on the value of the assets, and the

threats that need to be countered. The security policy needed to protect against these

threats may also depend on the environment and how vulnerable the assets are in this

environment. This CORBA Security Service provides a security architecture that can

support a variety of security policies to meet different needs.

The security functionality defined by this specification comprises:

• Identification and authentication of principals (human users and objects that need

to operate under their own rights) to verify they are who they claim to be.

• Authorization and infrastructure based access control - deciding whether a

principal can access an object domain, individual object, or operation on an

object, normally using the identity and/or privilege attributes of the principal

(such as role, groups, security clearance).

• Security auditing to make users accountable for their security related actions. It is

normally the human user who should be accountable. Auditing mechanisms

should be able to identify the user correctly, even after a chain of calls through

many objects.

• Security of communication between objects, which is often over insecure lower

layer communications. This requires trust to be established between the client and

target, which may require authentication of clients to targets and authentication of

targets to clients. If also requires integrity protection and (optionally)

confidentiality protection of messages in transit between objects.

• Non-repudiation provided 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.

The CORBA security model is security technology neutral. For example, interfaces

specified for security of client-target object invocations hide the security mechanisms

used from both the application objects and ORB (except for some security administrative

functions). It is possible to implement CORBA security on a wide variety of existing

systems, reusing the security mechanisms and protocols native to those systems.

The CORBA Security Service can control access to an application object without it being

aware of security, so it can be ported to environments that enforce different security

policies and use different security mechanisms. However, if an object requires

application level security, the security attributes must be delegated and made available to

the application for access control. This specification defines the core security facilities

and interfaces required to ensure a reasonable level of security of a CORBA-compliant

system as a whole.

CORBA Licensing Service

First, CORBA licensing service is used to achieve transparency. The end user should not

be aware of the existence of the licensing service. Whenever a user invokes an

application, the licensing service locates a valid license. If such a license is available and

the end user has permission to use it, the service returns the appropriate access rights

allowing the application to proceed without bothering the end-user. If a valid license is

not available, various policies can be implemented, depending on the agreement

negotiated between the software supplier and the software customer: put the request in a

waiting queue, wait a random amount of time and retry, ask the end user for a course of

action, give access anyway, etc.

Second, it is to permit the evolvability of the service in the face of ever changing

licensing policies. The service should be able to adapt to unanticipated licensing practices

with no or little changes to the core design.

A licensing service must allow client applications to run according to a license. It defines

two interfaces: LicenseServiceManager and ProducerSpecificLicenseService.

These standardized interfaces provide the entry points to the service.

Figure 1. Interfaces Interaction 1 4 5 6 3 2

Figure 1 shows the interactions among the system components. The ProducerClient

component is some piece of software whose use we want to control. In this paper, we

refer also to it as the client application. The LicenceManager component is a black box

embodying specific licensing policies, and is not part of the licensing service pecification.

The client application connects to the LicenseServiceManager and requests an instance

of the ProducerSpecificLicenseService (steps 1 and 2), which it gets through steps 3

Producer Client

Producer Specific License Service

License Service Manager

License Manager

License

License

and 4. The exact means for getting that instance are left to the service designers. After

steps 5 and 6, the client application becomes effectively controlled. Before granting

authorization, ProducerSpecificLicenseService communicates with LicenceManager

which checks the available licenses and applicable rules and policies.

CORBA LifeCycle service Life Cycle Service defines services and conventions for creating, deleting, copying and

moving objects. Because CORBA-based environments support distributed objects, the

Life Cycle Service defines conventions that allow clients to perform life cycle operations

on objects in different locations.

A client is any piece of code that initiates a life cycle operation for some object. A client

has a simple view of the life cycle operations. The client’s model of creation is defined in

terms of factory objects. A factory is an object that creates another object. Factories are

not special objects. As with any object, factories have well-defined IDL interfaces and

implementations in some programming language.

The above figure to create an object “over there” a client must posses an object reference

to a factory over there. The client simply issues a request on the factory. There is no

standard interface for a factory. Factories provide the client with specialized operations to

create and initialize new instances in a natural way for the implementation. The following

illustrates a factory for a document.

interface DocFactory { Document create(); Document create_with_title(in string title); Document create_for(in natural_language nl); };

Factories are object implementation dependent. A different implementation of the

document could define a different factory interface. A generic factory is a creation

service. It provides a generic operation for creation.

Instead of invoking an object specific operation on a factory with statically defined

parameters, the client invokes a standard operation whose parameters can include

information about resource filters, state initialization, policy preferences, etc. To create

an object, a client must possess an object reference for a factory, which may be either a

generic factory or an object-specific factory, and issue an appropriate

request on the factory. As a result, a new object is created and typically an object

reference is returned. There is nothing special about this interaction. A factory assembles

the resources necessary for the existence of an object it creates. Therefore, the factory

represents a scope of resource allocation, which is the set of resources available to the

factory. A factory may support an interface that enables its clients to constrain the scope.

Clients find factory objects in the same fashion they find any object. Two common

scenarios for clients to find factories are:

A client that wishes to delete an object issues a remove1 request on an object supporting

the LifeCycle Object interface. The object receiving the request is called the target. To

delete an object, a client must posses an object reference supporting the LifeCycleObject

interface and issues a remove request on the object.

A client that wishes to move or copy an object issues a move or copy request on an

object supporting the LifeCycleObject interface. The object receiving the request is

called the target. The move and copy operations expect an object reference supporting the

FactoryFinder interface. The implementations of move and copy can use the factory

finder to find appropriate factories “over there.” This is invisible to the client. Client code

would simply issue a copy request on the document and pass it an object supporting the

FactoryFinder interface as an argument. When a client issues a copy request on a

target, it is assumed that the target, the factory finder, and the newly created object can all

communicate via the ORB. With externalization/internalization there is no such

assumption. In the presence of a future externalization service, the externalized form of

the object can exist outside of the ORB for arbitrary amounts of time, be transported by

means outside of the ORB and can be internalized in a different, disconnected ORB.

Factory Finders Factory finders support operations which returns one or more factories. Clients pass

factory finders to the move and copy operations, which typically invoke this operation to

find a factory to interact with. The new copy or the migrated object will then be within

the scope of the factory finder. Some examples of locations that a factory finder might

represent are:

• somewhere on a work group’s local area network

• storage device A on machine X

• Susan’s notebook computer

Design Principles Several principles have driven the design of the Life Cycle Service:

1. A factory object registered at a factory finder represents an implementation at that

location. Thus, a factory finder allows clients to query a location for an implementation.

2. Object implementations can embody knowledge of finding a factory, relative to a

location. Object implementations usually do not embody knowledge of location.

3. The desired result for life cycle operations such as copy and move depends on

relationships between the target object and other objects.

4. The Life Cycle Service is not dependent on any particular model of persistence and is

suitable for distributed, heterogeneous environments.

5. The design does not include an object equivalence service nor rely on global object

identifiers.

CORBA Concurrency Control Service The Concurrency Control Service enables multiple clients to coordinate their access to

shared resources. Coordinating access to a resource means that when multiple,

concurrent clients access a single resource, any conflicting actions by the clients are

reconciled so that the resource remains in a consistent state.

The Concurrency Control Service does not define what a resource is. It is up to the clients

of the Concurrency Control Service to define resources and to properly identify

potentially conflicting uses of those resources. In a typical use, an object would be a

resource, and the object implementation would use the concurrency control service to

coordinate concurrent access to the object by multiple clients.

The Concurrency Control Service differentiates between two types of client: a

transactional client and a non-transactional client. Conflicting access by clients of

different types is managed by the Concurrency Control Service, thereby ensuring that

clients always see the resource in a consistent state. The Concurrency Control Service

does not define what a transaction is. Transactions are defined by the Transaction

Service. The Concurrency Control Service is designed to be used with the Transaction

Service to coordinate the activities of concurrent transactions.

The Transaction Service supports two modes of operation: implicit and explicit. When

operating in the implicit mode, a transaction is implicitly associated with the current

thread of control. When executing in the explicit mode, a transaction is specified

explicitly by the reference to the coordinator that manages the current transaction. To

simplify the model of locking supported by the Concurrency Control Service when a

transactional client is operating in the implicit transaction mode, transactional clients are

limited to a single thread per transaction (nested transactions can be used when

parallelism is necessary) and that thread can be executing on behalf of at most one

transaction at a time.

Locks The Concurrency Control service coordinates concurrent use of a resource using locks. A

lock represents the ability of a specific client to access a specific resource in a particular

way. Each lock is associated with a single resource and a single client. Coordination is

achieved by preventing multiple clients from simultaneously possessing locks for the

same resource if the activities of those clients might conflict. To achieve coordination, a

client must obtain an appropriate lock before accessing a shared resource.

Lock Modes The Concurrency Control Service defines several lock modes, which correspond to

different categories of access. Having a variety of lock modes allows more flexible

conflict resolution.

Lock Granularity The Concurrency Control Service does not define the granularity of the resources that are

locked. It defines a lock set, which is a collection of locks associated with a single

resource. It is up to clients of the Concurrency Control Service to associate a lock set

with each resource. Typically, if an object is a resource, the object would internally create

and retain a lock set. However, the mapping between objects and resources (and lock

sets) is up to the object implementation; the mapping could be one to one, but it could

also be one to many, many to many, or many to one.

Lock Modes Read, Write, and Upgrade Locks

The Concurrency Control service defines read (R) and write (W) lock modes that support

the conventional multiple readers, one writer policy. Read locks conflict with write locks,

and write locks conflict with other write locks. In addition, the Concurrency Control

service defines an upgrade (U) mode. An upgrade mode lock is a read lock that conflicts

with itself. It is useful for avoiding a common form of deadlock that occurs when two or

more clients attempt to read and then update the same resource. If more than one client

holds a read lock on the resource, a deadlock will occur as soon as one of the clients

requests a write lock on the resource. If each client requests a single upgrade lock

followed by a write lock, this deadlock will not occur.

CORBA Collection Service Collections support the grouping of objects and support operations for the manipulation

of the objects as a group. Common collection types are queues, sets, bags, maps, etc.

Collection types differ in the “nature of grouping” exposed to the user. “Nature of

grouping” is reflected in the operations supported for the manipulation of objects as

members of a group. Collections, for example, can be ordered and thus support access to

an element at position ”i” while other collections may support associative access to

elements via a key. Collections may guarantee the uniqueness of elements while others

allow multiple occurrences of elements. A user chooses a collection type that matches the

application requirements based on manipulation capabilities. Collections are foundation

classes used in a broad range of applications; therefore, they have to meet the general

requirement to be able to collect elements of arbitrary type. On the other hand, a

collection instance usually is a homogenous collection in the sense that all elements

collected are of the same type, or support the same single interface.

Bag, SortedBag A Bag is an unordered collection of zero or more elements with no key. Multiple

elements are supported. As element equality is supported, operations which require the

capability “test of element equality” (e.g., test on containment) can be offered. Example:

The implementation of a text file compression algorithm. The algorithm finds the most

frequently occurring words in sample files. During compression, the words with a high

frequency are replaced by a code (for example, an escape character followed by a one

character code). During re-installation of files, codes are replaced by the respective

words. Several types of collections may be used in this context. A Bag can be used during

the analysis of the sample text files to collect isolated words. After the analysis phase you

may ask for the number of occurrences for each word to construct a structure with the

255 words with the highest word counts. A Bag offers an operation for this, you do not

have to “count by hand,” which is less efficient. To find the 255 words with the highest

word count, a SortedRelation is the appropriate structure.

A SortedBag (as compared to a Bag) exposes and maintains a sorted order of the

elements based on a user-defined element comparison. Maintained elements in a sorted

order makes sense when printing or displaying the collection content in sorted order.

EqualitySequence An EqualitySequence is an ordered collection of elements with no key. There is a first

and a last element. Each element, except the last one, has a next element and each

element, except the first one, has a previous element. As element equality is supported,

all operations that rely on the capability “test on element equality” can be offered, for

example, locating an element or test for containment. Example: An application that

arranges wagons to a train. The order of the wagons is important. The trailcar has to be

the first wagon, the first class wagons are arranged right behind the trailcar, the restaurant

has to be arranged right after the first class and before the second class wagons, and so

on.

Heap A Heap is an unordered collection of zero or more elements without a key. Multiple

elements are supported. No element equality is supported. Example: A “trash can” on a

desktop which memorizes all objects moved to the trashcan as long as it is not emptied.

Whenever you move an object to the trashcan it is added to the heap. Sometimes you

move an object accidentally to the trashcan. In that case, you iterate in some order

through the trashcan to find the object - not using a test on element equality. When you

find it, you remove it from the trashcan. Sometimes you empty the trashcan and remove

all objects from the trashcan.

KeyBag, KeySortedBag A KeyBag is an unordered collection of zero or more elements that have a key. Multiple

keys are supported. As no element equality is assumed, operations such as “test on

collection equality” or “set theoretical operation” are not offered. A KeySortedBag is

sorted by key. In addition to the operations supported for a KeyBag, all operations related

to ordering are offered

KeySet, KeySortedSet A KeySet is an unordered collection of zero or more elements that have a key. Keys must

be unique. Defined element equality is not assumed; therefore, operations and semantics

which require the capability “element equality test" are not offered. A KeySortedSet is

sorted by key. In addition to the operations supported for a KeySet, all operations related

to ordering are offered. For example, operations exploiting the ordering, such as

“set_to_previous / set_to_next” and “access via position” are supported.

Map, SortedMap A Map is an unordered collection of zero or more elements that have a key. Keys must be

unique. As defined, element equality is assumed access via the element value and all

operations which need to test on element equality, such as a test on containment for an

element, test for equality, and set theoretical operations can be offered for maps. A

SortedMap is sorted by key. In addition to the operations supported for a Map, all

operations related to ordering are offered. For example, operations exploiting the

ordering like “set_to_previous / set_to_next” and “access via position” are supported.

Relation, SortedRelation A Relation is an unordered collection of zero or more elements with a key. Multiple keys

are supported. As defined element equality is assumed, test for equality of two collections

is offered as well as the set theoretical operations. A SortedRelation is sorted by key. In

addition to the operations supported for a Relation, all operations related to ordering are

offered. For example, operations that exploit ordering such as “set_to_previous /

set_to_next” and “access via position” are supported.

Set, SortedSet A set is an unordered collection of zero or more elements without a key. Element equality

is supported; therefore, operations that require the capability “test on element equality”

such as intersection or union can be offered. A SortedSet is sorted with respect to a user-

defined element comparison. In addition to the operations supported for a Set, all

operations related to ordering are offered.

Sequence A Sequence is an ordered collection of elements without a key. There is a first and a last

element. Each element (except the last one) has a next element and each element (except

the first one) has a previous element. No element equality is supported; therefore,

multiples may occur and access to elements via the element value is not possible. Access

to elements is possible via position/index.

Deque A double ended queue may be considered as a sequence with restricted access. It is an

ordered collection of elements without a key and no element equality. As there is no

element equality, an element value may occur multiple times. There is a first and a last

element. You can only add an element as first or last element and only remove the first or

the last element from the Deque.

PriorityQueue A PriorityQueue may be considered as a KeySortedBag with restricted access. It is an

ordered collection with zero or more elements. Multiple key values are supported. As no

element equality is defined, multiple element values may occur. Access to elements is via

key only and sorting is maintained by key. Accessing a PriorityQueue is restricted. You

can add an element relative to the ordering relation defined for keys and remove only the

first element (e.g., the one with highest priority).

Queue

A queue may be considered as a sequence with restricted access. It is an ordered

collection of elements with no key and no element equality. There is a first and a last

element. You can only add (enque) an element as last element and only remove (deque)

the first element from the Queue. That is, a queue exposes FIFO behavior.

Stack

A Stack may be considered as a sequence with restricted access. It is an ordered

collection of elements with no key and no element equality. There is a first and a last

element. You can only add (push) an element as last element (at the top) and only remove

(pop) the last element from the Stack (from the top). That is, a Stack exposes LIFO

behavior

CORBA Externalization Service The Externalization Service specification defines protocols and conventions for

externalizing and internalizing objects. To externalize an object is to record the object’s

state in a stream of data. Objects which support the appropriate interfaces and whose

implementations adhere to the proper conventions can be externalized to a stream (in

memory, on a disk file, across the network, etc.) and subsequently be internalized into a

new object in the same or a different process. The externalized form of the object can

exist for arbitrary amounts of time, be transported by means outside of the ORB, and can

be internalized in a different, disconnected ORB. Many different externalized data

formats and storage mediums can be supported by service implementations. But, for

portability, clients can request that externalized data be stored in a file using a

standardized format that is defined as part of this Externalization Service specification.

Externalizing and internalizing an object is similar to copying the object. The copy

operation creates a new object that is initialized from an existing object. The new object

is then available to provide service. Furthermore, with the copy operation, there is an

assumption that it is possible to communicate via the ORB between the “here” and

“there”. Externalization, on the other hand, does not create an object that is initialized

from an existing object. Externalization “stops along the way”.

New objects are not created until the stream is internalized. Furthermore, there is no

assumption that is possible to communicate via the ORB between “here” and “there.” The

Externalization Service is related to the Relationship Service. It also parallels the Life

Cycle Service in defining externalization protocols for simple objects, for arbitrarily

related objects, and for graphs of related objects that support compound operations. The

Externalization Service defines protocols in these areas:

• Client’s view of externalization, composed of the interfaces used by a client to

externalize and internalize objects. The client’s view of externalization is defined

by the Stream interface.

• Object’s view of externalization, composed of the interfaces used by an

externalizable object to record and retrieve their object state to and from the

stream’s external form. The object’s view is defined by the StreamIO interface.

• Stream’s view of externalization, composed of the interfaces used by the stream

to direct an externalizable object or graph of objects to record or retrieve their

state from the stream’s external form. The stream’s view of externalization is

given by the Streamable, Node, Role and Relationship interfaces.

CORBA Time Service

Time Service Requirements The requirements explicitly stated in the RFP ask for a service that enables the user to obtain current time

together with an error estimate associated with it. Additionally, the RFP suggests that the service also

provide the following facilities:

• Ascertain the order in which “events” occurred.

• Generate time-based events based on timers and alarms.

• Compute the interval between two events.

The general architectural pattern used is that a service object manages objects of a specific category as

shown in Figure 1-1.

The service interface provides operations for creating the objects that the service manages

and, if appropriate, also provides operations for getting rid of them. The Time Service

object consists of two services, and hence defines two service interfaces:

• Time Service manages Universal Time Objects (UTOs) and Time Interval Objects

(TIOs), and is represented by the TimeService interface.

• Timer Event Service manages Timer Event Handler objects, and is represented by the

TimerEventService interface.

CORBA Persistent State Service

The Persistent State Service presents persistent information as storage objects stored in

storage homes. Storage homes are themselves stored in datastores. A datastore is an

entity that manages data, for example a database, a set of files, a schema in a relational

database.

In order to manipulate a storage object, you need a programming-language object that

represents it in your program. In Java and C++, this programming language object is an

instance of a class: therefore we call it a storage object instance.

A storage object instance may be bound to a storage object in the datastore, and provides

direct access to the state of this storage object: updating the instance updates the storage

object in the datastore. Such a connected instance is called a storage object incarnation.

Likewise, to use a storage home, you need a programming language object called a

storage home instance. Storage home instances themselves are provided by catalogs.

To access a storage object, you need a logical connection between your process and the

datastore that contains the storage home of this storage object. This logical connection,

called session, can give access to more than one datastore.

The management of sessions is either explicit (you create and manage sessions yourself)

or implicit (you create one or more session pools that manage sessions for you). Sessions

and session pools are the two kinds of catalogs defined by this specification.

Conceptually, a datastore is a set of storage homes. Each storage home has a type. Within

a datastore, a storage home is a singleton: there is at most one storage home of a given

type in this datastore. A storage home contains storage objects. Each storage object has

an ID unique within its storage home (its short-pid) and a global ID (its pid). The scope

of the pid is all storage objects that can be accessed through the same catalog. Each

storage object has a type, which defines the state members and operations (also known as

stored methods) of instances of this type. A storage object type can derive from another

storage object type.

A storage home can only contain storage objects of a given type. The type of a storage

home defines this storage object type, plus operations and keys (defined below). A

storage home type can derive from another storage home type: the storage object type of

the base storage home type must be a base of the storage object type of the derived

storage home type.

Within a datastore, a storage home manages its own storage objects and the storage

objects of all derived storage homes. A storage home and all its derived storage homes is

called a storage home family.

A storage home can ensure that a list of state members of its storage object type forms a

unique identifier for the storage objects it manages. Such a list of state members is called

a key. A storage home can have any number of keys.

CORBA Component Model (CCM) The CCM is part of the CORBA 3.0 specification, is a server-side component model for

building and deploying CORBA applications. It is very similar to Enterprise Java Beans

(EJB) because this also allows system services to be implemented by the container

provider rather than the application developer. The CCM extends the CORBA object

model by defining features and services in a standard environment that enable application

developers to implement, manage, configure and deploy components that integrate with

commonly used CORBA Services. These server-side services include transactions,

security, persistence, and events. The CCM is language-independent. This means that the

OMG must package the technology more tightly to provide a complete vocabulary for

describing binary executables.

CCM Terminology:

Facets

The component facets are the interfaces that the component exposes.

Receptacles

These allow components to "hook" themselves together. Component systems contain

many components that work together to provide the client functionality. The receptacle

allows a component to declare its dependency to an object reference that it must use.

Receptacles provide the mechanics to specify interfaces required for a component to

function correctly.

Event sources/Sinks

Allow components to work with each other without being tightly linked. This is loose

coupling as provided by the Observer design pattern. When a component declares its

interest to publish or emit an event, it is an event source. A publisher is an exclusive

provider of an event while an emitter shares an event channel with other event sources.

Other components become subscribers or consumers of those events by declaring an

event sink.

Attributes

An extension of the traditional notion of CORBA interface attributes that allow

component values to be configured, the CCM version of attribute allows operations that

access and modify values to raise exceptions. This is a useful feature for raising a

configuration exception after the configuration has completed and an attribute has been

accessed or changed. These new terms are illustrated in Figure 1.

Figure 1. Component model

Component Implementation Definition Language (CIDL)

To support all the above features, the CCM extends the CORBA Interface Definition

Language (CIDL) to the point that it "introduces a new declaration language." CIDL, like

IDL, relieves developers from having to provide much of the "plumbing" needed to

include components within a container. To be exact, CIDL is a superset of the Persistent

State Definition Language (PSDL), which itself is a superset of IDL. You should be

aware that OMG IDL is morphing. Since CIDL is a language to emphasize the

description of components, it has many new keywords. All of these keywords have been

added to support the features introduced above. Listing 1 provides an example:

Listing 1. An example

interface VideoPlayer { VideoStream play(); int fastForward(in Speed spd); int rewind(in Speed spd); }; component VCR supports VideoPlayer{ provides AudioStream audioPort; provides VideoStream videoPort; }; component DVD supports VideoPlayer{ provides AudioStream audioPort; provides VideoStream videoPort;

}; A component will have a set of interfaces that will let it "behave nicely" in its designated

container, and it will have to have one or more interfaces that clients will call to perform

business logic. You could say the former would be a management interface and the latter

a service interface. OMG IDL allowed you to express a set of interfaces as a new

interface that inherited all the interfaces. This combined interface was usually long and

complicated. An alternative is to define an entry point interface that is used to navigate to

the other interfaces of the object.

The OMG has long known about the Multiple Interface gap. In fact it issued a Request

for Proposal (RFP) regarding this topic back in 1996. That RFP was never specified

concretely by a document, but the CCM can be looked at as fulfilling the requirements of

that RFP. Component types specified by CIDL are allowed a combination of different

interfaces that are not related by inheritance.

A component type name is defined with the component keyword. The component has is

own interface, termed its "equivalent" interface, that is implicitly defined in the

component definition. The equivalent interface for the components VCR and DVD is

VideoPlayer; the relationship is declared through the supports keyword.

The component facets provide the business logic to expose to clients. These "facets" of

our component come to life through the keyword provides . Provided interfaces are the

"ports" that clients or other components can connect to. This is important because another

keyword introduced in CIDL is the uses keyword. Uses declarations define a dependency

of a component to an interface provided by another component or CORBA object. Clients

can then navigate to a specified interface at runtime using Navigation operations

generated by the provides declarations.

CCM Containers :

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 transient containers that may

contain transient, non-persistent components whose states are not saved at all and

persistent containers that contain persistent components whose states are saved between

invocations. Depending upon the types of components that they can execute, CCM

Containers may be divided into:

• Service containers

• Session containers,

• Entity containers, and

• Other containers

Container model

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. The container offers series of local interfaces (internal interfaces) for establishing

component's context and allows component to implement series of callback methods.

Container Architecture

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.

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 and entity

APIs depending on component category explained below.

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 ObjectId mapping.

• Stateless - which uses transient object references in conjunction with a POA

servant which can support any ObjectId.

• Conversational - which uses transient references with a POA servant that is

dedicated to specific ObjectId

• Durable - which uses persistence references with POA servant that is dedicated to

a specific ObjectId.

Application Servers Application Servers which have become very popular in the last few years, provide the

platforms for the execution of transactional, server-side applications in the online world.

They are the modern cousins of traditional transaction processing monitors (TPMs) like

CICS. They play a central role in enabling electronic commerce in the web context. They

are built on the basis of more standardized protocols and APIs. One of the most important

features of Application Sservers is their ability to integrate the modern application

environments with legacy data sources like IMS, CICS, VSAM, etc. They provide a

number of connectors for this purpose, typically using asynchronous transactional

messaging technologies like MQSeries and JMS.

Traditional TPM-style requirements for industrial strength features like scalability,

availability, reliability and high performance are equally important for ASs also. Security

and authentication issues are additional important requirements in the web context. ASs

support DBMSs not only as storage engines for user data but also as repositories for

tracking their own state. Several caching technologies have been developed to improve

performance of ASs.

An Application server is a software framework dedicated to the efficient execution of

procedures (programs, routines, scripts) for supporting the construction of applications.

Advantages of application servers

Data and code integrity

By centralizing business logic on an individual server or on a small number of

server machines, updates and upgrades to the application for all users can be

guaranteed. There is no risk of old versions of the application accessing or

manipulating data in an older, incompatible manner.

Centralized configuration

Changes to the application configuration, such as a move of database server, or

system settings, can take place centrally.

Security

A central point through which service-providers can manage access to data and

portions of the application itself counts as a security benefit, devolving

responsibility for authentication away from the potentially insecure client layer

without exposing the database layer.

Performance

By limiting the network traffic to performance-tier traffic the client–server model

improves the performance of large applications in heavy usage

environments.[citation needed]

Total Cost of Ownership (TCO)

In combination, the benefits above may result in cost savings to an organization

developing enterprise applications. In practice, however, the technical challenges

of writing software that conforms to that paradigm, combined with the need for

software distribution to distribute client code, somewhat negate these benefits.

Transaction Support

A transaction represents a unit of activity in which many updates to resources (on

the same or distributed data sources) can be made atomic (as an indivisible unit of

work). End-users can benefit from a system-wide standard behaviour, from

reduced time to develop, and from reduced costs. As the server does a lot of the

tedious code-generation, developers can focus on business logic.

Borland Enterprise Server

Borland Enterprise Server, also known as Borland Application Server, was Borland's

Java EE Application Server. The product was developed in 1999 within the team of

former Visigenic company that was acquired by Borland in 1997. Borland's Java Studio

was supposed to have BES and JBuilder tightly integrated, but in reality this integration

never happened. BES suffered compatibility problems even with Borland's own products

(JDataStore, OptimizeIt). The appearance of free commercial grade (and more mature)

application servers, like JBoss, made BES unattractive and unable to really compete with

the former.

The Orbix E2A Application Server Platform The Orbix E2A Application Server Platform is a programmer oriented application

development and deployment platform that spans the entire spectrum of hardware and

operating systems, from Windows 2000 to the mainframe, and provides a complete

application integration solution. It provides a complete middleware suite, including: ¥

The worlds most advanced and widely-used CORBA ORB, which implements C++,

Java, COBOL, and PL/I language bindings (the latter two on OS/390).

A J2EE-compliant Application Server whose unique architecture supports full network

distribution, avoiding performance bottlenecks and allowing full use of multiple

machines.

Messaging middleware, including an implementation of EJB 2.0 Message Driven Beans

(part of the J2EE 1.3 specification), complete with ART-based Java Messaging Service

for J2EE-based applications, and the CORBA Notification Service for CORBA

applications.

Web services support: Orbix E2A XMLBus is a development and deployment

environment that lets developers expose existing applications as XML-based Web

services. Built on such standards as SOAP, WSDL, and UDDI, it automatically generates

WSDL interfaces and the SOAP client required to invoke the Web service in question. It

lets you define Web services for publication and access over the Web, bridging .Net,

CORBA, and EJB servers. XMLBus provides support for both Java and CORBA/C++

environments. The platformÕs reliability, availability, and scalability make it suitable for

enterprise-scale, mission-critical systems, as attested to by many of our 4500 customer

deployments.

Because Orbix E2A is neutral with respect to software component models and

programming languages, it allows developers to use their preferred tools to develop

business logic, and to expose business functions in their preferred deployment

environment. Further, Orbix E2A includes XMLBus technology, which not only

simplifies the creation of XML-based Web service applications, but also provides support

for XML communication to new and existing applications. Orbix E2A provides

integration tools for connecting to specific systems and technologies. For example, the

Orbix E2A Application Server Platform provides adapters for MQSeries, CICS, IMS, and

RDBMSs. Further, the Orbix E2A Application Server Platform can easily be integrated

with the Orbix E2A Web Services Integration Platform, to provide adapters for specific

ERP software products, including SAP, Siebel, PeopleSoft, Baan, and so on. Thus, Orbix

E2A supports point-to-point application integration; for example, for a project that needs

to use SAP R/3 as a data source. Orbix E2A makes it easy to use a combination of J2EE,

CORBA, Mainframe integration, and Web services to provide true peer-to-peer service

oriented architectures for enterprise-scale applications and environments. The Orbix E2A

Application Server Platform provides support for enterprise applications by way of three

broad classes of technology: CORBA, J2EE, and the Web services-related technologies

such as XML, SOAP, WSDL, UDDI, and ebXML.

OMG Model Driven Architecture

Model-driven architecture (MDA) is a software design approach for the development

of software systems. It provides a set of guidelines for the structuring of specifications,

which are expressed as models. Model-driven architecture is a kind of domain

engineering, and supports model-driven engineering of software systems. It was launched

by the Object Management Group (OMG) in 2001.

The Model-Driven Architecture approach defines system functionality using a platform-

independent model (PIM) using an appropriate domain-specific language (DSL). Then,

given a platform definition model (PDM) corresponding to CORBA, .NET, the Web, etc.,

the PIM is translated to one or more platform-specific models (PSMs) that computers can

run. This requires mappings and transformations and should be modeled too.

The PSM may use different Domain Specific Languages (DSLs), or a General Purpose

Language (GPL) like Java, C#, PHP, Python, etc. Automated tools generally perform this

translation. The OMG organization provides rough specifications rather than

implementations, often as answers to Requests for Proposals (RFPs). Implementations

come from private companies or open source groups.

MDA principles can also apply to other areas such as business process modeling (BPM)

where the PIM is translated to either automated or manual processes.

Figure 3: A simplified example of PIM to PSM transformation

The simple PIM in Figure 3 represents a Customer and Account. At this level of

abstraction, the model describes important characteristics of the domain in terms of

classes and their attributes, but does not describe any platform-specific choices about

which technologies will be used to represent them. Figure 3 illustrates three specific

mappings, or transformations, defined to create the PSMs, together with the standards

used to express these mappings. For example, one approach is to export the PSM

expressed in UML into XMI format, using standard definitions expressed as either XML

Schema Definitions (XSD) or Document Type Definitions (DTD). This can then be used

as input to a code generation tool that produces interface definitions in Java for each of

the classes defined in the UML.

Usually, a set of rules is built into the code generation tool to perform the transformation.

However, the code generation tool often allows those rules to be specifically defined as

templates in a scripting language.

COM

Component Object Model (COM) is a binary-interface standard for software

componentry introduced by Microsoft in 1993. It is used to enable interprocess

communication and dynamic object creation in a large range of programming languages.

The term COM is often used in the Microsoft software development industry as an

umbrella term that encompasses the OLE, OLE Automation, ActiveX, COM+ and

DCOM technologies.

The essence of COM is a language-neutral way of implementing objects that can be used

in environments different from the one in which they were created, even across machine

boundaries. For well-authored components, COM allows reuse of objects with no

knowledge of their internal implementation, as it forces component implementers to

provide well-defined interfaces that are separate from the implementation. The different

allocation semantics of languages are accommodated by making objects responsible for

their own creation and destruction through reference-counting. Casting between different

interfaces of an object is achieved through the QueryInterface() function. The

preferred method of inheritance within COM is the creation of sub-objects to which

method calls are delegated.

Although the interface standard has been implemented on several platforms[citation needed]

,

COM is primarily used with Microsoft Windows. For some applications, COM has been

replaced at least to some extent by the Microsoft .NET framework, and support for Web

Services through the Windows Communication Foundation (WCF). However, COM

objects can be used with all .NET languages through .NET COM Interop.

Networked DCOM uses binary proprietary formats, while WCF encourages the use of

XML-based SOAP messaging. COM is very similar to other component software

interface technologies, such as CORBA and Java Beans, although each has its own

strengths and weaknesses. The characteristics of COM make it most suitable for the

development and deployment of desktop applications[citation needed]

, for which it was

originally designed.

COM Interfaces

All COM components must (at the very least) implement the standard IUnknown

interface, and thus all COM interfaces are derived from IUnknown. The IUnknown

interface consists of three methods: AddRef() and Release(), which implement

reference counting and controls the lifetime of interfaces; and QueryInterface(), which

by specifying an IID allows a caller to retrieve references to the different interfaces the

component implements. The effect of QueryInterface() is similar to dynamic_cast<>

in C++ or casts in Java and C#.

A COM component's interfaces are required to exhibit the reflexive, symmetric, and

transitive properties. The reflexive property refers to the ability for the

QueryInterface() call on a given interface with the interface's ID to return the same

instance of the interface. The symmetric property requires that when interface B is

retrieved from interface A via QueryInterface(), interface A is retrievable from

interface B as well. The transitive property requires that if interface B is obtainable from

interface A and interface C is obtainable from interface B, then interface C should be

retrievable from interface A.

An interface consists of a pointer to a virtual function table that contains a list of pointers

to the functions that implement the functions declared in the interface, in the same order

that they are declared in the interface. This technique of passing structures of function

pointers is very similar to the one used by OLE 1.0 to communicate with its system

libraries.

COM specifies many other standard interfaces used to allow inter-component

communication. For example, one such interface is IStream, which is exposed by

components that have data stream semantics (e.g. a FileStream component used to read

or write files). It has the expected Read and Write methods to perform stream reads and

writes. Another standard interface is IOleObject, which is exposed by components that

expect to be linked or embedded into a container. IOleObject contains methods that

allow callers to determine the size of the component's bounding rectangle, whether the

component supports operations like 'Open', 'Save' and so on.

COM Classes

A class is COM's language-independent way of defining a class in the object-oriented

sense. A class can be a group of similar objects or a class is simply a representation of a

type of object; it should be thought of as a blueprint that describes the object.

A coclass supplies concrete implementation(s) of one or more interfaces. In COM, such

concrete implementations can be written in any programming language that supports

COM component development, e.g. Delphi, C++, Visual Basic, etc.

One of COM's major contributions to the world of Windows development is the

awareness of the concept of separation of interface from implementation. An

extension of this fundamental concept is the notion of one interface, multiple

implementations. This means that at runtime, an application can choose to instantiate an

interface from one of many different concrete implementations.

COM as an object framework

The fundamental principles of COM have their roots in Object-Oriented philosophies. It

is a platform for the realization of Object-Oriented Development and Deployment.

Because COM is a runtime framework, types have to be individually identifiable and

specifiable at runtime. To achieve this, globally unique identifiers (GUIDs) are used.

Each COM type is designated its own GUID for identification at runtime (versus compile

time).

In order for information on COM types to be accessible at both compile time and

runtime, COM uses type libraries. It is through the effective use of type libraries that

COM achieves its capabilities as a dynamic framework for the interaction of objects.

Consider the following example coclass definition in an IDL :

coclass MyObject

{

[default] interface IMyObject;

[default, source] dispinterface _IMyObjectEvents;

};

The above code fragment declares a COM class named MyObject which must implement

an interface named IMyObject and which supports (not implements) the event interface

_IMyObjectEvents. Ignoring the event interface bit, this is conceptually equivalent to

defining a C++ class like this:

class CSomeObject : public ISomeInterface

{

...

...

...

};

where ISomeInterface is a C++ pure virtual class.

Referring once again to the MyObject COM class: once a coclass definition for it has

been formalized in an IDL, and a Type Library compiled from it, the onus is on the

individual language compiler to read and appropriately interpret this Type Library and

then produce whatever code (in the specific compiler's language) necessary for a

developer to implement and ultimately produce the binary executable code which can be

deemed by COM to be of coclass MyObject.

Once an implementation of a COM coclass is built and is available in the system, next

comes the question of how to instantiate it. In languages like C++, we can use the

CoCreateInstance() API in which we specify the CLSID (CLSID_MyObject) of the

coclass as well as the interface (specified by the IID IID_IMyObject) from that coclass

that we want to use to interact with that coclass. Calling CoCreateInstance() like this:

CoCreateInstance(CLSID_MyObject,

NULL,

CLSCTX_INPROC_SERVER,

IID_IMyObject,

(void**)&m_pIMyObject);

is conceptually equivalent to the following C++ code:

ISomeInterface* pISomeInterface = new CSomeObject();

In the first case, the COM sub-system is used to obtain a pointer to an object that

implements the IMyObject interface and coclass CLSID_MyObject's particular

implementation of this interface is required. In the second case, an instance of a C++

class CSomeObject that implements the interface ISomeInterface is created. A coclass,

then, is an object-oriented class in the COM world. The main feature of the coclass is that

it is (1) binary in nature and consequently (2) programming language-independent.

COM Registry

In Windows, COM classes, interfaces and type libraries are listed by GUIDs in the

registry, under HKEY_CLASSES_ROOT\CLSID for classes and

HKEY_CLASSES_ROOT\Interface for interfaces. The COM libraries use the registry to

locate either the correct local libraries for each COM object or the network location for a

remote service.

Under the key HKCR\clsid, the following are specified:

-> Inprocserver32 = object is to be loaded into a process

Path to file/object and readable name

HKCR\interface:

example: ISTREAM, IRPCSTUB, IMESSAGEFILTER

connects to a CLSID. You can specify

NUMMETHODS and PROXYSTUB(if web-object)

HKCR\typelib

One or more CLSID kan be group into tp. it contains parameters for

linking in COM. The rest of the info in the COM parts of the REGISTRY,

is to give an application/object a CLSID.

Reference counting

The most fundamental COM interface of all, IUnknown (from which all COM interfaces

must be derived), supports two main concepts: feature exploration through the

QueryInterface method, and object lifetime management by including AddRef() and

Release(). Reference counts and feature exploration apply to objects (not to each

interface on an object) and thus must have a centralized implementation.

The COM specifications require a technique called reference counting to ensure that

individual objects remain alive as long as there are clients which have acquired access to

one or more of its interfaces and, conversely, that the same object is properly disposed of

when all code that used the object have finished with it and no longer require it. A COM

object is responsible for freeing its own memory once its reference count drops to zero.

For its implementation, a COM Object usually maintains an integer value that is used for

reference counting. When AddRef() is called via any of object's interfaces, this integer

value is incremented. When Release() is called, this integer is decremented. AddRef()

and Release() are the only means by which a client of a COM object is able to influence

its lifetime. The internal integer value remains a private member of the COM object and

will never be directly accessible.

The purpose of AddRef() is to indicate to the COM object that an additional reference to

itself has been affected and hence it is necessary to remain alive as long as this reference

is still valid. Conversely, the purpose of Release() is to indicate to the COM object that a

client (or a part of the client's code) has no further need for it and hence if this reference

count has dropped to zero, it may be time to destroy itself.

Certain languages (e.g. Visual Basic) provide automatic reference counting so that COM

object developers need not explicitly maintain any internal reference counter in their

source codes. Using COM in C, explicit reference counting is needed. In C++, a coder

may write the reference counting code or use a smart pointer that will manage all the

reference counting.

The following is a general guideline calling AddRef() and Release() to facilitate proper

reference counting in COM object:

• Functions (whether object methods or global functions) that return interface

references (via return value or via "out" parameter) should increment the

reference count of the underlying object before returning. Hence internally within

the function or method, AddRef() is called on the interface reference (to be

returned). An example of this is the QueryInterface() method of the IUnknown

interface. Hence it is imperative that developers be aware that the returned

interface reference has already been reference count incremented and not call

AddRef() on the returned interface reference yet another time.

• Release() must be called on an interface reference before that interface's pointer is

overwritten or goes out of scope.

• If a copy is made on an interface reference pointer, AddRef() should be called on

that pointer. After all, in this case, we are actually creating another reference on

the underlying object.

• AddRef() and Release() must be called on the specific interface which is being

referenced since an object may implement per-interface reference counts in order

to allocate internal resources only for the interfaces which are being referenced.

• Extra calls to these functions are not sent out to remote objects over the wire; a

proxy keeps only one reference on the remote object and maintains its own local

reference count.

COM Instantiation

COM standardizes the instantiation (i.e. creation) process of COM objects by requiring

the use of Class Factories. In order for a COM object to be created, two associated items

must exist:

• A Class ID.

• A Class Factory.

Each COM Class or CoClass must be associated with a unique Class ID (a GUID). It

must also be associated with its own Class Factory (that is achieved by using a

centralized registry). A Class Factory is itself a COM object. It is an object that must

expose the IClassFactory or IClassFactory2 (the latter with licensing support) interface.

The responsibility of such an object is to create other objects.

A class factory object is usually contained within the same executable code (i.e. the

server code) as the COM object itself. When a class factory is called upon to create a

target object, this target object's class id must be provided. This is how the class factory

knows which class of object to instantiate.

A single class factory object may create objects of more than one class. That is, two

objects of different class ids may be created by the same class factory object. However,

this is transparent to the COM system.

By delegating the responsibility of object creation into a separate object, a greater level of

abstraction is promoted, and the developer is given greater flexibility. For example,

implementation of the Singleton and other creation patterns is facilitated. Also, the

calling application is shielded from the COM object's memory allocation semantics by

the factory object.

In order for client applications to be able to acquire class factory objects, COM servers

must properly expose them. A class factory is exposed differently, depending on the

nature of the server code. A server which is DLL-based must export a

DllGetClassObject() global function. A server which is EXE-based registers the class

factory at runtime via the CoRegisterClassObject() Windows API function.

The following is a general outline of the sequence of object creation via its class factory:

The object's class factory is obtained via the CoGetClassObject() API (a standard

Windows API). As part of the call to CoGetClassObject(), the Class ID of the object (to

be created) must be supplied. The following C++ code demonstrates this:

IClassFactory* pIClassFactory = NULL;

CoGetClassObject(CLSID_SomeObject,CLSCTX_ALL,NULL,IID_IClassFactory,

LPVOID*)&pIClassFactory);

The above code indicates that the Class Factory object of a COM object, which is

identified by the class id CLSID_SomeObject, is required. This class factory object is

returned by way of its IClassFactory interface. The returned class factory object is then

requested to create an instance of the originally intended COM object. The following

C++ code demonstrates this:

ISomeObject* pISomeObject = NULL;

if (pIClassFactory)

{

pIClassFactory->CreateInstance (NULL,IID_ISomeObject,

(LPVOID*)&pISomeObject);

pIClassFactory->Release();

pIClassFactory = NULL;

}

The above code indicates the use of the Class Factory object's CreateInstance() method

to create an object which exposes an interface identified by the IID_ISomeObject GUID.

A pointer to the ISomeObject interface of this object is returned. Also note that because

the class factory object is itself a COM object, it needs to be released when it is no longer

required (i.e. its Release() method must be called).

The above demonstrates, at the most basic level, the use of a class factory to instantiate

an object. Higher level constructs are also available, some of which do not even involve

direct use of the Windows APIs.

For example, the CoCreateInstance() API can be used by an application to directly

create a COM object without acquiring the object's class factory. However, internally, the

CoCreateInstance() API itself will invoke the CoGetClassObject() API to obtain the

object's class factory and then use the class factory's CreateInstance() method to create

the COM object.

VBScript supplies the New keyword as well as the CreateObject() global function for

object instantiation. These language constructs encapsulate the acquisition of the class

factory object of the target object (via the CoGetClassObject() API) followed by the

invocation of the IClassFactory::CreateInstance() method. Other languages, e.g.

PowerBuilder's PowerScript may also provide their own high-level object creation

constructs. However, CoGetClassObject() and the IClassFactory interface remain the

most fundamental object creation technique.

COM Reflection

At the time of the inception of COM technologies, the only way for a client to find out

what features an object would offer, was to actually create one instance and call into its

QueryInterface method (part of the required IUnknown interface). This way of

exploration became awkward for many applications, including the selection of

appropriate components for a certain task, and tools to help a developer understand how

to use methods provided by an object.

As a result, COM Type Libraries were introduced, through which components can

describe themselves. A type library contains information such as the CLSID of a

component, the IIDs of the interfaces the component implements, and descriptions of

each of the methods of those interfaces. Type libraries are typically used by Rapid

Application Development (RAD) environments such as Visual Basic or Visual Studio to

assist developers of client applications.

Sample Code

Following are two examples that illustrate the COM concepts covered in the article. The

code is also contained in the article's sample project.

Using a COM object with a single interface

The first example shows how to use a COM object that exposes a single interface. This is

the simplest case you'll ever encounter. The code uses the Active Desktop coclass

contained in the shell to retrieve the filename of the current wallpaper. You will need to

have the Active Desktop installed for this code to work.

The steps involved are:

1. Initialize the COM library.

2. Create a COM object used to interact with the Active Desktop, and get an

IActiveDesktop interface.

3. Call the GetWallpaper() method of the COM object.

4. If GetWallpaper() succeeds, print the filename of the wallpaper.

5. Release the interface.

6. Uninitialize the COM library.

WCHAR wszWallpaper [MAX_PATH];

CString strPath;

HRESULT hr;

IActiveDesktop* pIAD;

1. Initialize the COM library (make Windows load the DLLs). Normally

you wouldcall this in your InitInstance() or other startup code. In

MFC apps, use AfxOleInit() instead.

CoInitialize ( NULL );

2. Create a COM object, using the Active Desktop coclass provided by

the shell.The 4th parameter tells COM what interface we want

(IActiveDesktop).

hr = CoCreateInstance ( CLSID_ActiveDesktop,

NULL,

CLSCTX_INPROC_SERVER,

IID_IActiveDesktop, (void**) &pIAD );

if ( SUCCEEDED(hr) )

{

3. If the COM object was created, call its GetWallpaper() method.

hr = pIAD->GetWallpaper ( wszWallpaper, MAX_PATH, 0 );

if ( SUCCEEDED(hr) )

{

4. If GetWallpaper() succeeded, print the filename it returned.

Note that I'm using wcout to display the Unicode string

wszWallpaper.

wcout is the Unicode equivalent of cout.

wcout << L"Wallpaper path is:\n " << wszWallpaper << endl <<

endl;

}

else

{

cout << _T("GetWallpaper() failed.") << endl << endl;

}

5. Release the interface.

pIAD->Release();

}

else

{

cout << _T("CoCreateInstance() failed.") << endl << endl;

}

6. Uninit the COM library. In MFC apps, this is not necessary

since MFC does it for us.

CoUninitialize();

Distributed Component Object Model (DCOM) DCOM is a proprietary Microsoft technology for communication among software

components distributed across networked computers. DCOM, which originally was

called "Network OLE", extends Microsoft's COM, and provides the communication

substrate under Microsoft's COM+ application server infrastructure. It has been

deprecated in favor of the Microsoft .NET Framework.The addition of the "D" to COM

was due to extensive use of DCE/RPC (Distributed Computing Environment/Remote

Procedure Calls) – more specifically Microsoft's enhanced version, known as MSRPC.

In terms of the extensions it added to COM, DCOM had to solve the problems of

• Marshalling – serializing and deserializing the arguments and return values of

method calls "over the wire".

• Distributed garbage collection – ensuring that references held by clients of

interfaces are released when, for example, the client process crashed, or the

network connection was lost.

One of the key factors in solving these problems is the use of DCE/RPC as the underlying

RPC mechanism behind DCOM. DCE/RPC has strictly defined rules regarding

marshalling and who is responsible for freeing memory.

DCOM was a major competitor to CORBA. Proponents of both of these technologies saw

them as one day becoming the model for code and service-reuse over the Internet.

However, the difficulties involved in getting either of these technologies to work over

Internet firewalls, and on unknown and insecure machines, meant that normal HTTP

requests in combination with web browsers won out over both of them. Microsoft, at one

point, attempted and failed to head this off by adding an extra http transport to DCE/RPC

called ncacn_http (Network Computing Architecture, Connection-based, over HTTP).

This was later resurrected to support a Microsoft Exchange 2003 connection over HTTP.

COM Object Reuse

Reusability is the mantra for the success of any technology in the field of programming.

C++ supports the reusability by providing the concept of inheritance. Inheritance is the

way by which the subclass inherits the functionality from its base class (parent class).

The subclass has the option to modify the functionality, which has been provided by the

base class (overriding), or to continue with the same functionality as that of the base

class. Inheritance has made the life of the programmers easier, but this has a problem

associated with it. Implementation inheritance, which is supported by C++, creates a

strong bonding or the contract between the base class and a subclass. Any changes in the

base class can cause a drastic affect on the child class and may cause the clients of the

child class to break. Implementation Inheritance is not an appropriate technology to

create a reusable components, which could be used anywhere, at anytime, by anybody

without worrying about the internal implementation of the component.

COM doesn’t support the Implementation inheritance as it violates the motto of the COM

technology i.e. to create the reusable components. COM does support the Interface

inheritance, in which the subclass inherits the interface of the base class and not the

implementation. Interface inheritance protects the clients of a component from change.

Implementation inheritance can be simulated in COM by using the concept of component

containment. In COM, the reusability is achieved by using containment and aggregation.

This article will be covering the Containment technique, in which the outer component

uses the inner component, in detail. The Aggregation will be covered in a separate article

Containment

Everything in COM is related with the interfaces. Containment is also implemented at the

interface level. The COM containment is same as the C++ containment, in which the

outer component is a client of an inner component. The outer component has pointers to

interfaces on the inner component. The inner component is not exposed directly to the

client and hence only the IUnknown of the outer component will be exposed to the client.

In Containment, the outer component forwards (delegates) the calls to the inner

component.

There could be two scenarios in which the containment can be implemented. The first

case is the outer component implements its own interfaces and uses the interfaces of the

inner component. The second case could be that the outer component reimplements an

interface supported by the inner component and forward the call to the interface of the

inner component.

In Contain ment, the outer component is acting as a client and using the interface of the

inner component. In implementing the containment, the inner component and client are

unaware of the fact that they are being the part of the containment implementation. The

outer component has to be modified to support the containment.

Sample code This article will explore the first scenario to explain the containment technique. In this

sample code, the outer component utilizes the functionality, which is being provided by

an inner component. The outer component needs some modification to accommodate the

inner component as a contained object. The client and an inner component won’t be

affected and will be unaware of the fact that they are taking part in the containment

implementation. This sample code will demonstrate that the client is unfamiliar with the

fact that the outer component is using the services of an inner component.

The outer component i.e. CMath will have a new member variable m_pISqaure, which is

a pointer to ISquare interface on the inner component.

class CMath : public IMath {

public:

// Implementing IUnknown Interface.

virtual HRESULT __stdcall QueryInterface(const IID& iid,void

**ppv);

virtual ULONG __stdcall AddRef();

virtual ULONG __stdcall Release();

//Implementing IMath Interface.

virtual void _STDCALL SumSquare(int Val1,int Val2,int*

pResult);

// Constructor

CMath();

// Destructor

~CMath();

// Pointer to ISquare interface on the inner component.

ISquare* m_pISquare;

private:

long m_cRef;

};

As this COM Server (ContainmentSample.dll) supports two COM Components i.e. CMath

and CSquare, therefore DllGetClassObject should have a validation for these two

ClassIDs.

// Code Snippet for DllGetClassObject.

// COM SCM creates a class object only when the request has

come for CLSID_CMath and CLSID_CSquare. After creating the

// class object, the IClassFactory interface pointer on the

// class object is returned back to the client.

STDAPI DllGetClassObject(const CLSID & clsid,const IID& iid,

void **ppv)

{

// This server supports two COM Components and hence

// validation is performed.

if((clsid == CLSID_CMath) || (clsid == CLSID_CSquare)) {

cout<<"The requested component is supported by "

"COM server (ContainmentSample.dll)" << endl;

}

else

{

return CLASS_E_CLASSNOTAVAILABLE;

}

CFactory *pFactory = new CFactory();

if (pFactory == NULL) {

return E_OUTOFMEMORY;

}

HRESULT hResult = pFactory->QueryInterface(iid,ppv);

static_cast<< IUnknown* >>(pFactory)->Release();

return hResult;

}

The CreateInstance for the outer component has to be modified to accommodate the

creation of an inner component and storing the ISquare interface on the inner

component in its member variable i.e. m_pISqaure. The outer component calls the

CoCreateInstance with the CLSID parameter as CLSID_CSquare and queries for

ISquare interface on the inner component (CSquare), and if the call is succeeds it stores

the interface pointer in m_pISqaure.

//Code Snippet for CreateInstance of Class Object.

//This snippet shows the part of the code which is

//executed during the creation of an outer component.

//This is executed when the client calls the CreateInstance,

//after getting the IClassFactory

//interface pointer on CMath's instance.

//The client gets the IClassFactory interface pointer by

//calling CoGetClassObject.

if ((iid == IID_IMath) || (iid == IID_IUnknown)) {

CMath* pMath = new CMath();

if(pMath == NULL) {

return E_OUTOFMEMORY;

}

// Here, the Outer Component initializes the inner component.

// The CoCreateInstance is called by

// the outer component during its creation and

// it queries for the ISquare interface on the inner

// component, and if the calls succeeds it stores the pointer

// in its variable m_pISqaure.

cout<<"Call to Create the Inner Component" << endl;

hResult =CoCreateInstance (CLSID_CSquare, NULL,

CLSCTX_INPROC_SERVER,

IID_ISquare,(void**)&pMath->m_pISquare);

cout<<"CoCreateInstance for CSquare has been called"<< endl;

hResult = pMath->QueryInterface(iid,ppv);

if(SUCCEEDED(hResult)) {

pMath->Release();

}

}

Interfaces and Versioning

A good versioning mechanism allows one system component to be updated without

requiring updates to all the other components in the system. Versioning in COM is

implemented using interfaces and IUnknown::QueryInterface. The COM design

completely eliminates the need for things like version repositories or central management

of component versions.

When a software module is updated, it is generally to add new functionality or to improve

existing functionality. In COM, you add new functionality to your component object by

adding support for new interfaces. Since the existing interfaces don't change, other

components that rely on those interfaces continue to work. Newer components that know

about the new interfaces can use those newly exposed interfaces. Because

QueryInterface calls are made at run time without any expensive call to some

"capabilities database" (as used in some other system object models), the current

capabilities of a component object can be efficiently evaluated each time the component

is used; when new features become available, applications that know how to use them

will begin to do so immediately.

Improving existing functionality is even easier. Because the syntax and semantics of an

interface remain constant, you are free to change the implementation of an interface,

without breaking other developers components that rely on the interface. For example,

say you have a component that supports the (hypothetical) IStack interface, which would

include methods like Push and Pop. You've currently implemented the interface as an

array, but you decide that a linked list would be more appropriate. Since the methods and

parameters do not change, you can freely replace the old implementation with a new one,

and applications that use your component will get the improved linked list functionality

"for free."

Windows and OLE use this technique to provide improved system support. For example,

in OLE today, structured storage is implemented as a set of interfaces which currently use

the C run-time file input/output functions internally. In Windows 2000 (the next version

of Windows NT), those same interfaces will write directly to the file system. The syntax

and semantics of the interfaces remain constant; only the implementation changes.

Existing applications will be able to use the new implementation without any changes;

they get the improved functionality "for free."

The combination of the use of interfaces (immutable, well-defined "functionality sets"

that are extruded by components) and QueryInterface (the ability to cheaply determine

at run time the capabilities of a specific component object) enable COM to provide an

architecture in which components can be dynamically updated, without requiring updates

to other reliant components. This is a fundamental strength of COM over other proposed

object models. COM solves the versioning/evolution problem where the functionality of

objects can change independently of clients of that object without rendering existing

clients incompatible. In other words, COM defines a system in which components

continue to support the interfaces through which they provided services to older clients,

as well as support new and better interfaces through which they can provide services to

newer clients. At run time old and new clients can safely coexist with a given component

object. Errors can only occur at easily handled times: bind time or during a

QueryInterface call. There is no chance for a random crash such as those that occur

when an expected method on an object simply does not exist or its parameters have

changed.

Language Independence

Components can be implemented in a number of different programming languages and

used from clients that are written using completely different programming languages.

Again, this is because COM, unlike an object-oriented programming language, represents

a binary object standard, not a source code standard. This is a fundamental benefit of a

component software architecture over object-oriented programming (OOP) languages.

Objects defined in an OOP language typically interact only with other objects defined in

the same language. This necessarily limits their reuse. At the same time, an OOP

language can be used in building COM components, so the two technologies are actually

quite complementary. COM can be used to "package" and further encapsulate OOP

objects into components for widespread reuse, even within very different programming

languages.

.NET Components

• It is a platform neutral framework.

• Is a layer between the operating system and the programming language.

• It supports many programming languages, including VB.NET, C# etc.

• .NET provides a common set of class libraries, which can be accessed from any

.NET based programming language. There will not be separate set of classes and

libraries for each language. If you know any one .NET language, you can write

code in any .NET language!

• In future versions of Windows, .NET will be freely distributed as part of

operating system and users will never have to install .NET separately.

.NET Framework Assemblies The .NET framework introduces assemblies as the main building blocks of your

application. An application can contains one or more assemblies. An assembly can be

formed in one or more files. This all depends on your programming needs.

An assembly can consist of the following four elements: Your code, compiled into MS

intermediate language (MISL). This code file can be either an EXE file or a DLL file.

The assembly manifest, which is a collection of metadata that describes assembly name,

culture settings, list of all files in the assembly, security identity, version requirements,

and references to resources. The assembly manifest can be stored with the intermediate

code, or in a standalone file that contains only assembly manifest information.

1. Type metadata

2. Resources

The main and only required element of the above four elements is the assembly manifest.

The remaining elements are optional depending on your requirements.

As we have mentioned above, an assembly can be formed into a single physical file. In

this case all the above four elements will be stored inside this file (either an EXE, or a

DLL file). Or it can be formed in more than one file, and in this later case we call it a

multi-file assembly. In multi-file assembly the above four elements can be stored in

separate files like module files for code, resources files for images, or other files required

by the application. Note that the files that forms the multi-file assembly are not physically

linked, instead they are linked through the assembly manifest.

You may ask yourself, when should I use multi-file assembly technique? The answer is,

you should use this form of assembly when you want to combine modules written in

different languages, when you want to optimize downloading an application that consists

of more than one module, or when you want to use a huge resource file so you put it in a

separate resource file and the .NET framework will download it only when it is

referenced which will optimize your memory usage and system resources.

Benefits of Using Assemblies

Assemblies are mainly introduced to solve the problems of versioning, DLL conflicts,

and simplifying the process of deployment. Most end users have encountered versioning

or deployment problems when they do install a new application or a new version of an

existing one. There are many situations where you install a new application only to find

an existing one stopped working, and the system can not recover from that. Many

developers spent a lot of time trying to retain the registry entries consistence in order to

activate a COM class. All this frustration occurs because of versioning problems that

occur with component-based applications.

Versioning Problems

There are two versioning problems that arise with WIN32 applications. The first one is

that versioning rules are enforced by the operating system not between the pieces of an

application. Backward compatibility between the new piece of code and the old one is the

current approach of versioning and this is hard to maintain in most applications. Beside

that only a single version of an application is allowed to be present and executing on a

computer at any given time. The second problem is that there is no way to preserve

consistency between groups of components that are built together and the current present

group at run time.

DLL Conflicts

As a result of the above two versioning problems, DLL conflicts do occur. Which is:

when installing a new application an existing one may break because of that the new one

installed a new version of a component or a DLL that is not fully backward compatible

with the previous one.

The Solution

To solve the above problems, Microsoft began a new approach in its Windows 2000

platform. Windows 2000 gives you the ability to place DLL files used by your

application in the same directory as your application's exe file, so that your application

can use the right version it was designed for using. Beside that, Windows 2000 locks files

that exist in the System32 directory to prevent their replacement when new applications

are installed, and this prevents the DLLs that are used by existing applications from being

replaced and so prevents the crashing of existing applications.

The .NET framework introduces assemblies as an evolution towards the complete

solution of versioning problems and DLL conflicts. Assemblies on their core design give

developers the ability to specify version rules between components, offer the

infrastructure required to enforce these rules, and allowing multiple versions of the

component to be run side by side at the same time.

How Does It Work?

You may recall that an assembly manifest contains the versioning requirements of the

current assembly. The version of the assembly and the versions of the required

assemblies and/or components are recorded in the manifest. So, when you run an

application, the .NET runtime checks the assembly manifest of your application and

executes the version of assemblies or components that are recorded in the manifest. To

gain the advantages of versioning you must give your assembly a strong name (will be

explained later).

Assembly Version

An assembly can have two types of versions. The first one which we call "Version

Number" consists of a four-part string with the following format:

<Major Version>.<Minor Version>.<Build Number>.<Revision Number>

For example a version number of 3.5.20.1 indicates 3 as the major version, 5 as the minor

version, 20 as the build number, and 1 as the revision number. Note that the version

number is stored in the assembly's manifest. The second type of versions is called

"Informational Version". The informational version consists of a string that contains the

version number besides additional information like packaging, marketing literature, or

product name. This type of version is used for informational purposes only, and is not

used at runtime for calculating versioning related decisions.

Assembly Locations

An assembly can be placed into one of the following three locations:

1. Under the application directory or subdirectories. This is the most common

location for placing an assembly. If your assembly uses a culture other than the

default one which is "en-US", you have to put it under a subdirectory with this

culture name.

2. In the global assembly cache, which is a machine code cache installed whenever

the common language runtime is installed. You deploy your assembly to the

global assembly cache when you want to share it with multiple applications.

3. On an ftp server.

The location of an assembly determines whether the common language runtime can

locate it when it is referenced and whether this assembly can be shared with other

applications or not.

The Manifest

How .NET makes sure the right version of every assembly is used?

In the bad old days of COM, shared components were usually dumped into that

unorganized Windows warehouse, the System directory, and then "registered" in

Windows so other programs could locate them. This is a big reason why the registry is

such a critical and sensitive part of Windows. Without it, one piece of software can't

locate another one. (The registry is still used in .NET, by the way. But .NET doesn't use it

to identify components anymore.) In .NET, every assembly starts with something called a

manifest that takes the place of the information that was formerly placed in the registry.

The manifest contains metadata (data about data) telling the CLR what it needs to know

to execute the assembly instructions. One of the things the CLR needs to know is the

version number of components used by the assembly. To illustrate the point, let's

compare the manifest of a very simple 1.1 and 2.0 .NET component (DLL file) using the

ILDASM utility. This is a standard tool that is installed with the .NET Framework and it

lets you look inside the IL code in an assembly.

.NET Application Domains

Overview

Before .NET framework 2.0 technology, the only way used to isolate applications

running on the same machine is by the means of process boundaries. Each application run

within a process, and each process has its own boundaries and memory addresses relative

to it and this is how isolation from other processes was performed.

.NET framework 2.0 introduces a new boundary called the Application Domains. Each

application running within its main process boundaries and its application domain

boundaries. So, you can think of the application domain as an extra shell to isolate the

application and making it more secure and robust.

The above is not the main advantage of application domains. The main advantage is the

ability to run several applications domains in a single process or application. All of this is

performed while maintaning the same level and quality of isolation that would exist in

separate processes, without the need of making cross-process calls or switching between

processes.

Advantages

The following advantages of application domains answer this question.

• In terms of isolation, code running in one application domain can not access code

or resources running in another application domain.

• In terms of security, you can run more than one set of web controls in a single

browser process. Each set of them is running in a separate application domain so

each one can not access the data or resources of the other sets. You can control

the permissions granted to a given piece of code by controlling the application

domain inside which the code is running.

• In terms of robustness, fault in code running in one application domain can not

affect other applications although they all are running inside the same process.

Individual application domain can be stopped without stopping the entire process,

you can simply unload the code running in a single application domain.

So, from the above advantages, you can observe that by using application domains you

can create rather robust .NET applications. It increases isolation, stability, and security of

your application.

Relation Between Application Domains and Assemblies

Most development and runtime environments has a definition for the building blocks of

an application. Assemblies are the building blocks of .NET framework applications. They

are the fundamental unite of deployment. An assembly consists of types and resources

working together to form a logical unit of the functionality of your application. You can

divide your .NET application into assemblies. The assembly file can have an .EXE or a

.DLL extension.

As we mentioned previously, you can run more than one application domain within your

application. Each application domain will run a given piece of code. An assembly is

simply the piece of code we mean here. So, each application domain can run an assembly

within the entire application. This is the relation between application domains and

assemblies.

Whenever we start an application, we're actually starting a Win32 process and running

our application inside it. These processes use resource such as memory, objects, kernel

and blah blah blah. Each Win32 process contains at the least one thread (eventually we

end up running multiple threads) and if we are to run other tasks or open up other

applications through our application, these tasks will belong to our particular Win32

process running on a collection of multiple threads.

One of the characteristics of a Win32 process is that it is very much similar to a virtual

boundary. It's pretty easy to communicate within a process but the same is restricted to a

certain level outside that particular Win32 process. To interact with other Win32

processes, we would require some special mechanisms to work on as there are a couple of

security contexts we would have to take into consideration and also the need to restrict

what a Win32 process can and should do on a particular system. So who takes care of

running a process and what are the factors involved in running a process successfully? The

execution of a process and running our code within it is usually the domain and prerogative of the

operating system. There are many complex situations and issues that the Operating System has to

handle while maintaining an active process.

.NET Context

All applications run within an application domain, and this domain can contain numerous

contexts…an application which is executing within a given app domain isn’t necessarily

tied to one specific context though, it is free to switch contexts freely (meaning it is

context agile); thus getting a reference to a specific object means obtaining a direct

reference which makes it impossible to hook into and perform processing on the

messages the object contains (method calls, exceptions, etc). By deriving an object from

ContextBoundObject you force the runtime to isolate the object into a single context

where it will remain for it’s entire lifetime. Any hooks into this object from other

contexts are done via a runtime generated proxy which is a reference to the object; there

are no direct hooks into the object itself. As it’s a proxy, it is now possible to write your

own sinks to hook into the message chain and perform any type of processing you’d like.

This is comparable to remoting in .Net (and indeed most of the objects needed for this

live in the System.Runtime.Remoting namespace), albeit on a smaller scale.

So how does this relate to real world programming? There are certain services that need

to be applied to every layer of the application and are not domain specific; in the case of

the typical 3 tier app which contains a data layer, a business layer, and a presentation

layer; they all need common services such as logging and exception management. The

most common approach to solve this is to write a separate utility library that

accomplishes the functionality you need, and then just reference it from your

projects…this can create unneeded dependencies though, and in the case of exceptions

means lots of try/catch blocks with logging code in each catch block (in the case of a web

application, I do realize this can be centralized in Application_OnError which is great in

theory, but is usually not used out in the real world). This can get a quite messy in larger

applications. In this case, I’ll attempt to provide an alternate solution to this by providing

a simple example that centralizes exception logging by using a ContextAttribute and a

ContextBoundObject which allows the attribute to hook into the message chain.

A channel is needed inside an application domain: calling objects across contexts.If

you’ve previously written COM+ components, you already know about COM+ contexts.

Contexts in .NET are very similar. A context is a boundary containing a collection of

objects. Likewise, with a COM+ context, the objects in such a collection require the same

usage rules that are defined by the context attributes.

As you already know, a single process can have multiple application domains. An

application domain is something as a subprocess with security boundaries. An application

domain can have different contexts. A context is used to group objects with similar

execution requirements. Contexts are composed from a set of properties and are used for

interception: when a context-bound object is accessed by a different context, an

interceptor can do some work before the call reaches the object. This can be used for

thread synchronization, transactions, and security management, for example.

A class derived from MarshalByRefObject is bound to the application domain. Outside

the application domain a proxy is needed to access the object. A class derived from

ContextBoundObject, which itself derives from MarshalByRefObject, is bound to a

context. Outside the context, a proxy is needed to access the object.

Context-bound objects can have context attributes. A context-bound object without

context attributes is created in the context of the creator. A context-bound object with

context attributes is created in a new context or in the creator’s context if the attributes

are compatible.

To further understand contexts, you must be familiar with these terms:

• Creating an application domain creates the default context in this application domain.

If a new object is instantiated that needs different context properties, a new context is

created.

• Context attributes can be assigned to classes derived from ContextBoundObject. You

can create a custom attribute class by implementing the interface IContextAttribute.

The .NET Framework has one context attribute class in the namespace

System.Runtime.Remoting.Contexts: SynchronizationAttribute.

• Context attributes define context properties that are needed for an object. A context

property class implements the interface IContextProperty. Active properties

contribute message sinks to the call chain. The class ContextAttribute implements

both IContextProperty and IContextAttribute, and can be used as a base class for

custom attributes.

• A message sink is an interceptor for a method call. With a message sink, method calls

can be intercepted. Properties can contribute to message sinks.

Activation

A new context is created if an instance of a class that’s created needs a context different

from the calling context. The attribute classes that are associated with the target class are

asked if all the properties of the current context are acceptable. If any of these properties

are unacceptable, the runtime asks for all property classes associated with the attribute

class and creates a new context. The runtime then asks the property classes for the sinks

they want to install. A property class can implement one of the IContributeXXXSink

interfaces to contribute sink objects. Several of these interfaces are available to go with

the variety of sinks.

Communication Between Contexts

How does the communication between contexts happen? The client uses a proxy instead

of the real object. The proxy creates a message that is transferred to a channel, and sinks

can intercept. Does this sound familiar? It ought to. The same mechanism is used for

communication across different application domains or different systems. A TCP or

HTTP channel is not required for the communication across contexts, but a channel is

used here too. CrossContextChannel can use the same virtual memory in both the client

and server sides of the channel, and formatters are not required for crossing contexts.

Introduction to .NET Reflection Programming languages like C++ had the ability to collect information on the types. But

this ability had limited scope. With .NET there is a powerful mechanism called .NET

Reflection that not only allows you to introspect types but also raise methods on those

types during runtime. Though the process of retrieving types information in .NET

Reflection is slow compared to direct access of a method, property, or field, .NET

Reflection provides dynamic execution of code and controls when used sparingly. All

types with their methods are stored in assemblies.

Assemblies are the most integral part of any .NET application. All the functionality of

.NET application can be exposed through assemblies. The .NET Reflection provides you

with Application Programming Interface (APIs) to inspect assemblies. Apart from

inspecting assemblies, reflection APIs also allows you to dynamically create assembly in

memory and use it in your program code. All the APIs related to .NET Reflection are

located under System.Reflection namespace. These .NET Reflection APIs are also used

to develop applications editors, class browsers, and add-ons for Integrated Development

Environment (IDEs).

Since .NET most often uses types, .NET Reflection is frequently required when you do

not know the particular type that you are dealing with at compile time. For example, if

you dynamically create server-side controls or objects at runtime, or use meta-based

programming where some of the data is dynamically created based on data stored in a

database, you often create things in hurry. This is where the .NET Reflection comes to

rescue when it can be used against these ‘dynamic’ runtime generated objects which the

compiler knows nothing about.

There are other usages for .NET Reflection like compilers for languages such as JScript

make use of reflection to construct symbol tables and the classes in the

System.Runtime.Serialization namespace makes use of reflection to access data and to

determine which fields to persist. Moreover, fhe classes in the System.Runtime.Remoting

namespace also use reflection through serialization.

Reflection – The process of getting the metadata from modules / assemblies. Whwn .net

code is compiled, metadata about the types defined in the modules is produced. These

modules isproduced. These modules are in turn packaged as assemblied. The process of

accessing this metadata is called Reflection. The namespace Syste.Reflection contains

classes that can be used for interrogating the types for a module/assembly. We use

reflection for examining data type sizes for marshalling across process and machine

boundaries.

Reflection is also used for:

1) To dynamically invoke methods (using System.Type.InvokeMember)

2) To dynamically create types at runtime(using System.Reflection.Emit.TypeBuilder)

The System.Type Class The System.Type class is the main class for the .NET Reflection functionality and is the

primary way to access metadata. The System.Type class is an abstract class and that

represents a type in the Common Type System (CLS). It represents type declarations:

class types, interface types, array types, value types, enumeration types, type parameters,

generic type definitions, and open or closed constructed generic types.

Use the members of Type to get information about a type declaration, such as the

constructors, methods, fields, properties, and events of a class, as well as the module and

the assembly in which the class is deployed. Three ways to obtain a Type reference:

Metadata & Reflection

Reflection is the ability to read metadata at runtime. Using reflection, it is possible to

uncover the methods, properties, and events of a type, and to invoke them dynamically.

Reflection also allows us to create new types at runtime, but in the upcoming example we

will be reading and invoking only.

Reflection generally begins with a call to a method present on every object in the .NET

framework: GetType. The GetType method is a member of the System.Object class, and

the method returns an instance of System.Type. System.Type is the primary gateway to

metadata. System.Type is actually derived from another important class for reflection: the

MemeberInfo class from the System.Reflection namespace. MemberInfo is a base class

for many other classes who describe the properties and methods of an object, including

FieldInfo, MethodInfo, ConstructorInfo, ParameterInfo, and EventInfo among others. As

you might suspect from thier names, you can use these classes to inspect different aspects

of an object at runtime.

.NET Remoting Remoting enables software components to interact across application domains. The

components interacting with each other can be in different processes and systems. This

enables us to create n-tier Distributed applications. Here is a simplified illustration of the

.NET Remoting Architecture.

The Key Players are: ...........- Client Object

...........- Server (Remote) Object

...........- Proxy Object

...........- Formatter

...........- Channel

Client Object is the object or component that needs to communicate with(call) a remote

object.

The Server (Remote) Object receives the request from the client object and responds.

Proxy Object When the client object needs to call a method from the Remote Object it

uses a proxy object to do this. Every public method that defined in the remote object class

can be made available in the proxy and thus can be called from clients. The proxy object

acts as a representative of the remote object. It ensures that all calls made on the proxy

are forwarded to the correct remote object instance. There are two types of proxies

transparent and real proxy

The TransparentProxy contains a list of all classes, as well as interface methods of the

remote object. It examines if the call made by the client object is a valid method of the

remote object and if an instance of the remote object resides in the same application

domain as the proxy. If this is true, a simple method call is routed to the remote object. If

the object is in a different application domain, the call (call parameters on the stack are

packaged into an IMessage object) is forwarded to a RealProxy class by calling its

Invoke method. This class is then responsible for forwarding messages to the remote

object.

Formatter

The formatting can be done be done in three ways –

...........a) Binary

...........b) SOAP or

...........c) Custom.

The remoting framework comes with two formatters: the binary and SOAP formatters.

The binary formatter is extremely fast, and encodes method calls in a proprietary, binary

format. The SOAP formatter is slower. Developers can also write their own Custom

Formatter and have the ability to use that.

Channels

Channels are used to transport messages to and from remote objects. You can choose a

TcpChannel or a HttpChannel or extend one of these to suit your requirements.

HTTP channel : The HTTP channel transports messages to and from remote objects

using the SOAP protocol. However, All messages are passed through the SOAP

formatter, where the message is changed into XML and serialized, and the required

SOAP headers are added to the stream. The resulting data stream is then transported to

the target URI using the HTTP protocol.

TCP Channel : The TCP channel uses a binary formatter to serialize all messages to a

binary stream and transport the stream to the target URI using the TCP protocol. It is also

possible to configure the TCP channel to the SOAP formatter.

Connectors

An Architecture Description Language (ADL) is a computer language used to describe

software and/or system architectures. An Architecture Description Language (ADL) is a

language designed to model a system. They have often graphical as well as plain text

syntax. Architecture Description Languages (ADLs) are computer languages describing

the software and hardware architecture of a system. The description may cover software

features such as processes, threads, data, and subprograms as well as hardware

component such as processors, devices, buses, and memory. The connections between the

components can be described in logical as well as physical terms. The difference between

an ADL and a programming language or a modelling language is not totally clear.

However, there are some requirements for a language to be classified as an ADL:

• It should be suitable for communicating architecture to all interested

parties.

• It should support the tasks of architecture creation, refinement and

validation.

• It should provide a basis for further implementation, so it must be able to

add information to the ADL specification to enable the final system

specification to be derived from the ADL.

• It should provide the ability to represent most of the common architectural

styles.

• It should support analytical capabilities or provide quick generating

prototype implementations.

Connector components The connector for SAP is written in Java and consists of two parts: the vision connector

framework and connector modules (the connector's application-specific component, the

connector framework, and business object handlers). The vision connector framework

provides a metadata-driven layer of abstraction to the connector framework used by all

WebSphere business integration system adapters. The vision connector framework

extends the methods in the Adapter Framework. The connector modules extend the

methods in the vision connector framework and communicate with an SAP application.

Figure illustrates the architecture of the connector and the relationship of the system-wide

and vision connector frameworks. The visionConnectorAgent class can implement any

number of connector modules.

Figure Architecture of the connector for SAP

Real-Time Object-Oriented Modeling (ROOM)

Model real time systems based on timeliness, dynamic internal structure, reactiveness,

concurrency and distribution, using the ROOM notation.

ROOM is an object-oriented methodology for real-time systems developed originally at

Bell-Northern Research. ROOM is based upon a principle of using the same model for all

phases of the development process. ROOM models are composed of actors which

communicate with each other by sending messages along protocols. Actors may be

hierarchically decomposed, and may have behaviors described by ROOM charts, a

variant of Harel's state charts. Descriptions of actors, protocols, and behaviors can all be

reused through inheritance. Edraw contains special shapes and setting for creating

ROOM diagrams. In Edraw Professional, the ROOM Diagrams template and shapes are

in the Software folder.

ROOM Diagram Symbols

Some symbols can changed into other shapes. When you drag them into the canvas, a

dialog popup. Then you can choose the types.

For example:

Modified Actor Ref. An actor is an active architectural component of a software system.

Actors interact with their environment via ports. A dynamic actor is created and

destroyed by the containing actor.

Ports provide an interface between actors using protocols that define how information

should be accessed and changed.

ROOM Port Type

• Relay port - Shares the interface between a contained class and the container

class.

• Conjugated port - Handles both the outgoing and incoming messages of its

protocol. Conjugated ports are usually white colored.

• External end port - Communicates with the actor's state machine or behavior.

• Internal end port - Connects a component actor to the container actor's behavior.

It is illustrated using the same notation as an external end port, but the port is

placed inside the container border rather than on it.

Transition points

• Initial transition point - Indicates the first transition within the state.

• Choice point - Indicates a choice between transition path segments. One path will

be the default.

• Non-extending transition point - Marks the end of a transition that does not extend

outside of the state context.

• Non-extending transition point - Illustrates an incoming transition.

Contextual Framework Contextual Composition

The final form of composition in our little list is contextual composition. The typical

examples here are EJB containers and .NET enterprise services contexts. Unlike

connection-oriented composition, contextual composition is implicit and asymmetric. A

component instance inside a container instance benefits from container-supplied services

and from a container-maintained abstraction (simplification) of the world outside the

container. For example, a container can add transactional processing and limit what a

contained instance can and cannot see.

How is a container different from a platform? It depends. Some platforms actually have

container properties. For example, operating systems that strongly isolate processes form

process containers. As a result, two applications running in separate processes of such an

operating system can communicate with each other only through the mechanisms

provided and controlled by the operating system. Other platforms don't form containers:

They don't intercept all incoming and all outgoing communications and thus can be

bypassed.

How is a container different from a set of connections? A container completely encloses

its contained instances, while the same can be established only by convention for peer-to-

peer connections. Also, a container is implicitly connected to all instances inside—all

enclosed instances uniformly benefit from their single shared container instance's

services and all are uniformly constrained by that container's policies.

EJB containers An Enterprise JavaBeans (EJB) container provides a run-time environment for enterprise

beans within the application server. The container handles all aspects of an enterprise

bean's operation within the application server and acts as an intermediary between the

user-written business logic within the bean and the rest of the application server

environment.

One or more EJB modules, each containing one or more enterprise beans, can be installed

in a single container. The EJB container provides many services to the enterprise bean,

including the following:

• Beginning, committing, and rolling back transactions as necessary.

• Maintaining pools of enterprise bean instances ready for incoming requests and

moving these instances between the inactive pools and an active state, ensuring

that threading conditions within the bean are satisfied.

• Most importantly, automatically synchronizing data in an entity bean's instance

variables with corresponding data items stored in persistent storage.

EJB Roles

In RMI there are two fundamental roles in the RMI environment: the client of the remote

object, and the object itself, which acts as a kind of server or service provider. These two

roles exist in the EJB environment as well, but EJB adds a third role, called the container

provider. The container provider is responsible for implementing all the extra services for

an EJB object : transaction processing, security, object persistence, and resource pooling.

If you're familiar with CORBA, you can think of the EJB container as being roughly

equivalent to the ORB in CORBA, with a few of the CORBA services thrown in as well.

In EJB, however, the container is strictly a server-side entity. The client doesn't need its

own container to use EJB objects, but an EJB object needs to have a container in order to

be exported for remote use. Figure shows a conceptual diagram of how the three EJB

roles interact with each other.

Figure The basic roles in an EJB environment

The EJB Container

The EJB container represents the value-added features of EJB over standard remote

objects built using RMI or CORBA. The EJB container manages the details of

transactional processing, resource pooling, and data persistence for you, which reduces

the burden on client applications and EJB objects and allows them to deal with just the

business at hand.

An EJB application server can contain multiple EJB containers, each managing multiple

EJB objects. In this chapter, I'll refer to EJB servers and EJB containers somewhat

interchangeably, depending on the context. In general, though, the container is strictly the

runtime elements that interact directly with your EJB objects to provide client proxy

services and notifications, while the server is the other glue outside the core EJB standard

that integrates the EJB containers into a larger application management structure of some

kind.

An EJB container is the heart of an EJB environment, in the same way an ORB is the

heart of a CORBA environment. The container registers EJB objects for remote access,

manages transactions between clients and EJB objects, provides access control over

specific methods on the EJB, and manages the creation, pooling, and destruction of

enterprise beans. The container also registers the home interface for each type of bean

under a given name in a JNDI namespace, allowing remote clients to find the home

interfaces and use them to create enterprise beans.

Once you provide the EJB container with the home and remote interfaces and the

implementation class for your bean, along with a deployment descriptor, the container is

responsible for generating the various classes that connect these components, as shown in

Figure. The home and remote interfaces you provide are RMI Remote interfaces; the

container generates both the client stubs and the server-side implementation for these

interfaces. When a client looks up a bean's home interface through JNDI, it receives an

instance of the home stub class. All methods invoked on this stub are remotely invoked,

via RMI, on the corresponding home implementation object on the EJB server. Similarly,

if the client creates or finds any beans through the home stub, the client receives remote

object stubs, and methods invoked on the stubs are passed through RMI to corresponding

implementation objects on the server. These remote objects are linked, through the EJB

container, to a corresponding enterprise bean object, which is an instance of your bean-

implementation class. Optionally, the EJB container may also generate a container-

specific subclass of your bean implementation (e.g., if it wants to augment some of your

bean methods to facilitate synchronization with the container).

Figure 7-2. Relationship of bean-provider classes and container-generated classes

The container receives client requests to create, look up, and/or remove beans. It either

handles them itself or passes the requests to corresponding methods on the EJB object.

Once the client obtains a reference to a remote interface for an EJB object, the container

intercedes in remote method calls on the bean, to provide the bean with required

transaction management and security measures. The container also provides support for

persistence of enterprise beans, either by storing/loading the bean state itself or by

notifying the bean that it needs to store or reload its state from persistent storage.

A container can maintain multiple EJB objects and object types during its lifetime. The

container has some freedom to manage resources on the server for performance or other

reasons. For example, a container can choose to temporarily serialize a bean and store it

to the server filesystem or some other persistent store; this is called passivating a bean.

The EJB object is notified of this and given a chance to release any shared resources or

transient data that shouldn't be serialized. The bean is also notified after it is activated

again, to allow it to restore any transient state or reopen shared resources.

An EJB container can make any EJB object type available for remote use. When you

deploy an EJB object within an EJB server, you can specify how the container should

manage the bean during runtime, in terms of transaction management, resource pooling,

access control, and data persistence. This is done using deployment descriptors, which

contain parameter settings for these various options. These settings can be customized for

each deployment of an EJB object. You might purchase an EJB object from a vendor and

deploy it on your EJB server with a particular set of container management options, while

someone else who purchased the same bean can deploy it with a different set of

deployment options.

CLR Contexts and Channels CLR context infrastructure attempts to provide an extensible infrastructure for contextual

composition. Third parties can introduce new properties to context boundaries. CLR

objects come in four top-level flavors:

• Value types

• Pass-by-value types

• Pass-by-reference types

• Context-bound types

Standard types include marshalling over SOAP/HTTP and DCOM

All applications run within an application domain, and this domain can contain numerous

contexts…an application which is executing within a given app domain isn’t necessarily

tied to one specific context though, it is free to switch contexts freely (meaning it is

context agile); thus getting a reference to a specific object means obtaining a direct

reference which makes it impossible to hook into and perform processing on the

messages the object contains (method calls, exceptions, etc). By deriving an object from

ContextBoundObject you force the runtime to isolate the object into a single context

where it will remain for it’s entire lifetime. Any hooks into this object from other

contexts are done via a runtime generated proxy which is a reference to the object; there

are no direct hooks into the object itself. As it’s a proxy, it is now possible to write your

own sinks to hook into the message chain and perform any type of processing you’d like.

This is comparable to remoting in .Net (and indeed most of the objects needed for this

live in the System.Runtime.Remoting namespace), albeit on a smaller scale.

So how does this relate to real world programming? There are certain services that need

to be applied to every layer of the application and are not domain specific; in the case of

the typical 3 tier app which contains a data layer, a business layer, and a presentation

layer; they all need common services such as logging and exception management. The

most common approach to solve this is to write a separate utility library that

accomplishes the functionality you need, and then just reference it from your

projects…this can create unneeded dependencies though, and in the case of exceptions

means lots of try/catch blocks with logging code in each catch block (in the case of a web

application, I do realize this can be centralized in Application_OnError which is great in

theory, but is usually not used out in the real world). This can get a quite messy in larger

applications. In this case, I’ll attempt to provide an alternate solution to this by providing

a simple example that centralizes exception logging by using a ContextAttribute and a

ContextBoundObject which allows the attribute to hook into the message chain.

A channel is needed inside an application domain: calling objects across contexts.If

you’ve previously written COM+ components, you already know about COM+ contexts.

Contexts in .NET are very similar. A context is a boundary containing a collection of

objects. Likewise, with a COM+ context, the objects in such a collection require the same

usage rules that are defined by the context attributes.

Black Box Component Framework

"Another way to customize a framework is to supply it with a set of components that

provide application specific behavior. Each of these components will be required to

implement a particular protocol. All or most of the components might be provided by a

component library. The interface between components can be defined by protocol, so the

user needs to understand only the external interface of the components. Thus, this kind of

a framework is called a black-box framework."

BlackBox Component Builder is an integrated development environment optimized for

component-based software development. It consists of development tools, a library of

reusable components, a framework that simplifies the development of robust custom

components and applications, and a run-time environment for components.

In BlackBox, the development of applications and their components is done in

Component Pascal. This language is a descendant of Pascal, Modula-2, and Oberon. It

provides modern features such as objects, full type safety, components (in the form of

modules), dynamic linking of components, and garbage collection. The entire BlackBox

Component Builder is written in Component Pascal: all library components, all

development tools including the Component Pascal compiler, and even the low-level run-

time system with its garbage collector.

Directory Objects:

A software design pattern, the abstract factory pattern provides a way to encapsulate a

group of individual factories that have a common theme. In normal usage, the client

software creates a concrete implementation of the abstract factory and then uses the

generic interfaces to create the concrete objects that are part of the theme. The client does

not know (or care) which concrete objects it gets from each of these internal factories

since it uses only the generic interfaces of their products. This pattern separates the

details of implementation of a set of objects from their general usage.

In software development, a Factory is the location in the code at which objects are

constructed. The intent in employing the pattern is to insulate the creation of objects from

their usage. This allows for new derived types to be introduced with no change to the

code that uses the base class.

Use of this pattern makes it possible to interchange concrete classes without changing the

code that uses them, even at runtime. However, employment of this pattern, as with

similar design patterns, may result in unnecessary complexity and extra work in the initial

writing of code. Used correctly the "extra work" pays off in the second instance of using

the Factory.

The factory determines the actual concrete type of object to be created, and it is here that

the object is actually created (in C++, for instance, by the new operator). However, the

factory only returns an abstract pointer to the created concrete object.

This insulates client code from object creation by having clients ask a factory object to

create an object of the desired abstract type and to return an abstract pointer to the object.

As the factory only returns an abstract pointer, the client code (which requested the object

from the factory) does not know - and is not burdened by - the actual concrete type of the

object which was just created. However, the type of a concrete object (and hence a

concrete factory) is known by the abstract factory; for instance, the factory may read it

from a configuration file. The client has no need to specify the type, since it has already

been specified in the configuration file. In particular, this means:

• The client code has no knowledge whatsoever of the concrete type, not needing to

include any header files or class declarations relating to the concrete type. The

client code deals only with the abstract type. Objects of a concrete type are indeed

created by the factory, but the client code accesses such objects only through their

abstract interface.

• Adding new concrete types is done by modifying the client code to use a different

factory, a modification which is typically one line in one file. (The different

factory then creates objects of a different concrete type, but still returns a pointer

of the same abstract type as before - thus insulating the client code from change.)

This is significantly easier than modifying the client code to instantiate a new

type, which would require changing every location in the code where a new object

is created (as well as making sure that all such code locations also have

knowledge of the new concrete type, by including for instance a concrete class

header file). If all factory objects are stored globally in a singleton object, and all

client code goes through the singleton to access the proper factory for object

creation, then changing factories is as easy as changing the singleton object.

H-MVC Framework First, let’s start with the famous MVC pattern; we will come back on the ‘H’ of H-MVC

later. The MVC is decomposed in three different components called the Model, the View

and the Controller. Those components are connected to each other in such a way that the

Controller acts as a mediator between the model and the view. Each component can send

and receive events from its connected counter part(s).Let’s see how MVC can help us in

organizing and reusing our code:

• The View is where the interactions with the GUI are programmed. This is

typically the place where user input validation rules are programmed. The view

fires events (called ViewEvents) to the controller, which will process them

accordingly. The View also receives view events from the controller to perform

GUI updates.

• The Controller is a real mediator1: it receives events from either the model or the

view and decides which component must be triggered to process the action. There

is no business logic here; it’s just a relay, which “forwards” events from one

component to the other.

• �The Model contains all the rest! In other words, anything, which is not GUI

related and process flow related. Typically, Business logic and data model

methods would be defined here. The Model, as the above components can send

and receive events (called ModelEvents).

HMVC Design rules

There are a few important rules about this pattern:

1. The Model and the View don’t know anything about each other. They use the

controller to exchange information.

2. There is no constrains on how components talk to each other. It can be a direct method

call, listeners… this framework implements a listener approach.

3. Finally don’t be surprise if you see other declination of this pattern. MVC has been

widely used in the computer industry and hence widely changed. But the main idea

remains the same. Just for information, the framework implements late instantiation in

order to minimize memory usage.

Cross-Development Environment Developers new to embedded development often struggle with the concepts and

differences between native and cross-development environments. Indeed, there are often

three compilers and three (or more) versions of standard header files such as stdlib.h.

Debugging an application on your target embedded system can be difficult without the

right tools and host-based utilities. You must manage and separate the files and utilities

designed to run on your host system from those you intend to use on your target.

When we use the term host in this context, we are referring to the development

workstation that is sitting on your desktop and running your favorite Linux desktop

distribution. Conversely, when we use the term target we are referring to your embedded

hardware platform. Therefore, native development denotes the compilation and building

of applications on and for your host system. Cross-development denotes the compilation

and building of applications on the host system that will be run on the embedded system.

Keeping these definitions in mind will help you stay on track through this chapter.

Figure shows the layout of a typical cross-development environment. A host PC is

connected to a target board via one or more physical connections. It is most convenient if

both serial and Ethernet ports are available on the target. Later when we discuss kernel

debugging, you will realize that a second serial port can be a very valuable asset.

Figure Cross-development setup

In the most common scenario, the developer has a serial terminal on the host connected to

the RS-232 serial port, possibly one or more Telnet terminal sessions to the target board,

and potentially one or more debug sessions using Ethernet as the connection medium.

This cross-development setup provides a great deal of flexibility. The basic idea is that

the host system provides the horsepower to run the compilers, debuggers, editors, and

other utilities, while the target executes only the applications designed for it. Yes, you

can certainly run compilers and debuggers on the target system, but we assume that your

host system contains more resources, including RAM, disk storage, and Internet

connectivity. In fact, it is not uncommon for a target embedded board to have no human-

input devices or output displays.

Cross compiler A cross compiler is a compiler capable of creating executable code for a platform other

than the one on which the compiler is run. Cross compiler tools are used to generate

executables for embedded system or multiple platforms. It is used to compile for a

platform upon which it is not feasible to do the compiling, like microcontrollers that don't

support an operating system. It has become more common to use this tool for

paravirtualization where a system may have one or more platforms in use.

Uses of cross compilers

The fundamental use of a cross compiler is to separate the build environment from the

target environment. This is useful in a number of situations:

• Embedded computers where a device has extremely limited resources. For

example, a microwave oven will have an extremely small computer to read its

touchpad and door sensor, provide output to a digital display and speaker, and to

control the machinery for cooking food. This computer will not be powerful

enough to run a compiler, a file system, or a development environment. Since

debugging and testing may also require more resources than are available on an

embedded system, cross-compilation can be less involved and less prone to errors

than native compilation.

• Compiling for multiple machines. For example, a company may wish to support

several different versions of an operating system or to support several different

operating systems. By using a cross compiler, a single build environment can be

set up to compile for each of these targets.

• Compiling on a server farm. Similar to compiling for multiple machines, a

complicated build that involves many compile operations can be executed across

any machine that is free regardless of its brand or current version of an operating

system.

• Bootstrapping to a new platform. When developing software for a new platform,

or the emulator of a future platform, one uses a cross compiler to compile

necessary tools such as the operating system and a native compiler.

• Compiling native code for emulators for older now-obsolete platforms like the

Commdore 64 or Apple II by enthusiasts who use cross compilers that run on a

current platform (such as Aztec C's MS DOS 6502 cross compilers running under

Windows XP).

Use of virtual machines (such as Java's JVM) resolves some of the reasons for which

cross compilers were developed. The virtual machine paradigm allows the same compiler

output to be used across multiple target systems.

Typically the hardware architecture differs (e.g. compiling a program destined for the

MIPS architecture on an x86 computer) but cross-compilation is also applicable when

only the operating system environment differs, as when compiling a FreeBSD program

under Linux, or even just the system library, as when compiling programs with uClibc on

a glibc host.

Component-Oriented Programming "Component Oriented Programming offers a unique programming-centered approach to

component-based software development that delivers the well-developed training and

practices you need to successfully apply this cost-effective method. There will be a

unified component infrastructure for building component software using JavaBeans, EJB,

OSGi, CORBA, CCM, .NET, and Web services. Component-oriented programming

supports constructing software systems by composing independent components into a

software architecture. However, existing approaches decouple implementation code from

architecture, allowing inconsistencies, causing confusion, violating architectural

properties, and inhibiting software evolution.

Principles of Component-Oriented Programming Systems that support component-oriented programming and the programmers that use

them adhere to a set of core principles that continues to evolve. The most important

of these include:

• Separation of interface and implementation

• Binary compatibility

• Language independence

• Location transparency

• Concurrency management

• Version control

• Component-based security

Separation of Interface from Implementation

The fundamental principle of component-oriented programming is that the basic unit in

an application is a binary-compatible interface. The interface provides an abstract service

definition between a client and the object. This principle contrasts with the object-

oriented view of the world that places the object rather than its interface at the center. An

interface is a logical grouping of method definitions that acts as the contract between the

client and the service provider. Each provider is free to provide its own interpretation of

the interface—that is, its own implementation. The interface is implemented by a black-

box binary component that completely encapsulates its interior. This principle is known

as separation of interface from implementation.

To use a component, the client needs to know only the interface definition (the service

contract) and be able to access a binary component that implements that interface. This

extra level of indirection between the client and the object allows one implementation of

an interface to be replaced by another without affecting client code. The client doesn’t

need to be recompiled to use a new version. Sometimes the client doesn’t even need to be

shut down to do the upgrade. Provided the interface is immutable, objects implementing

the interface are free to evolve, and new versions can be introduced. To implement the

functionality promised by an interface inside a component, you use traditional object-

oriented methodologies, but the resulting class hierarchies are usually simpler and easier

to manage. Another effect of using interfaces is that they enable reuse. In object oriented-

programming, the basic unit of reuse is the object.

In theory, different clients should be able to use the same object. Each reuse instance

saves the reusing party the amount of time and effort spent implementing the object.

Reuse initiatives have the potential for significant cost reduction and reduced product-

development cycle time. One reason why the industry adopted object-oriented

programming so avidly was its desire to reap the benefits of reuse.

Binary Compatibility Between Client and Server

Component-oriented programming revolves around packaging code into components, i.e.,

binary building blocks. Changes to the component code are contained in the binary unit

hosting it; you don’t need to recompile and redeploy the clients. However, the ability to

replace and plug in new binary versions of the server implies binary compatibility

between the client and the server, meaning that the client’s code must interact at runtime

with exactly what it expects as far as the binary layout in memory of the component entry

points. This binary compatibility is the basis for the contract between the component and

the client.

Language Independence In component-oriented programming, the server is developed independently of the client.

Because the client interacts with the server only at runtime, the only thing that binds the

two is binary compatibility. A corollary is that the programming languages that

implement the client and server should not affect their ability to interact at runtime.

Language independence means exactly that: when you develop and deploy components

your choice of programming language should be irrelevant. Language independence

promotes the interchangeability of components, and their adoption and reuse.

Location Transparency A component-based application contains multiple binary components. These components

can all exist in the same process, in different processes on the same machine, or on

different machines on a network. Recently, with the advent of web services, components

can also be distributed across the Internet. The underlying component technology is

required to provide a client with location transparency, which allows the client code to

be independent of the actual location of the object it uses. Location transparency means

there is nothing in the client’s code pertaining to where the object executes.

The same client code must be able to handle all cases of object location although the

client should be able to insist on a specific location as well. Note that in the figure, the

object can be in the same process (e.g., Process 1 on Machine A), in different processes

on the same machine (e.g., Process 1 and Process 2 on Machine A), on different

machines in the same local network, or even across the Internet (e.g., Machines B and C).

Location transparency is crucial to component-oriented programming for a number of

reasons. First, it lets you develop the client and components locally (which leads to easier

and more productive debugging), yet deploy the same code base in distributed scenarios.

Second, the choice of using the same process for all components, or multiple processes

for multiple machines, has a significant impact on performance and ease of management

versus scalability, availability, robustness, throughput, and security. Organizations have

different priorities and preferences for these tradeoffs, yet the same set of components

from a particular vendor or team should be able to handle all scenarios. Third, the

location of components tends to change as the application’s requirements evolve over

time.

Concurrency Management A component developer can’t possibly know in advance all the possible ways in which a

component will be used and particularly whether it will be accessed concurrently by

multiple threads. The safest course is for you to assume that the component will be used

in concurrent situations and to provide some mechanism inside the component for

synchronizing access. However, this approach has two flaws. First, it may lead to

deadlocks; if every component in the application has its own synchronization lock, a

deadlock can occur if two components on different threads try to access each other.

Second, it’s an inefficient use of system resources for all components in the application to

be accessed by the same thread.

The underlying component technology must provide a concurrency management service-

way for components to participate in some application-wide synchronization mechanism,

even when the components are developed separately. In addition, the underlying

component technology should allow components and clients to provide their own

synchronization solutions for fine-grained control and optimized performance.

Versioning Support Component-oriented programming must allow clients and components to evolve

separately. Component developers should be able to deploy new versions (or just fixes)

of existing components without affecting existing client applications. Client developers

should be able to deploy new versions of the client application and expect it to work with

older versions of components. The underlying component technology should support

versioning, which allows a component to evolve along different paths, and for different

versions of the same component to be deployed on the same machine, or side by side. The

component technology should also detect incompatibility as soon as possible and alert the

client. .

Component-Based Security In component-oriented programming, components are developed separately from the

client applications that use them. Component developers have no way of knowing how a

client application or end user will try to use their work. A benign component could be

used maliciously to corrupt data or transfer funds between accounts without proper

authorization or authentication. Similarly, a client application has no way to know

whether it’s interacting with a malicious component that will abuse the credentials the

client provides. In addition, even if both the client and the component have no ill intent,

the end application user can still try to hack into the system or do some other damage

(even by mistake).

Component Design Tools Rapid Application Development (RAD) refers to a type of software development

methodology that uses minimal planning in favor of rapid prototyping. The "planning" of

software developed using RAD is interleaved with writing the software itself. The lack of

extensive pre-planning generally allows software to be written much faster, and makes it

easier to change requirements.

Components based on Rapid Application Development paradigm

• Add-in Express – Visual RAD tool for developing COM add-ins, smart tags, RTD

servers and Excel user defined functions in Visual Studio .NET and Delphi.

• Panther is a cross-platform (Windows, Unix, Linux; TUI, GUI, Web), cross-

database RAD toolset for development of n-tier component based database

oriented applications. It builds native components employing the same visual

paradigm used for client screens. Editions for middleware from IBM, BEA and

Microsoft exist (and can be combined).

Component Testing Tools Testing software components

When to test a component

One of the first issues in testing software components is whether all that effort is required

in the first place or not. When is it ideal to test a component in a system? If it is seen that

the results of the component not working is greater than the efforts to test it, then plans

should be made to test such a malfunctioning component.

Which components to test

When risk classification of the use cases is mapped onto components, we find that not all

components need to be tested to the same coverage level [10].

• Reusable components - Components intended for reuse should be tested over a

wider range of values.

• Domain components - Components that represent significant domain concepts

should be tested both for correctness and for the faithfulness of the representation.

• Commercial components - Components that will be sold as individual products

should be tested not only as reusable components but also as potential sources of

liability.

The ultimate goal of testing

Testing a software component is basically done to resolve the following issues:

• Check whether the component meets its specification and fulfill its functional

requirements.

• Check whether the correct and complete structural and interaction requirements,

specified before the development of the component, are reflected in the

implemented software system.

Problems in testing software components

The focus now shifts to the most important problem of component software technology

i.e. the problem of coming up with efficiently testing strategies for component integrated

software systems.

Building reusable component tests

Current software development teams use an ad-hoc approach to create component test

suites. Also it is difficult to come up with a uniform and consistent test suite technology

to cater to the different requirements like different information formats, repository

technologies, database schema and test access interfaces of the test tools for testing such

diverse software components. With increasing use of software components, the tests used

for these components should also be reused [25]. Development of systematic tools and

methods are required to set up these reusable test suites and to organize, manage and

store various component test resources like test data and test scripts.

Component Assembly Tools After creating the component logic and writing the business logic, we can use the

component from a simple client program. A big advantage of the CORBA component

model is the ability to connect components together to form larger structures called

component assemblies.

A component assembly is a set of components (with their component descriptors) and a

Component Assembly Descriptor (CAD). Based on the CAD we can generate an

assembly object that instantiates components and connects them together to form a

component assembly.

CCM component assembly tools

Assembly Descriptor Generator

The component descriptor files are the base for the higher-level assembly descriptor,

which describes the components of the assembly and their connections. That means that

all information of the assembly descriptor comes from the component descriptors of the

related components (and some additional data from a GUI).

Assembly Object Generator

At runtime a managing object is needed that can establish an assembly instance. The

assembly object creates the component instances and connects their receptacles and

facets. All information for generating an assembly object comes from the assembly

descriptor (or its DOM model in memory). Note that this object must eventually be able

to create local or local/remote assembly instances.

UML Parser

As with components, there should be a way to define component assemblies in a UML

diagram. Therefore we need a UML parser that reads the UML-XMI file and translates

the data into the DOM model used by the assembly descriptor. The OMG has not yet

defined a mapping between UML and CCM assemblies.

Assembly Packaging Tool

After generating the component assembly and its descriptor file we have to package these

files into a zip file called a component assembly package. The assembly packaging tool

provides these functionalities to the assembly developer.

Assembly Deployment Tool

On the target host the component assembly package must be unzipped, and the assembly

must be deployed in the application server. The assembly deployment tool provides these

functionalities to the assembly deployer.