UNIT 4 DISTRIBUTED OBJECTS 1) Distributed Object Model

Remote Object - an object whose methods can be invoked from another Virtual Machine. Remote Interface - a Java interface that declares the methods of a remote object. Remote Method Invocation (RMI) - the action of invoking a method of a remote interface on a remote object.

2) How Client Server Communicates in Distributed Systems OR Roles of Client & Server in Distributed Systems In the traditional client/server model, the client translates the request to an intermediary

transmission format & sends the request data to the server.The server parses the request format,computes the response & formats the response for transmission to the client.The client then parses the response & displays it to the user.Now you have to design a transmission format & you have to write code for conversion between your data & the transmission format.Now what we want is a mechanism by which the client programmer makes a regular method call,the problem is that the object that carries out the work is not located in the same virtual machine.The solution is to install a proxy for the server object on the client.The client calls the proxy,making a regular method call.The client proxy contacts the server. similarly the programmer of the server object doesn’t want to fuss with the client communication.The solution is to install a second proxy object on the server.The server proxy communicates with the client proxy & it makes regular method calls to the server objects.

How do proxies communicate with each other ? a) RMI (Remote Method Invocation) – It supports method calls b/w distributed java objects. b) CORBA (Common Object Request Broker Architecture) – It supports method calls b/w objects of any programming language.It uses the Internet Inter-ORB protocol, or IIOP, to communicate between objects. c) SOAP (Simple Object Access Protocol) – It is programming language neutral.It supports method calls through web services. ( draw diagram of this on page no.279 of ur book) 3) Remote Method Invocation (RMI)

If you have an access to an object on a different machine, you can call methods of the remote object.of course, the method parameters must somehow be shipped to the other machine,the server must be informed to execute the method & the return value must be shipped back. In RMI, the object whose methods makes the remote call is called the client object. The remote object is called the server object.The computer running the java code that calls the remote method is the client for that call. The computer hosting the object that processes the call is the server for that call. Registration (binding) A server can register its remote objects with a naming service – the rmiregistry.Once registered, each remote object has a unique URL.

Obtaining a remote object reference.

A client can use the naming service to lookup a URL to obtain a remote object reference. The application can pass and return remote object references

as part of its operation. (draw diagram of this on page no.281 of ur book) Stubs & Parameter Marshalling :

when client code invokes a remote method on a remote object, it actually calls an ordinary method on a proxy object called a stub.The stub resides on the client machine.The stub packages the parameters used in the remote method into a block of bytes. This packaging uses a 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 m/c to another.

Stub functions include: a) Initiating a call to the remote object. b) A description of the method to be called. c) The marshalled parameters. d) Unmarshals the return value or exception from the server. e) Return value to the caller. Skeleton A proxy object on server side is called Skeleton. Skeleton function includes: a) It unmarshals the parameters. b) It locates the object to be called. c) It calls the desired method.

d) It captures & marshals the return value or exception of the call. e) Returns marshalled data back to the stub.

( draw diagram of this on page no.282) This process is complex, but it is completely automatic & to a large extent transparent to the programmer. Dynamic Class Loading When u pass a remote object to another program, either as

a parameter or return value of a remote method, then that program must have the class file for that object.

For ex: consider a method with return type Product.The client program needs the class file product.class to compile,but now suppose server constructs & return Book object & Book is a subtype of Product.Client have no idea where to find the class file Book.class. Therefore a class loader that will load required classes from the server is required.RMI uses a special RMIClassLoader that loads at runtime the classes required for remote invocations.whenever a program loads new code from another network location,there is a security issue.For that reason,you need to use a security manager in RMI client applications.This is a safety mechanism that protects the program from viruses in stub code.For specialized applications,programmers can substitute their own class loaders & security managers.

RMI Architecture

Client Virtual Machine

Client

Server Virtual Machine

Stub

Remote

Object

Skeleton

Registry Virtual Machine

RmiRegistry

Server

RMI Flow

Client Virtual Machine

Client

Server Virtual Machine

Stub

Remote

Object

Skeleton

Registry Virtual Machine

RmiRegistry

Server

1

2

1. Server Creates Remote Object 2. Server Registers Remote Object

RMI Flow

Client Virtual Machine

Client

Server Virtual Machine

Stub

Remote

Object

Skeleton

Registry Virtual Machine

RmiRegistry

Server

4

3. Client requests object from Registry 4. Registry returns remote reference (and stub gets created)

3

4) Setup for Remote Method Invocation (RMI) 1) Defining a remote interface. 2) Implementing the remote interface. 3) Write the server program to create server objects. 4) Write the client program that uses the remote object. 5) Generating stubs & skeletons. 6) Starting the registry & registering the objects 7) Running the server & client.

1. Define the Remote Interface – Your client program needs to manipulate server objects,but it doesnot actually have copies of all of them.

RMI Flow

Client Virtual Machine

Client

Server Virtual Machine

Stub

Remote

Object

Skeleton

Registry Virtual Machine

“Fred”

Server

6

5. Client invokes stub method 6. Stub talks to skeleton 7. Skeleton invokes remote object method

5 7

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 & server & so resides simulateneously on both machines. To define the remote service, we write a remote interface.All interfaces for remote objects must extend Remote interface defined in java.rmi package. All methods in those interfaces may throw a RemoteException.Such exceptions are thrown during a remote method call if there is a network problem

import java.rmi.*;

public interface Hello extends Remote { public String sayHello() throws RemoteException; } 2. Implementing the Remote Interface On the server side,you must implement the class that

actually carries out the methods advertised in the remote interface.Declare the remote interface being implemented. You can tell that the class is a server for remote methods because it extends UnicastRemoteObject,which is a concrete java class that makes objects remotely accessible. A UnicastRemoteObject object resides on a server.This is the class that we extend for all the server classes.Define a constructor for the remote object. Give an implementation for each method on the remote interface.By convention, the name of a class implementing an interface refers to the name of the interface and is ended by Impl.

import java.rmi.*;

import java.rmi.server.*; public class HelloImpl extends UnicastRemoteObject implements Hello

{ public HelloImpl() throws RemoteException { super(); } public String sayHello() throws RemoteException { return "Hello! How r u? "; } } 3. Server Program import java.rmi.*; import java.rmi.server.*; public class HelloServer { public static void main(String args[]) { try { Hello h=new HelloImpl(); Naming.rebind("server",h); System.out.println("object is registered"); System.out.println("now server is waiting"); } catch(Exception e) { System.out.println("error:"+e); } } } Locating Server Objects

To access a remote object that exists on the server,the client needs a local stub object.Then how can a client request such a stub? The most common method is to call a remote method of another server object & get a stub object as a return value. A server programs registers objects with the bootstrap registry service & the client retrieves stubs to those objects.You register a server object by giving the bootstrap registry service a reference to the object & a name. RMI URLs start with rmi:// & are followed by a server, an optional port number, another slash, & the name of the remote object. Eg: rmi://localhost:99:port/central_warehouse For security reasons,an application can bind,unbind or rebind registry object refrences only if it runs on the same host as the registry. Registry used for client bootstraping to get the initial reference.

java.rmi.Naming

a) registry access b) URL format : prot://host:port/name c) default protocol : rmi d) default host : localhost e) default port : 1099 f) all static methods:

void bind(String name, Remote obj); void rebind(String name, Remote obj); void unbind(String name); // unbinds the name Remote lookup(String url); // returns a stub

4. Client program import java.rmi.*; public class HelloClient { public static void main(String args[]) {

try { Hello h=(Hello)Naming.lookup("rmi://localhost/server"); System.out.println("client: Hello!"); System.out.println("server:" +h.sayHello()); } catch(Exception e) { System.out.println("Error:"+e); } } } 5. Registering the Object import java.rmi.*; import java.rmi.server.* ; import javax.naming.*; public class ShowBindings { public static void main (String args[]) { try { Context namingContext=new InitialContext(); NamingEnumeration e = namingContext.list(“rmi:”); while(e.hasMore()) System.out.println(e.next.getName()); } catch(Exception e) { e.printStackTrace(); } } } Then follow these steps:

1) Compile the source files for the interface, implementation, client & server classes.

2) run rmic on the implementation class 3) Start the rmi registry as: Start rmiregistry 4) start the server. 5) Run the client.

(draw diagram of this on page no.293) 5) Parameter Passing in Remote Methods There are two ways of passing parameters in remote methods: 1) Passing Non remote Methods -

When a remote object is passed from the server to the client, the client receives a stub. Using the stub, it can manipulate the server object by invoking remote methods. The object, however stays on the server. It is also possible to pass & return any objects with a remote method call, not just those that implements the Remote interface. The client gets a copy of the string. Then, after the call, the client has its own string object to work with. This means that there is no need for any further connection to any object on the server to deal with that string. Whenever an object that is not a remote object needs to be transported from one Java virtual machine to another, the Java virtual machine makes a copy & sends the copy across the network connection. This technique is very different from parameter passing in a local method. When u pass objects into a local method or return them as method results, only object references are passed. However, object references are memory addresses of objects in the local java virtual machine. This information is meaningless to a different java virtual machine. The RMI mechanism can also make copies of more complex objects, provided

they are serializable.RMI uses the serialization mechanism to send objects across a network. This means that only the information in any classes that implement the serializable. Eg: An object of type customer is then sent to the server. Because customer is not a remote object, a copy of the object is made on the server. The server program sends back an array list of products. The array list contains those products that match the customer profile & it always contains that one item namely, a copy of the book core java. Again ArrayList is not a remote class, so the array list is copied from the server back to its client.

2) Passing Remote Objects – In remote passing objects, the client receives a stub object, then saves it in an object variable with the same type as the remote interface. The client can now access the actual object on the server through the variable. The client can copy this variable in its own local machine – all those copies are simply references to the same stub. Only remote interfaces can be accessed through the stub. A remote interface is any interface extending Remote. All local methods are inaccessible through the stub. A local method is any method that is not defined in a remote interface. Local methods can run only on the virtual machine containing the actual object. Stubs are generated only from classes that implement a remote interface & only the methods specified in the interfaces are provided in the stub classes. If a subclass doesn’t implement a remote interface but a superclass does, & an object of the subclass is passed to a remote method, only the superclass methods are accessible. A remote class can implement multiple interfaces. For Eg: interface StockUnit extends Remote { public String getStockCode() throws RemoteException; } Class BookImpl extends ProductImpl implements StockUnit

{ public BookImpl(String title, String theISBN, int age1, int age2, String hobby) throws RemoteException { super(title + “Book” , age1, age2, hobby) ; ISBN =theISBN; }

public String getStockCode() throws RemoteException {

Return ISBN; } private String ISBN ; }

Now when a book object is passed to a remote method, the recipient obtains a stub that has access to the remote methods in both the Product & the StockUnit class. Cloning Remote Objects –

Stubs do not have a clone method, so you cannot clone a remote object by invoking clone on the stub. The reason is: If clone were to make a remote call to tell the server to clone the implementation object, then the clone method would need to throw a RemoteException.

6) Server Object Activation

We used a server program to instantiate & register objects so that the clients could make remote calls on them. However in some cases, it may be wasteful to instantiate lots of server objects & have them wait for connections, whether or not client objects use them. The activation mechanism lets you delay the object construction so that a server object is only constructed when atleast one client invokes a remote method on it.

To take advantage of activation, the client code is completely unchanged. The client simply requests a remote reference & make calls through it. However the server program is replaced by an activation program that constructs activation descriptors of the objects that are to be constructed at a later time, 7 binds receivers for remote method calls with the naming service. When a call is made for the first time, the information in the activation descriptor is used to construct the object. A server object that is used in this way should extend the Activable class & implement one or more remote interfaces. For ex: Class ProductImpl extends Activable implements Product { …………… }

You must provide a constructor that takes two parameters:

a) An activation ID b) A single object containing all construction information wrapped in a

MarshallObject. When you place a serialized (or marshalled) copy of the construction information inside the activation descriptor. Your server object constructor should use the get method of the MarshalledObject class to deserialize the construction information. To construct the activation descriptors, you need the following: a) The activation group ID for the virtual machine

which the object should be constructed. b) The name of the class c) The URL string from which to load the class files. d) The marshalled construction information.

Pass the descriptor to the static Activable.register method.

It returns an object of some class that implements the remote interfaces of the implementation class.You can bind that object with the naming service: Product p = (Product) Activable.register(desc); namingContext.bind(“toaster”, p) ; The activation program exits after registerin & binding the activation receivers. The server objects are constructed only when the first remote method call occurs. 7) CORBA

CORBA lets u make calls between objects written in any language. CORBA is an industry standard for distributed object computing, developed by Object Management Group (OMG). CORBA depends on having an ORB(Object Request Broker) available on both client & server. ORB act as a kind of universal translator for interobject CORBA communication. It Provides a set of common services eg: create, copy, move or destroy objects, to a “naming service” that allows you to search for objects if you know their name.

How CORBA differ from RMI:

RMI is Java-only. RMI is not an industry standard (it is a product of Sun). RMI does not provide such a rich set of services. RMI is simpler to use and integrates smoothly with Java.

Steps for Implementing CORBA objects

1) Write the Interface that’ specifies how the object works, using IDL, the interface definition language for defining CORBA interfaces. IDL is a special language to specify interfaces in a language neutral form.

2) Using the IDL complier for the target language(s), generate the needed stub & helper classes. 3) Add the implementation code for the server objects, using the language of your choice. Compile the implementation code. 4) Write a server program that creates & registers the server objects.The most convenient method for

registration is to use the CORBA naming service, a service that is similar to rmiregistry.

5) Write a client program that locates the server objects invokes services on them. 6) Start server program on server & client program on

client. A CORBA Example –

1) first you initialize the ORB.The ORB is a code library that knows

how to talk to other ORB’s & how to marshal & unmarshal parameters.

ORB orb = ORB.init(args , null) ; 2) Next , you locate the naming service that helps you locate other objects.However in CORBA, the naming service is just another CORBA object.To call the naming service, you first need to locate it.The call

String [] services = orb.list_initial_services(); lists the name of the standard services to which the ORB can connect.

3) To obtain an object reference to the service, you use the resolve_initial_references method.It returns a generic CORBA object, an instance of the class org.

corba.Object. org.omg.CORBA.Object

object=orb.resolve_initial_references(“NameService”);

4) Convert this reference to a NamingContext reference so that you can invoke the methods of the NamingContext interface.

NamingContext namingcontext=NamingContextHelper.narrow(object); 5) Now you have the naming context, you can use it to locate the object that the server placed into it.The naming context associates names with server objects.

6) A name component consists of an ID & a kind.The

ID is a name for the component & Kind is some indication of the type of the component.

IDL (Interface Definition Language)

IDL specifies interfaces b/w CORBA objects. CORBA is language independent, bcoz interfaces described in IDL can be mapped to any programming language. A client written in c++ can communicate with server written in java. IDL syntax is :

interface Product { string getDescription(); };

Differences b/w IDL & java :

a) The interface definition ends with a semicolon. b) string is written in lower case. c) In CORBA, the string contain only 8 bit characters,

whereas in java programming language, string contains 16 bit Unicode characters. IDL compiler generates a number of other source files – the stub class for communicating with the ORB & three helper classes.

IDL compiler generates a class with suffix Holder for every interface. for ex: when a Product interface is compiled, it automatically generates a ProductHolder class. In IDL you can use sequence construct to define an arrays of variable size.u must define a type before u can declare sequence parameters. Ex:

interface Warehouse { ProductSeq find(Customer c); };

IDL can contain constants also. Ex: interface Warehouse { const int SOLD_OUT =404; }; In IDL, u can group definitions of interfaces,types,exceptions & constants into modules. Ex: module corejava { interface Product { …… }; interface Warehouse { ………… }; };

8) Remote Method Calls with SOAP (Simple Object Access Protocol)

SOAP is an XML protocol, like CORBA’s IIOP ,that provides a protocol for invoking remote methods. In recent years, web services have emerged as a popular technology for remote method calls. A web service has two components:

a) A server can be accessed with SOAP transport protocol.

b) A description of the service in the Web Description Language (WSDL) format.

A primary attraction of web services is that they are language neutral. WSDL: WSDL is analogous to IDL.It describes the interface of the web service, the methods that can be called & their parameter & return types. The WSDL descriptor describes the services in a language independent manner.For Ex: the WSDL for the Amazon web services (located at http://soap.amazon.com/schemas3/AmazonWebServices.wsdl) describes an AuthorSearchRequest operation.

To make web services easy to understand, we look at an example : The Amazon web service allows a programmer to interact with the Amazon system for a wide variety of purposes.For ex: you can get listings of all books with a given author or title, or you can fill shopping carts & place orders.Amazon makes this service available for use by companies that want to sell items to their customers, using the Amazon systems as a fulfillment backend. (draw diagram on page no 337)