UNIT-III JAVA REMOTE METHOD INVOCATION

What is a distributed Operating System?

Definition: A distributed system is a collection of independent computer that appears
to its user as a coherent (logical) system.

Distributed Object Technologies:

A distributed system consists of concurrent (parallel) processes accessing

distributed resources.

A distributed system consists of autonomous computers linked by a computer

n/w and equipped with a distributed system s/w.

Resource are shared through message passing in a network environment that may
be unreliable and contain un-trusted components.

Characteristics of Distributed System

Difference between various computers and the ways in which they communicate
are mostly hidden from users.
User and application can interact with a distributed system in a consistent
(reliable) way, regardless where and when interaction takesplace.
It should be relatively easy to expand.
DS will normally be available continuously, if some parts may be temporarily out of
order.

Advantages of Distributed System

Inherently distributed applications

Information sharing among geographically distributed users
Resource sharing: hardware and software
Better price performance ratio
Shorter response time and higher throughput
Higher reliability and availability against component failure
Extensibility and incremental growth
Better flexibility in meeting users needs

ARCHITECTURE OF ENTERPRISE APPLICATION

IMPLEMENTED IN JAVA (Multi tier Architecture )
Every enterprise application comprises of 4 types.
1. Client Tier.
2. Presentation Tier.
3. Business Tier.
4. Data Tier.
Tier: A logical partition of the related components of an application
(System) is known as tier. Or a deletion of an application is called tier.

Here we can develop each tier separately without having any communication between
them.
For example we can develop business tier without having the support of presentation
tier.
Tiers may be in one computer or a tier may separately contain in each
machine.

Client Tier (Layer): End user interacts with the application through the client
interface (Client Tier/Browser soft ware / cell phone).

This tier offers user interface to the end users i.e. any internet based
web application is used by the end user with the help of client-tier. Here browser
is nothing but an application running in the client-tier.

In the client tier HTML and java script are executed. But in the client
machine no code is stored.
Client tier is the mediator between the end user and presentation tier. It
takes the user requests and submits them to the presentation tier. It also receives the
output from the presentation tier and gives to the end user.

Presentation Tier:

Presenting the output to the user (client) in

presentation tier you need to write java programs (JSP, SERVLETS) to execute it
and present the output to the end user.

In Enterprise Application (web enabled enterprise application) this tier presents

the results (required information) to the client-tier. JSPS and SERVLETS are the
technologies used in this tier. These technologies are used to write server side
programs that contact the data tier or business tier to produce / get dynamic data.

Business Tier:

In this tier enterprise applications business

implemented EJB Technology is used here (for complex applications).

Data Tier:

rules

are

It is the data base server process any companys data is stored

mostly in the RDBMS.

Ex:

Oracle
Sybase server
SQL server

Note: SERVLETS, EJBS, JSPS make use of JDBC Technology to interact with the
data tier.
Therefore JDBC is known as the service technology.

Architecture of Enterprise Application

Presentation
Client
Tier

Business

Tier

Tier

Servlets,jsp

EJB

Data Tier

Oracle,sqlservr
,Sybase server

Architectural Styles of Distributed Applications

1. 2_tier Architecture
2. 3_tier Architecture
3. n_tier Architecture

Two_Tier Architecture: - In traditional 2_tier architecture the processing load is

given to the client PC While the server simply acts as a traffic controller between the
application and the data.
client

PL/per L/B L

Server

Data

Here a system (application) is divided in to two tiers.

1. Client Tier: It is responsible for maintaining the business logic
(BL), Persistent Logic, Presentation Logic.
2. Server Tier: It is responsible for maintaining data.

Presentation Logic:

set of operations which are used to set our

requirement. (Code which is used to presenting the view) Presentation Logic is used to
prepare a frame used to take input from the clients present the output.

View: it is responsible to take the requests from the client. and presenting the response
to the clients.

Business Logic:

set of operations to meet functional requirements of a

business system (application).

Persistent Logic: set of operations are used to persist the data. (Using
JDBC we can persist the data).
Example of two tiered application
client

DBserver

AWT

RDBMS

Draw backs:
client tier complexity is high
No proper division of work
Heavy weight application (memory , processing time, and resource requirement
increases) to execute Presentation Logic, Persistent Logic ,Business Logic
Ex: But Mobile System doesnt contain persistence logic and Business Logic at client
side. Makes the client application a heavy weight application. We need additional
resources since the resources required for presentation, business, and persistence logic has
to be accommodated in to the client side. We use AWT, SWINGS concepts to develop an
application we can use it in any O.S (sun salaries, UNIX, Linux, window). Here if
each client is in a separate (different) O.S we need separate JVM for every O.S so it
is costlier.

Type-2 drivers:these drivers translates the JDBC API calls to vender specific
APIS the Data Base will process the requests and send results back through the
API which will in turn forward them back to the JDBC Driver. Nearly we have
300 drivers provided by different venders. This translation from one API to another API
will be held in client side (in JVM) burden will become high.
Increase the cost of the application when we target application to be used with the
different JVM for each O.S)]
The Business Logic cant be reused means B.L cant be reused by different types of
clients.
Note:

Go for Two-Tier Architecture if the systems are fixed.

Root cause:-

Business Logic and Persistent Logic is embedded with presentation

Logic.
To solve the above problems we want to separate B.L and persistence logic from the
presentation logic and as a result of the requirement 3-tier Architecture is designed.

client

Middle server

Presentation
Logic

Business Logic
Persistence
Logic

DB server

RDBMS

Three Tier Architecture Is Divided In To Two Types

Traditional Three Tier Architecture
Web Based Architecture

Traditional Three Tier Architecture:

client

Middle server

AWT

RMI/Socket

DBserver

D.B

Takes the request from remote clients

connects to DB if necessary and process
the request and then sends a flag to the
client

If we take employee Management system as an example input the total

emp details through the client side when we do this the middle ware is (ready)
intelligent to take the request and if required it connects to the D.B get the data
required. And process the request and sends a flag (it may be a Boolean or an int) to
the client side.
Here the client (developer) has to implement the partial business logic to
prepare the presentation content.

Draw Backs:
Complexity is increased compared with 2-tired architecture because in 2-tier
architecture there is no network communication so there is no need for the network
logic in 2- tier architecture.
It is mostly costlier than 2-tier architecture
In traditional architecture partial Business Logic will be implemented in client side.

Separate client s/w we need to install compared with web based Architecture(there the
client is browser no need to install any s/w)
Network Logic: It is a logic which is used to communicate with middle ware
server to understand the client requests.
Web Based Architecture:
To reach out the services to number of clients we need web based
Architecture.
client

Middle server

Browser

Business Logic
Persistence
Logic

DBserver
RDBMS

It contains business logic and presentation logic

(used to prepare the presentation content) ready made

In this case middle ware server takes additional responsibilities compare to traditional
3-tier architecture.
Middle Tier (Middle Ware Server): Middle
Tier
has
the
additional
responsibility to prepare presentation content that can explain generic web client about
what to present and how to present
Yahoo
Sun

Browser

IBM
Rediff

Here one client (browser) is able to communicate with more than one server there is no
need to install separate soft ware for separate servers. It is a generic client it can
communicate with any other app server.
In general Two possible out comes can occur from server to clients
Correct
Wrong (Exception)
But it is not in all the cases
What we can do
if the number of outcomes increases
if the same application(server) has to connect to the different
databases
if different type of requests are sent to communicate with
different Data Base servers
The middle ware must be intelligent to handle above three problems
We can do it by separating persistent logic, Business Logic, Presentation
Logic etc in server (middle ware server).

