Unit-4 Distributed Objects

Lecture-18: The role of Client and server: collecting information on a client computer and sending the information across a network to a server. We are supposing that a user on a local machine will fill out an information request form. The data is sent to the vendor's server. The server processes the request and will, in turn, want to send back product information the client can view, as shown
in below.

Diagram for transmitting objects between client and server

Remote Method Invocations The Remote Method Invocation mechanism lets you do something that sounds simple. If you have 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, and the return value must be shipped back. RMI handles these details.For example, the client seeking product information can query a Warehouse object on the server. It calls a remote method, find, which has one parameter: a Customer object. The find method returns an object to the client: the Product object Figure Invoking a remote method on a server

In RMI terminology, the object whose method makes the remote call is called the client object. The remote object is called the server object. It is important to remember that the client/server terminology applies only to a single method call. The computer running the Java code that calls the remote method is the client for that call, and the computer hosting the object that processes the call is the server for that call. It is entirely possible that the roles are reversed somewhere down the road. The server of a previous call can itself become the client when it invokes a remote method on an object residing on another computer. Stubs and Parameter Marshalling When client code wants to invoke 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, not on the server. 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. For example, in the RMI protocol, numbers are always sent in big-endian byte ordering, and objects are encoded with the serialization mechanism. 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. To sum up, the stub method on the client builds an information block that consists of An identifier of the remote object to be used; A description of the method to be called; and The marshalled parameters.

The stub then sends this information to the server. On the 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 captures and marshals the return value or exception of the call. It sends a package consisting of the marshalled return data back to the stub on the client. The client stub unmarshals the return value or exception from the server. This value becomes the return value of the stub call. Or, if the remote method threw an exception, the stub rethrows it in the process Space of the caller. Figure shows the information flow of a remote method invocation.

Figure Parameter marshalling

Lecture-19:
Set up for RMI: Running even the simplest remote object example requires quite a bit more setup than does running a standalone program or applet. You must run programs on both the server and client computers. The necessary object information must be separated into client-side interfaces and server-side implementations. Also, a special lookup mechanism allows the client to locate objects on the server. To get started with the actual coding, we walk through each of these requirements, using a simple example. In our first example, we generate a couple of objects of a type Product on the server computer. We then run a program on a client computer that locates and queries these objects. Interfaces and Implementations Your 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 simultaneously on both machines. interface Product // shared by client and server extends Remote { String getDescription() throws RemoteException; } Just as in this example, all interfaces for remote objects must extend the Remote interface defined in the java.rmi

package. All the methods in those interfaces must also declare that they will throw a RemoteException. The reason for the declaration is that remote method calls are inherently less reliable than local callsit is always possible that a remote call will fail. For example, the server or the network connection may be temporarily unavailable, or there may be a network problem. Your client code must be prepared to deal with these possibilities. For these reasons, the Java programming language forces you to catch the RemoteException with every remote method call and to specify the appropriate action to take when the call does not succeed. The client accesses the server object through a stub that implements this interface. Product p = . . .; // see below how the client gets a stub reference String d = p.getDescription(); System.out.println(d); In the next section, you will see how the client can obtain a reference to this kind of remote object. Next, on the server side, you must implement the class that actually carries out the methods advertised in the remote interface. public class ProductImpl // server extends UnicastRemoteObject implements Product { public ProductImpl(String d) throws RemoteException { descr = d;

} public String getDescription() throws RemoteException { return "I am a " + descr + ". Buy me!"; } private String descr; } Diagram for RMI classes:

Parameter Passing Remote Objects Passing remote objects from the server to the client is simple. 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. It is important to note that only the 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. Next, stubs are generated only from classes that implement a remote interface, and 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, and an object of the subclass is passed to a remote method, only the superclass methods are accessible. To understand this better, consider the following example. We derive a class BookImpl from ProductImpl. class BookImpl extends ProductImpl { public BookImpl(String title, String theISBN, int sex, int age1, int age2, String hobby) { super(title + " Book", sex, age1, age2, hobby); ISBN = theISBN; } public String getStockCode() { return ISBN; }

private String ISBN; } Now, suppose we pass a book object to a remote method, either as a parameter or as a return value. The recipient obtains a stub object, but that stub is not a book stub. Instead, it is a stub to the superclass ProductImpl because only that class implements a remote interface . Thus, in this case, the getStockCode method isn't available remotely. Diagram for parameter passing:

