Distributed Objects
Introduction
■
A distributed object-based system is a collection of objects that isolates the
requesters of services (clients) from the providers of services (servers) by a
well-defined encapsulating interface.
■
In other words, clients are isolated from
the implementation of services as data
representations and executable code.
■
This is one of the main differences that distinguishes the distributed object-based model from the pure
client/server model.
■
In the distributed object-based model, a client sends a message to an object, which in turns interprets the message to decide what service to perform.
■
This service, or method, selection could be performed by either the object or a broker. The Java Remote
Method Invocation (RMI) and the Common Object
Request Broker Architecture (CORBA) are examples
of this model.
The Roles of Client & Server
Client Server
Send request data
Return response data
Transmitting objects between client and server
■
The client/server model is a form of
distributed computing in which one program (the client) communicates with another
program (the server) for the purpose of exchanging information.
■
In this model, both the client and server
usually speak the same language -- a protocol
that both the client and server understand --
so they are able to communicate.
■
While the client/server model can be
implemented in various ways, it is typically done using low-level sockets.
■
Using sockets to develop client/server systems means that we must design a
protocol, which is a set of commands agreed
upon by the client and server through which
they will be able to communicate.
■
As an example, consider the HTTP
protocol that provides a method called GET, which must be implemented by all web servers and used by web clients
(browsers) in order to retrieve
documents.
The Distributed Objects Paradigm
Remote Method Call with Proxies
■
A distributed object is provided, or exported, by a
process, here called the object server. A facility, here called an object registry, must be present in the
system architecture for the distributed object to be registered.
■
To access a distributed object, a process –an object client–looks up the object registry for a reference to the object. This reference is used by the object client to make calls to the methods.
■
A reference is a “handle”for an object; it is a
representation through which an object can be
located in the computer where the object resides.
■
Logically, the object client makes a call directly to a remote method.
■
In reality, the call is handled by a software
component, called a client proxy, which interacts with the software on the client host that provides the
runtime support for the distributed object system.
■
The runtime support is responsible for the
inter-process-communication needed to transmit the
call to the remote host, including the marshalling of
the argument data that needs to be transmitted to
the remote object.
■
A similar architecture is required on the server side, where the runtime support for the distributed object system handles the receiving of messages and the unmarshalling of data, and forwards the call to a software component called the server proxy.
■
The server proxy interfaces with the distributed object to invoke the method call locally, passing in the unmarshalled data for the arguments.
■
The method call results in the performance of some tasks on the server host. The outcome of the execution of the method,
including the marshalled data for the return value, is forwarded
by the server proxy to the client proxy, via the runtime support
and network support on both sides.
■
The distributed object paradigm has been widely adopted in distributed applications, for which a large number of mechanisms based on the paradigm are available. Among the most well known of such mechanisms are:
■
Java Remote Method Invocation(RMI),
■
the Common Object Request Broker Architecture(CORBA) systems,
■
the Distributed Component Object Model(DCOM),
■
mechanisms that support the Simple Object Access Protocol(SOAP).
■
Of these, the most straightforward is the Java RMI
RMI
■
RMI is a distributed object system that enables you to easily develop distributed Java applications.
■
Developing distributed applications in RMI is simpler than developing with sockets since there is no need to design a protocol, which is an error-prone task.
■
In RMI, the developer has the illusion of calling a local method from a local class file, when in fact the arguments are shipped to the remote target and
interpreted, and the results are sent back to the
callers.
■
Remote Method Invocation (RMI) is an object-oriented
implementation of the Remote Procedure Call model. It is an API for Java programs only.
■
Using RMI, an object server exports a remote object and
registers it with a directory service. The object provides remote methods, which can be invoked in client programs.
■
Syntactically:
■ A remote object is declared with a remote interface, an extension of the Java interface.
■ The remote interface is implemented by the object server.
■ An object client accesses the object by invoking the remote methods associated with the objects using syntax provided for remote method invocations.
Stubs and Parameter Marshalling
■
When client wants to invoke a remote method on a remote object, it actually calls an
ordinary method on proxy object called a stub.
■
Stub resides on the client machine.
■
Stub packages the parameters used in the remote method into a block of bytes.
■
This packaging uses the device independent
encoding for each parameter.
■
The process of encoding the parameters is called parameter marshalling.
■
The purpose of parameter marshalling is to convert the parameters into a
format suitable for transport from one
virtual machine to another.
■
The stub method on the client machine builds an information block that consists of:
■
An identifier of the remote object to be used
■
A descriptor of the method to be called
■
The marshalled parameter
■
The stub then send this information to
the server.
■
Server side, a receiver object performs the following actions for every remote method call:
■
It unmarshals the parameters
■
It locates the object to be called
■
It calls the desired method
■
It capture and marshals the return value or exception of the call
■
It sends a package consisting of the marshalled
return back to the stub on the client.
■
The client stub un-marshals the return value or exception from the server.
■
This value becomes the return of the stub call.
■
Or, if the remote method threw an
exception, the stub rethrows it in the
process space of the caller.
Client Stub Skeleton Server
Call stub method locally
Send marshalled parameters Call Server method locally
Return method result Send marshalled return value
or exception Return value or
throw exception
Parameter marshalling
■
The syntax for remote method call is the same as of local call.
■
Interfaces are abstract entities that only spell out what method can be called along with their
signatures.
■
Variables whose type is an interface must always be bound to an actual object of some type.
■
When remote methods are called, the object variable refers to a stub object.
■
The client program does not actually know the type of those objects.
■
The stub classes and the associated objects are
created automatically.
Dynamic Class Loading
■
When you pass a remote object to
another program, either as a parameter or return value of a remote method,
then program must have the class file for that object.
■
As you know basic work of class loader
is to load the necessary class files from
the server
■
Whenever a program loads new code from another network location, there is a security issue.
■
For this reason we need to use a security manager in RMI client applications.
■
This is a safety mechanism that protects the
program from viruses in stub code.
Setup for RMI
■
You must run programs on both the server and client computers.
■
The necessary object information may
be separated into client side interfaces
and server side implementations.
Interfaces & Implementations
■
Client program needs to manipulate server objects, but it doesn’t actually have copies of them.
■
The objects themselves reside on the server.
■
The client code must still know what it
can do with those objects.
■
Their capabilities are expressed in an interface that is shared between the
client and server and so resides on both
machines.
RMI Architecture
CORBA
■
The Common Object Request Broker Architecture (or CORBA) is an industry
standard developed by the Object Management Group (OMG) to aid in distributed objects
programming.
■
It is important to note that CORBA is simply a specification. A CORBA implementation is
known as an ORB (or Object Request Broker).
■
There are several CORBA implementations available on the market such as VisiBroker, ORBIX, and others. JavaIDL is another
implementation that comes as a core package
with the JDK1.3 or above.
■
CORBA was designed to be platform and language independent.
■
Therefore, CORBA objects can run on any
platform, located anywhere on the network, and can be written in any language that has
Interface Definition Language (IDL) mappings.
■
Similar to RMI, CORBA objects are specified with interfaces.
■
Interfaces in CORBA, however, are specified in IDL.
■
While IDL is similar to C++, it is important to
note that IDL is not a programming language.
The Genesis of a CORBA Application
■
There are a number of steps involved in developing CORBA applications. These are:
■
Define an interface in IDL
■
Map the IDL interface to Java (done automatically)
■
Implement the interface
■
Develop the server
■
Develop a client
■
Run the naming service, the server, and the
client.
■
Code-wise, it is clear that RMI is simpler to work with since the Java
developer does not need to be familiar with the Interface Definition Language (IDL). In general, however, CORBA
differs from RMI in the following areas:
■
CORBA interfaces are defined in IDL and RMI interfaces are defined in Java. RMI allows you to write all interfaces in
Java.
■
CORBA supports in and out
parameters, while RMI does not since local objects are passed by copy and remote objects are
passed by reference.
■
CORBA was designed with language
independence in mind. This means that some of the objects can be written in
Java, for example, and other objects can be written in C++ and yet they all can
interoperate. Therefore, CORBA is an ideal mechanism for bridging islands between different programming
languages. On the other hand, RMI was
designed for a single language where all
objects are written in Java.
■
CORBA objects are not garbage collected. As we mentioned, CORBA is language
independent and some languages (C++ for
example) does not support garbage collection.
This can be considered a disadvantage since once a CORBA object is created, it continues to exist until you get rid of it, and deciding when to get rid of an object is not a trivial task. On the other hand, RMI objects are garbage
collected automatically.
■
CORBA depends on having an Object Request Broker available on both client and server.
■
ORB is a kind of universal translator for
inter object CORBA communication.
IDL: Interface Definition Language
■
In this interface definition ends with semicolon.
■
string class is started with small s. this string class refer to the CORBA notion of string.
■
In java String contains 16 bit unicode
characters but in CORBA string contains
only 8 bit characters.
■
IDL to java compiler translates IDL definitions to definitions for java
interfaces.
IDL interface
interface IDLTest {
string string_test();
};
After executing idlj IDLTest.idl
It will produce IDLTestOperations.java interface IDLTest
{
String string_test();
}
■ SOAP
Short for Simple Object Access Protocol, a lightweight
XML-based messaging protocol used to encode the information in Web service request and response messages before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including SMTP, MIME, and HTTP.
■ WSDL