N-Tier Architecture:
Here in N-tier architecture the middle ware server is divided into multiple
divisions (tiers).
In this case as the number of types of clients and the back-end data store
types increases complexity of middle ware application also increases.
And to simplify this we are recommended to divide this middle ware into
multiple tiers which provides the following benefits
Reusability:
reusability of Persistent Logic, Presentation Logic, Business Logic
and the cost of development will be reduced. Proper Responsibility division that can
improve the productivity of the application.

Future extension to the system can be easily added.

client

Middle server

Data base

Http

Browser

Per Logic

Mobile
Awt/vb

B.L

Pre Logic

In the given above example we divide our middle tier into 3 divisions
(components)
Http

to receive http request

Presentation Logic to present the content to the web clients Business Logic to
implement the business Logic Persistent Logic to persist the data
When we develop a system following n-tier architecture model then first of all we need
to decide how many number of tiers our system should be divided into and what should
be the responsibility of each of these tiers.

Distributed object technology:

Objects are classified in two main classes based on when they are bound and how long
they exist.
Based on the time of binding, objects are classified as runtime and compile time.
Runtime objects:

Distributed applications are built easily using compile time objects.

These types of objects are dependent on the programming language. To avoid this
dependency, they are bound at runtime.
So application reconstructed from objects written in multiple languages.

Compile time objects:

The object adapter acts as a wrapper around the implementation detail to give in the
appearance of an object.
An interface is defined to implement the object which can be later registered. The
objects are now available for remote invocations.

Persistent objects:

These objects exist even if they are not contained in the server process address space.
It implies that the client manages the persistent object and can store its state on any
secondary storage and exit.

Transient objects:

They exist only for the time when the server manages the object. When the server
ceases to exist, the object gets vanished.

White a short Note on Stub and Skeleton :

RMI uses stub and skeleton object for communication with the remote object.
A remote object is an object whose method can be invoked from another JVM. Let's understand
the stub and skeleton objects:

stub
The stub is an object, acts as a gateway for the client side. All the outgoing requests are routed
through it. It resides at the client side and represents the remote object. When the caller invokes
method on the stub object, it does the following tasks:

It initiates a connection with remote Virtual Machine (JVM),

It writes and transmits (marshals) the parameters to the remote Virtual Machine (JVM),

It waits for the result

It reads (unmarshals) the return value or exception, and

It finally, returns the value to the caller.

skeleton
The skeleton is an object, acts as a gateway for the server side object. All the incoming requests
are routed through it. When the skeleton receives the incoming request, it does the following
tasks:

It reads the parameter for the remote method

It invokes the method on the actual remote object, and

It writes and transmits (marshals) the result to the caller.

In the Java 2 SDK, an stub protocol was introduced that eliminates the need for skeletons.

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.
4. CORBA is a standard defined by the OMG (Object Management Group). It
describes an architecture, interfaces, and protocols that distributed objects can use
to interact with each other.
Part of the CORBA standard is the Interface Definition Language
(IDL), which is an implementation-independent language for
describing the interfaces of remote objects.
5. Unlike RMI, objects that are exported using CORBA can be accessed by
clients implemented in any language with an IDL binding (C, C++, Ada etc.).
6. The CORBA standard is extensive and provides a rich set of services.

The Common Object Request Broker Architecture (CORBA) is a standard developed by

the Object Management Group (OMG) to provide interoperability among distributed objects.
CORBA is the world's leading middleware solution enabling the exchange of information,
independent of hardware platforms, programming languages, and operating systems. CORBA is
essentially a design specification for an Object Request Broker (ORB), where an ORB provides
the mechanism required for distributed objects to communicate with one another, whether locally
or on remote devices, written in different languages, or at different locations on a network.
The CORBA Interface Definition Language, or IDL, allows the development of language
and location-independent interfaces to distributed objects. Using CORBA, application
components can communicate with one another no matter where they are located, or who has
designed them. CORBA provides the location transparency to be able to execute these
applications.
Data communication from client to server is accomplished through a well-defined objectoriented interface. The Object Request Broker (ORB) determines the location of the target
object, sends a request to that object, and returns any response back to the caller. Through this
object-oriented technology, developers can take advantage of features such as inheritance,
encapsulation, polymorphism, and runtime dynamic binding. These features allow applications to
be changed, modified and re-used with minimal changes to the parent interface. The illustration
below identifies how a client sends a request to a server through the ORB:

The major components that make up the CORBA architecture include the:
4. Interface Definition Language (IDL), which is how CORBA interfaces are
defined.
5. Object Request Broker (ORB), which is responsible for all interactions
between remote objects and the applications that use them,
6. The Portable Object Adaptor (POA), which is responsible for object
Activation / deactivation, mapping object ids to actual object
implementations.
7. Naming Service, a standard service in CORBA that lets remote clients
find remote objects on the networks, and
8. Internet Inter-ORB Protocol (IIOP).
This figure shows how a one-method distributed object is shared between a
CORBA client and server to implement the classic "Hello World"
application.

A one-method distributed object shared between a CORBA client and server.

RMI for Distributed Computing:

Java's Remote Method Invocation (RMI): Package is a set of classes and

interfaces that enables one java object to call the public methods of another java
object running on a different virtual machine.
As a distributed computing architecture, the RMI allows objects to
communicate through a pre-defined interface that allows them to function as if the
objects are local to them, so they can invoke their methods directly.

The Basics of RMI:

Definition: The RMI (Remote Method Invocation) is an API that provides a mechanism to
create distributed application in java. The RMI allows an object to invoke methods on an object
running in another JVM.

The RMI architecture allows an applet or application to call methods contained within
an object running on a remote host.

The RMI registry is an application that works as the 'gateway' between the remote
object and the RMI client.

A security manager must be present within the architecture to govern the access
attempts made by the client to the remote object. RMI applications use the RMI
Security Manager class as their security manager, and applets use their own built-in
security manager.

Stub and skeleton object perform the exchange of information between the client and
remote object using TCP sockets and object serialization.

Objects which are passed between the client and the remote objects must implement
the Serializable interface.

The Remote interface is used to define the structure of the remote object.

The Unicast Remote Object class is used to create the remote object as an RMI server
process. This remote object binds itself to the RMI registry through the Naming class
in order to be seen and accessed by RMI clients.

Several Exception classes may be thrown by the RMI process. These exception should
be caught by the client and remote objects in order to control the activity of the
program if an error is generated.

RMI clients access the remote object by obtaining a reference to it through the RMI
registry using Naming class. This reference is preformed through the remote object's
stub.

Multi-user support can be enabled through the used of threads. Since threads are not
serializable, they must be implemented and managed within the remote object and not
the RMI client.

Session management is effective in controlling database connectivity for multi-user

support. There are several ways in which database sessions can be managed.

Garbage collection is managed automatically by the RMI runtime environment.

RMI Architecture:

A client process and a remote (server) object are logically linked to each other through a
registry.

As the start of the process, a Java application (the remote object) executes as a server
process on Virtual Machine A and identifies itself with the RMI registry.

The registry is another Java application whose role is to maintain active reference to
remote objects. These references are stored within an internal table contained within the
registry program.

A java Client running on Virtual Machine B needs to request the service from the
registry to invoke the method contained within the remote object. It does this by access
the RMI registry on the host where the remote object resides (Virtual Machine A) through
a TCP socket connection. Once the registry accepts the clients request, it deliveries a
reference to the remote object in the form of a stub back to the client.

The client now invokes a method within the remote object's stub. This invocation may
also involve the exchange of additional objects as parameters, and the receipt of the
return values from the method call. These communications occur through the network
streams made available by the TCP socket, using object serialization.

The parameters are forwarded to the remote object through a skeleton object. The
skeleton object then dispatch them to the remote object and invoke the remote method.
The return value is sent back through the skeleton and the stub and finally received by the
client.

A security manager governs the access as the stub and the skeleton communicates with
each other.

RMI Registry Service:

Definition: The registration of the remote objects must be done by the server in order for the
client to look it up, is called the RMI Registry
In RMI, the client must contact an RMI registry, so that the server side application will be
able to contact the clients registry which points the client in the direction of the service. The
client registers the service with the registry so that it is transparent to even for the server.

Creating RMI Applications:

Creating a simple RMI application involves the following steps:

Define a remote interface.

Implementing remote interface.

Create and start remote application

Create and start client application

1. Define a remote interface.

A remote interface specifies the methods that can be invoked remotely by a client. Clients
program communicate to remote interfaces, not to classes implementing it. To be a remote
interface, a interface must extend the Remote interface of java.rmi package.
import java.rmi.*;
public interface AddServerInterface extends Remote
{
public int sum(int a,int b);
}

2. Implementing remote interface.

For implementation of remote interface, a class must either extend UnicastRemoteObject or use
export Object() method of UnicastRemoteObject class.

import java.rmi.*;
import java.rmi.server.*;
public class Adder extends UnicastRemoteObject implements AddServerInterface
{
Adder()throws RemoteException{

super();
}
public int sum(int a,int b)
{
return a+b;
}
}

3. Create and start remote application.

You need to create a server application and host rmi service Adder in it. This is done using
rebind() method of java.rmi.Naming class. rebind() method take two arguments, first represent
the name of the object reference and second argument is reference to instance of Adder.
import java.rmi.*;
import java.rmi.registry.*;
public class AddServer{
public static void main(String args[]){
try{
AddServerInterface addService=new Adder();
Naming.rebind("AddService",addService);
//addService object is hosted with name AddService.

}catch(Exception e){System.out.println(e);}
}
}

4. Create and start client application

Client application contains a java program that invokes the lookup() method of
the Naming class. This method accepts one argument, the rmi URL and returns a reference to an
object of type AddServerInterface. All remote method invocation is done on this object.
import java.rmi.*;
public class Client{
public static void main(String args[]){

try{
AddServerInterface
st=(AddServerInterface)Naming.lookup("rmi://"+args[0]+"/AddService");
System.out.println(st.sum(25,8));
}catch(Exception e){System.out.println(e);}
}
}

Steps involved in running the RMI application in case the server application
and the client application is running in the same machine:

Removing Objects from a registry:

A registry allows you to remove from it any objects that you have submitted to it. You use the
object's ID as an argument to the Life Cycle Manager.deleteObjects method.
The following code fragment deletes the object that corresponds to a specified key string and
then displays the key again so that the user can confirm that it has deleted the correct one.
String id = key.getId();
Collection keys = new ArrayList();
keys.add(key);
BulkResponse response = blcm.deleteObjects(keys);
Collection exceptions = response.getException();
if (exceptions == null) {
System.out.println("Objects deleted");
Collection retKeys = response.getCollection();
Iterator keyIter = retKeys.iterator();
javax.xml.registry.infomodel.Key orgKey = null;
if (keyIter.hasNext()) {
orgKey =

(javax.xml.registry.infomodel.Key) keyIter.next();
id = orgKey.getId();
System.out.println("Object key was " + id);
}
}
Deleting an Organization does not delete the Service and User objects
the Organization. You must delete them separately.

that

belong to

Deleting a Service object deletes the Service Binding objects that belong to it, and also
the Specification Link objects that belong to the Service Binding objects. Deleting
the Specification Link objects, however, does not delete the associated Extrinsic Object instances
and their associated repository items. You must delete the extrinsic objects separately.
AuditableEvent and Association objects are not always deleted when the objects associated with
them are deleted. You may find that as you use the Registry, a large number of these objects
accumulates.

Removing Objects from the Registry: Example

For an example of deleting an object from the Registry, see <INSTALL>/registry/samples/ deleteobject/src/JAXRDelete.java. This example deletes the object whose unique identifier you
specify. To run the example, follow these steps:

Go to the directory <INSTALL>/registry/samples/delete-object.

Type the following command:

ant run -Did=id_string

Remote Method Invocation (RMI):

Remote Method Invocation (RMI) allows a Java object that executes on one machine to
invoke a method of a Java object that executes on another machine.

This is an important feature, because it allows you to build distributed

applications.

A Simple Client/Server Application Using RMI

This section provides step-by-step directions for building a simple client/server
application by using RMI.
The server receives a request from a client, processes it, and returns a result.
Step One: Enter and Compile the Source Code.
This application uses four source files.

The first file, AddServerIntf.java, defines the remote interface that is

provided by the server.

All remote interfaces must extend the Remote interface, which

is part of java.rmi. Remote defines no members.

Its purpose is simply to indicate that an interface uses remote methods.

All remote methods can throw a RemoteException.

The second source file, AddServerImpl.java, implements the remote interface.

Theimplementation of the add( ) method is straightforward.

All remote objects must extend UnicastRemoteObject, which provides functionality that is needed
to make objects available from remote machines.

It contains one method that accepts two double arguments and returns their sum.

The third source file, AddServer.java, contains the main program for the server
machine.
Its primary function is to update the RMI registry on that machine.
This is done by using the rebind( ) method of the Naming class (found in java.rmi).
That method associates a name with an object reference.
The first argument to the rebind( ) method is a string that names the server as AddServer.
Its second argument is a reference to an instance of AddServerImpl.

The fourth source file, AddClient.java, implements the client side of this
distributed application.

AddClient.java requires three command-line arguments.

The first is the IP address or name of the server machine.
The second and third arguments are the two numbers that are to be summed.

Step Two: Generate a Stub

In the context of RMI, a stub is a Java object that resides on the client machine.
Its function is to present the same interfaces as the remote server.
Remote method calls initiated by the client are actually directed to the stub.

The stub works with the other parts of the RMI system to formulate a request that is sent to the
remote machine.
A remote method may accept arguments that are simple types or objects. In the latter case, the object
may have references to other objects.

All of this information must be sent to the remote machine. That is, an object passed as an
argument to a remote method call must be serialized and sent to the remote machine.
If a response must be returned to the client, the process works in reverse. Note that the
serialization and deserialization facilities are also used if objects are returned to a client.
To generate a stub, you use a tool called the RMI compiler, which is invoked from the
command line, as shown here:

rmic AddServerImpl

This command generates the file AddServerImpl_Stub.class. When using rmic, be sure that
CLASSPATH is set to include the current directory.

Step Three: Install Files on the Client and Server Machines.

Copy AddClient.class, AddServerImpl_Stub.class, and AddServerIntf.class to a directory on the

client machine.

Copy
AddServerIntf.class,
AddServerImpl_Stub.class, and
AddServer.class to a directory on the server machine.

AddServerImpl.class,

Step Four: Start the RMI Registry on the Server Machine.

Java SE 6 provides a program called rmiregistry, which executes on the server

machine.

It maps names to object references. First, check that the CLASSPATH environment variable
includes the directory in which your files are located.

Then, start the RMI Registry from the command line, as shown here:
start rmiregistry

When this command returns, you should see that a new window has been created. You
need to leave this window open until you are done experimenting with the RMI
example
.Step Five: Start the Server.

The server code is started from the command

line, as shown here: java AddServer

Recall that the AddServer code instantiates AddServerImpl and registers that object with the name
AddServer.

Step Six: Start the Client.

The AddClient software requires three arguments: the name or IP address of

the server machine and the two numbers that are to be summed together.

You may invoke it from the command line by using one of the two formats

shown here:
Java AddClient server1 8 9
java AddClient 11.12.13.14 8 9
In the first line, the name of the server is provided. The second line uses its IP
address (11.12.13.14).