Server Object Activation In the preceding sample programs, we used a server program to instantiate and register objects so that clients could make remote calls on them. However, in some cases, it may be wasteful to instantiate lots of server objects and 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 at least 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 and makes 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, and 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 Activatable class and, of course, implement one or more remote interfaces. For example, class ProductImpl extends Activatable implements Product { ... } Because the object construction is delayed until a later time, it must happen in a standardized form.Therefore, you must provide a constructor that takes two parameters: An activation ID (which you simply pass to the superclass constructor)

 A single object containing all construction information, wrapped in a MarshalledObject If you need multiple construction parameters, you must package them in a single object. You can always use an Object[] array or an ArrayList. As you will soon see, 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. In the case of the ProductImpl class, this procedure is quite simpleonly one piece of information is necessary for construction, namely, the product name. That information can be wrapped into a MarshalledObject and unwrapped in the constructor: public ProductImpl(ActivationID id, MarshalledObject data) { super(id, 0); name = (String) data.get();; System.out.println("Constructed " + name); } By passing 0 as the second parameter of the superclass constructor, we indicate that the RMI library should assign a suitable port number to the listener port. This constructor prints a message so that you can see that the product objects are activated on demand.

Lecture-20: CORBA: CORBA lets you make calls between Java objects and objects written in other languages. CORBA depends on having an Object Request Broker (ORB) available on both client and server. CORBA is a standard defined by Object Management Group that enables software components written in multiple computer languages and running on multiple computers to work together. ORB as a kind of universal translator for inter-object CORBA communication. The CORBA 2 specification defines more than a dozen "services" that the ORB can use for various kinds of housekeeping tasks. These range from a "startup service" to get the process going, to a "life cycle service" that you use to create, copy, move, or destroy objects, to a "naming service" that allows you to search for objects if you know their name.

(Client) main( )

(Server) main( )

Object Reference Stub code

Object Implementation Skeleton

Object Request Broker

Network

Object Request Broker

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 compiler(s) for the target language(s), generate the needed stub and helper classes. 3. Add the implementation code for the server objects, using the language of your choice. (The skeleton created by the IDL compiler is only glue code. You still need to provide the actual implementation code for the server methods.) Compile the implementation code. 4. Write a server program that creates and registers the server objects. The most convenient method for registration is to use the CORBA naming service, a service that is similar to the rmiregistry. 5. Write a client program that locates the server objects and invokes services on them. 6. Start the naming service and the server program on the server, and start the client program on the client. These steps are quite similar to the steps that you use to build distributed applications with RMI, but with two important differences: You can use any language with a CORBA binding to implement clients and servers. You use IDL to specify interfaces.

In the following sections, you will see how to use IDL to define CORBA interfaces, and how to connect clients implemented in Java with C++ servers and C++ clients with servers implemented in Java. The Interface Definition Language(IDL) Java IDL adds CORBA capability to java platform, providing standard based interoperability & connectivity. Java IDL enables distributed web enabled java applications to transparently invoke operations on remote network services. IDL is a special language to specify interfaces in a language neutral form. By IDL we write the interface of CORBA. With CORBA, the starting point is an interface in IDL syntax: interface Product { string getDescription(); }; There are a few subtle differences between IDL and Java. In IDL, the interface definition ends with a semicolon. Note that string is written in lower case. In fact, the string class refers to the CORBA notion of a string, which is different from a Java string. In the Java programming language, strings contain 16-bit Unicode characters. In CORBA, strings contain only 8-bit characters. If you send the 16-bit string through the ORB and the string has characters with nonzero high byte, an exception is thrown. This kind of type mismatch problem is the price you pay for interoperability between programming languages.

Lecture-21: Remote Method call with SOAP: SOAP stands for Simple Object Access Protocol.SOAP is a XML based protocol for communication between applications.It is used in Internet.& is a W3C recommendation. CORBA uses SOAP protocol to communicate between objects. SOAP is defined by WSDL(Web services Description Language). SOAP provides a way to Communicate between applications running on different operating systems with different technologies and programming languages. SOAP Building Block: A SOAP message is an XML document having elements 1) An envelope element that identifies the XML document as a SOAP message. 2)A header element that contains header information. 3)A body element contains call and response information. 4)A fault element contains error and status information. The Syntax of SOAP message is as follows:<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... ... </soap:Header> <soap:Body> ... ... <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope>