Syllabus Introduction to Java Distributed Objects - Using RMI and CORBA | CSCE 590B, Study notes of Computer Science

Download Syllabus Introduction to Java Distributed Objects - Using RMI and CORBA | CSCE 590B and more Study notes Computer Science in PDF only on Docsity!

Introduction to Java Distributed Objects - Using RMI and CORBA

Welcome to the Course

Description: This course introduces how to program distributed objects using Java Remote Method Invocation (RMI) and using the Common Object Request Broker Architecture (CORBA) Prerequisites: To get the most out of this course, you need to be an experienced Java programmer Objectives: When you have completed the course, you should be able to: Contrast RMI and CORBA both at the conceptual and technical levels Write simple RMI and CORBA programs using the Java Development Kit (JDK) version 1.

Welcome to the Java distributed objects course! Before we start, let's cover a few details. First of all, what should your background be? To get the most out the course, you already be a pretty good Java programmer. We will not cover any Java syntax. In particular, you should be comfortable with the notions of classes, interfaces, applications and applets. You don't need any background in distributed objects, however.

When you finish the course, you should have a pretty good idea about how distributed objects work in Java. You should also be able to code simple programs using either RMI or CORBA.

Now on to our agenda!

Twisted Transistors, Inc. : the Beginning

Once upon a time, Jill and Bill started a new company named Twisted Transistor, Inc. to manufacture LCD panels for laptop computers. At the beginning, with only a few people in the company, and only one building, life was easy. When they needed to meet, they just walked over to someone's office and hashed things out. All of their work was done at one location, and communication was simple.

Twisted Transistors, Inc.: Growing Pains

But then a funny thing happened: the company grew, and soon found that it needed more space. The problem was, office space was expensive in their town, so they rented a building in Silver City, 10 miles away. This gave them more space to work and to manufacture product, but now things that were easy before became difficult.

For example, running a meeting was a nightmare compared to before. How could they get all of the meeting participants together? First they tried shuttling employees from one building to another, but that wasted too much time in transit. Then they tried conference calling, but found that to be awkward and it was difficult to show technical diagrams and presentations to each other.

What Twisted Transistors needed was a way to make it seem like employees were together, when in fact they were spread out geographically.

Introduction to Distributed Objects

remote object

client computer object server computer

The big problem Twisted Transistor had was making people in a remote location easily accessible. We can have the same issue with applications that we write. Often, applications grow, just like Twisted Transistor did - the program might start out as a single-user program, but may expand to allow multiple people to access the program at the same time.

And remember, Java is an object-oriented language, so our real problem is: how do we work it so that programs running one computer can call methods on objects that reside on another? If we can pull this off, then we can distribute the computing load across networks - instead of writing standalone, single user programs, we can write programs that fully utilize our network.

Such programming is often referred to as client/server programming - the program issuing the method calls is the client, and the computer that supplies the remote object is the server.

Twisted Transistor solved their meeting problem by allowing people in separate offices to interact naturally - our goal here is to find technology so that remote and local objects can interact naturally.

Why Java for Distributed Objects?

Java is an easy-to-use, intuitive language that enforces O-O programming Java works on many platforms The Java infrastructure can automatically download code to client computers Java tools are becoming mature and widespread Potential downside: execution speed versus compiled languages like C++

If you've decided that distributed objects are a good thing, your next job is to choose a distributed object infrastructure and your programming language. We'll come back on the infrastructure part in just a moment, but now let's talk about the programming language.

This tutorial covers distributed objects using the Java programming language. Why Java? Because Java is ideally suited to the task. Most distributed object programs run on a mixture of operating systems, for example Windows for the client and a UNIX variant such as IBM's AIX for the server. Since Java itself is platform neutral, it lets you develop, test and deploy across different platforms without having to change languages.

In addition, the tool market for Java is exploding. Vendors such as IBM are developing powerful application servers that serve up Java distributed objects using technologies like Enterprise Java Beans. While we will not cover EJBs here, their use of Java helps to validate our choice of Java for this tutorial.

Finally, we would be remiss if we didn't at least mention that Java is not always the solution. During this program, we will discuss one infrastructure technology, CORBA, that lets you use compiled languages such as C++ whenever performance is the ultimate criteria.

Introduction to RMI

MyRemoteObject o = ...; o.myMethod ();

Sample Client Code

client

server

remote object

Note: All of the code in this course has been compiled and tested with JDK 1.2, Release Candidate 1. Please consult the documentation for the version of the JDK that you are using for details on changes for that version.

We will start our discussion of distributed object technologies with Java's Remote Method Invocation, which was introduced in Java 1.1.

RMI's purpose is to make objects in separate virtual machines look and act like local objects. The virtual machine that calls the remote object is sometimes referred to as a client. Similarly, we refer to the VM that contains the remote as a server.

Obtaining a reference for a remote object is a bit different than for local objects, but once you have the reference, you call the remote object just as if it was local as shown in the code snippet. The RMI infrastucture will automatically intercept the request, find the remote object, and dispatch the request remotely.

This location transparency even includes garbage collection. In other words, the client doesn't have to do anything special to release the remote object -- the RMI infrastructure and the remote VM handle the garbage collection for you.

RMI Architecture

• skeleton
• remote object

client

• stub

server

RMI Transport

RMI Transport

MyRemoteObject o = ...; o.myMethod ();

Sample Client Code

To achieve location transparency, RMI introduces two special kinds of objects known as stubs and skeletons.

The stub is a client-side object that represents the remote object. The stub has the same interface, or list of methods, as the remote object, but when the client calls a stub method, the stub forwards the request via the RMI infrastructure to the remote object, which actually executes it.

On the server side, the skeleton object takes care of all of the details of "remoteness" so that the actual remote object doesn't need to worry about them. In other words, you can pretty much code a remote object the same way as if it were local -- the skeleton insulates the remote object from the RMI infrastructure. During remote method requests, the RMI infrastructure automatically invokes the skeleton object so it can do its magic.

The best news about this setup is that you don't have to write the code for the stubs and skeletons yourself! The JDK contains a tool, rmic, that creates the class files for the stubs and skeletons for you.

Server Development Steps Overview

Define a remotable interface Write a class that implements the remotable interface Write a server main program that creates an instance of the implementation object and assigns the object a name Run the rmic compiler to generate the code for the stubs and skeletons

Now let's take a look at the steps involved in writing the object server. We will look at the client side in a few moments.

The first thing you need to do is define an interface for the remote object. This interface defines the methods that the client can call remotely. The big difference between a remoteable interface and local interface is that remote methods must throw the exception described on the last page.

Next, you must write a class that implements the interface.

Next, you need to write a main program that runs on the server. This program must instantiate one or more of the server objects and then typically registers the remote objects into the RMI name registry so that clients can find the objects.

Finally, you need to generate the code for the stubs and skeletons. The JDK provides the rmic tool, which reads the remote object's class file and creates class files for the stubs and skeletons.

Writing a Remote Interface

import java.rmi.*;

public interface Meeting extends Remote { public String getDate () throws RemoteException; public void setDate ( String date ) throws RemoteException; public void scheduleIt() throws RemoteException; }

Here's the interface definition for a simple remote interface. Objects that implement this interface provide a three methods: one that returns a string, one that accepts a string as an argument, and one that accepts no arguments and returns nothing. As mentioned earlier, these methods must throw the RemoteException, which clients will catch if something goes wrong with the communication between the client and server.

Note that the interface itself extends the Remote interface that's defined in the java.rmi package. The Remote interface itself defines no methods, but by extending it, we indicate that the interface can be called remotely.

Writing an RMI Server Overview import java.rmi.; import java.rmi.server.; public class MeetingServer extends UnicastRemoteObject implements Meeting {

... public static void main ( String [] args ) throws RemoteException, java.net.MalformedURLException, RMISecurityException { // 1. Set Security Manager // 2. Create an object instance // 3. Register object into the name space } }

In addition to implementing the interface, we also need to write the server's main program. RMI currently does not support server programs as applets, so the main program needs to be a standalone Java application. You can either code a separate Java class for main, or you can just code a main method in the implementation class as we did here.

Note also that we coded the main function to throw any RMI-related exceptions to the command line. That's OK for a small sample program like this, but in a real program you will probably instead bracket the steps that follow in separate try-catch blocks so you can perform better error handling.

The steps that the server main typically does are:

1. Install a security manager class that lets the server program accept stub classes from other machines
2. Create an instance of the server object
3. Register the server object into the RMI naming registry so that client programs can find it

Let's now take a closer look at each of these steps.

Setting the Security Manager import java.rmi.; import java.rmi.server.; public static void main ( String [] args ) throws RemoteException, java.net.MalformedURLException, RMISecurityException { System.setSecurityManager ( new RMISecurityManager() ); MeetingServer ms = new MeetingServer(); Naming.rebind ( "rmi://myhost.com/Meeting", ms ); }

The first step is to install the RMI security manager. While this is not strictly required, it does allow the server virtual machine to download class files. For example, suppose the client calls a method in this server that accepts a reference to an application-defined object type, for example a BankAccount. By setting the security manager, we allow the RMI runtime to copy the BankAccount class file to the server dynamically - that eases the configuration on the server.

The downside to letting RMI dynamically download such classes is that it's a security risk. In other words, we are essentially letting the server execute code from another machine. While we hope that these class files are not going to harm the server, if you want to avoid the risk, your RMI server should not install a security manager. You must then ensure that all class files are installed locally in the server's classpath.

And now just an aside before we move on: passing object argument types is actually a pretty involved topic, since there are two ways to do it. One way is to pass only a reference across the communication wire; the other is to serialize the object and create a new object remotely. We will not discuss these any further since we don't have enough time, so you should read the RMI documentation in the JDK for more details.

Generating the Stubs and Skeletons

MeetingServer.class

rmic

MeetingServer_Stub.class

MeetingServer_Skel.class

After writing and compiling your server implementation, you're ready to create the stubs and skeleton classes. And that's easy to do: just run the JDK's rmic command, specifying the name of your implementation class file (without the extension). RMIC will create a class file each for the stub and skeleton. You will then need to deploy these files properly, which we will cover after we cover writing the client-side code.

Client Development Overview

Determine whether you want to write a client application or applet Write the client to look up the object in the naming registry Call remote methods

Now let's take a look at the client side. First, you must determine whether you want to write a client standalone application or a client applet. Applications are a bit simpler to setup, but applets are easier to deploy since the Java and RMI infrastructure can download them to the client machine. We will cover how to do both kinds.

In your client, the code needs to first look up the remote object using the RMI registry. Once you have done so, the client can then call the methods defined by the remote interface.