// addserverintf.java
import java.rmi.*;
public interface addserverintf extends Remote
{
double add(double d1,double d2) throws RemoteException;
}
// addserverimpl.java
import java.rmi.*;
import java.rmi.server.*;
public class addserverimpl extends UnicastRemoteObject implements addserverintf
{
public addserverimpl() throws RemoteException{ }
public double add(double d1,double d2) throws RemoteException
{
return d1+d2;
}
}
// addserver.java
import java.net.*; import
java.rmi.*; public class
addserver
{ public static void main(String args[])
{ try
{
addserverimpl addsi=new addserverimpl();
Naming.rebind("addserver", addsi);}
catch(Exception e)
{
System.out.println("exception" + e);
}
}

}
//addclient.java
import java.rmi.*;
public class addclient
{
public static void main(String args[])
{ try
{
String addServerURL="rmi://" +args[0]+ "/addserver";
addserverintf addsintf = (addserverintf)Naming.lookup(addServerURL);
System.out.println("the first no is" + args[1]);
double d1=Double.valueOf(args[1]).doubleValue();
System.out.println("the second no is"+args[2]); double
d2=Double.valueOf(args[2]).doubleValue();
System.out.println("the sum is: "+addsintf.add(d1,d2));
}
catch(Exception e)
{
System.out.println("Exception "+e);
}
}
}
Execution procedure
if there is no change in the class path this is the procedure
Place all the files in one directory
TERMINAL 0
command 0:
Satish@CentOS$ javac *.javac command 1:
Satish@CentOS /$ rmic addserverimpl command 2:
Satish@CentOS $ rmiregistry&
command 3:
Satish@CentOS /$ java addserver
Satish@CentOS /$ java addclient 127.0.0.1 8 9
output
the first no is 6
the second no is9 the
sum is: 15.0
Distributed computing is a field of computer science that studies distributed systems. A
distributed system consists of multiple autonomous computers that communicate through a
computer network. The computers interact with each other in order to achieve a common goal. A

computer program that runs in a distributed system is called a distributed program, and
distributed programming is the process of writing such programs.
Distributed computing also refers to the use of distributed systems to solve computational
problems. In distributed computing, a problem is divided into many tasks, each of which is
solved by one or more computers.[
J2EE
Java EE is defined by its specification. As with other Java Community Process
specifications, providers must meet certain conformance requirements in order to declare their
products as Java EE compliant.
Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web services,
XML, etc., and defines how to coordinate them. Java EE also features some specifications
unique to Java EE for components. These include Enterprise JavaBeans, Connectors, servlets,
portlets (following the Java Portlet specification), JavaServer Pages and several web service
technologies. This allows developers to create enterprise applications that are portable and
scalable, and that integrate with legacy technologies. A Java EE application server can handle
transactions, security, scalability, concurrency and management of the components that are
deployed to it, in order to enable developers to concentrate more on the business logic of the
components rather than on infrastructure and integration tasks.
CORBA:

CORBA products provide a framework for the development and execution of

distributed applications. But why would one want to develop a distributed
application in the first place? As you will see later, distribution introduces a
whole new set of difficult issues. However, sometimes there is no choice;
some applications by their very nature are distributed across multiple
computers because of one or more of the following reasons:
The data used by the application are distributed
The computation is distributed
The users of the application are distributed
Data are Distributed
Some applications must execute on multiple computers because the data
that the application must access exist on multiple computers for

administrative and ownership reasons. The owner may permit the data to be
accessed remotely but not stored locally. Or perhaps the data cannot be colocated and must exist on multiple heterogeneous systems for historical
reasons.
Computation is Distributed
Some applications execute on multiple computers in order to take advantage
of multiple processors computing in parallel to solve some problem. Other
applications may execute on multiple computers in order to take advantage
of some unique feature of a particular system. Distributed applications can
take advantage of the scalability and heterogeneity of the distributed
system.

DCOM:Distributed object computing extends an object-oriented programming

system by allowing objects to be distributed across a heterogeneous network, so
that each of these distributed object components interoperate as a unified whole.
These objects may be distributed on different computers throughout a network,
living within their own address space outside of an application, and yet appear as
though they were local to an application.
Three of the most popular distributed object paradigms are Microsoft's Distributed
Component Object Model (DCOM), OMG's Common Object Request Broker Architecture
(CORBA) and JavaSoft's Java/Remote Method Invocation (Java/RMI). In this article, let us
examine the differences between these three models from a programmer's standpoint and an
architectural standpoint. At the end of this article, you will be able to better appreciate the merits
and innards of each of the distributed object paradigms.
CORBA relies on a protocol called the Internet Inter-ORB Protocol (IIOP) for
remoting objects. Everything in the CORBA architecture depends on an Object Request Broker
(ORB). The ORB acts as a central Object Bus over which each CORBA object interacts
transparently with other CORBA objects located either locally or remotely. Each CORBA server
object has an interface and exposes a set of methods. To request a service, a CORBA client
acquires an object reference to a CORBA server object. The client can now make method calls
on the object reference as if the CORBA server object resided in the client's address space. The
ORB is responsible for finding a CORBA object's implementation, preparing it to receive
requests, communicate requests to it and carry the reply back to the client. A CORBA object
interacts with the ORB either through the ORB interface or through an Object Adapter - either a
Basic Object Adapter (BOA) or a Portable Object Adapter (POA). Since CORBA is just a
specification, it can be used on diverse operating system platforms from mainframes to UNIX
boxes to Windows machines to handheld devices as long as there is an ORB implementation for

that platform. Major ORB vendors like Inprise have CORBA ORB implementations through
their VisiBroker product for Windows, UNIX and mainframe platforms and Iona through their
Orbix product.
DCOM which is often called 'COM on the wire', supports remoting objects by running on
a protocol called the Object Remote Procedure Call (ORPC). This ORPC layer is built on top
of DCE's RPC and interacts with COM's run-time services. A DCOM server is a body of code
that is capable of serving up objects of a particular type at runtime. Each DCOM server object
can support multiple interfaces each representing a different behavior of the object. A DCOM
client calls into the exposed methods of a DCOM server by acquiring a pointer to one of the
server object's interfaces. The client object then starts calling the server object's exposed methods
through the acquired interface pointer as if the server object resided in the client's address space.
As specified by COM, a server object's memory layout conforms to the C++ vtable layout. Since
the COM specification is at the binary level it allows DCOM server components to be written in
diverse programming languages like C++, Java, Object Pascal (Delphi), Visual Basic and even
COBOL. As long as a platform supports COM services, DCOM can be used on that platform.
DCOM is now heavily used on the Windows platform. Companies like Software AG provide
COM service implementations through their EntireX product for UNIX, Linux and mainframe
platforms; Digital for the Open VMS platform and Microsoft for Windows and Solaris
platforms.
Java/RMI relies on a protocol called the Java Remote Method Protocol (JRMP). Java
relies heavily on Java Object Serialization, which allows objects to be marshaled (or transmitted)
as a stream. Since Java Object Serialization is specific to Java, both the Java/RMI server object
and the client object have to be written in Java. Each Java/RMI Server object defines an interface
which can be used to access the server object outside of the current Java Virtual Machine(JVM)
and on another machine's JVM. The interface exposes a set of methods which are indicative of
the services offered by the server object. For a client to locate a server object for the first time,
RMI depends on a naming mechanism called an RMIRegistry that runs on the Server machine
and holds information about available Server Objects. A Java/RMI client acquires an object
reference to a Java/RMI server object by doing a lookup for a Server Object reference and
invokes methods on the Server Object as if the Java/RMI server object resided in the client's
address space. Java/RMI server objects are named using URLs and for a client to acquire a
server object reference, it should specify the URL of the server object as you would with the
URL to a HTML page. Since Java/RMI relies on Java, it can be used on diverse operating system
platforms from mainframes to UNIX boxes to Windows machines to handheld devices as long as
there is a Java Virtual Machine (JVM) implementation for that platform. In addition to Javasoft
and Microsoft, a lot of other companies have announced Java Virtual Machine ports.