Distributed Computing - Computing systems in which
services to users are provided by teams of computers
collaborating over a network.   - A Glossary Definition

http://www.cs.cornell.edu/wya/DigLib/MS1999/Glossary.html

One Famous Distributed Application

We are now use to the idea of surfing the Internet,
clicking on a page and having that page appear in our
browser. We don't think much of the fact that millions
of others are simultaneously accessing millions of
machines on the Internet which are all cooperating
to supply a user with a single experience.

Our PC with it's browser and the huge number of HTTP
servers with their stored HTML pages are cooperating
seamlessly to give the impression that everything is
happening in one 'massive' local environment.

Without being too formal about definitions, The World
Wide Web in fact is one grand distributed application.
The whole business of negotiating the TCP/IP protocol,
with it's IP addresses, ports, sockets and hyperlinked
pages are all hidden away in the World Wide Web,
application design.

// The Internet is a great example of a distributed application

Distributed Computing

Operating System Processes

The operating system is the software that coordinates
the different components that make up a computer system.
The operating system provides coordination between the
software and hardware and the user of a system. It also is
specifically assigned the job of booting the computer which
involves loading a short program that allows the system to
self start. The operating system also has the responsibility
of allocating memory resources and the maintaining a file
system.

All these different tasks are carried out by sub-routines
operating in separate address spaces called 'processes'.

// different tasks of the operating system are carried out
// in sub-routines called 'processes'

Multiproccessing & Networking Facilitate Distributed Computing

Early in the days of Unix, work was done to allow these
processes to communicate with each other. At first different
processes running on the same machine would interact.
We have seen this sort of communication in the Java's
Thread environment while using the Producer Consumer
model. 

The advent of networking technology, network protocols and
the ability of processes to communicate with each other made
possible the idea of distributing the functions of a single program
or a collection of interacting programs over the processes of
many machines working in tandem. This is essentially the
idea behind distributed computing.

// a distributed application is a single program or collection of interacting
// programs that distribute functions over many processes working on
// many machines in tandem

EDI, Electronic Data Interchange   // an early networked application

Many of the first distributed network programs were proprietary
schemes invented by companies to serve the needs of firms
such as banks, airlines and manufacturers. These applications
may have used custom networks or networks based on EDI,
(an abbreviation for Electronic Data Interchange) . 

The growth of the Internet into an exceedingly strong and
robust communication system has led to a great migration
of business applications to the Internet where they can take
advantage of both the reach and economy of scale supplied
by the Internet.

// today's distributed commercial applications have migrated to the net
// to take advantage of the installed infrastructure, the reach and the
// economy of scale which the Internet affords.

Advantages of Distributed Computing

RMI, CORBA and Enterprise JavaBeans all are APIs that
Java supply to enable the creation of distributed network
applications. Learning to use these programming tools is
not simple. Before we do it is fair to ask, "What are the
advantages that distributed applications provide?"

A distributed application can provide inexpensive distributed
customer service. Isolated locations can be afforded the
same interactive service over the Internet as a customer
would receive in a large municipal center. Distributed
applications make servicing a widely distributed market
feasible.

A real world example, recently I ordered a few electronic
components ordered at 4 in the afternoon on a Tuesday.
Some kind of a record, they were in my rural mailbox
on Wednesday, first thing in the afternoon.  They were
sent from Minnesota to central southern Ontario.  By car
it would be 15 or 20 hours. The great lakes are between
Minnesota and Southern Ontario!

I tried local retailers but all the parts were two specialized
for them to keep on the racks.

While I am describing the physical response, the whole
transaction was done over the net in moments and the
delivery system is also facilitated by a couriers distributed
application.

// able to supply service over large thinly populated
// areas, makes niche markets viable

Better Management of Product Inventory

Distributed applications can retrieve widespread 'information'
which can be used to better manage product inventory. The
program can be designed to observe trends and anticipate
inventory requirements. Inventory can be kept lower while still
be more readily available.

// reporting fromdistribution centers can make inventory control more efficient

Economic Advantages of Large Scale Marketing

Distributed applications can supply a dynamic continent
wide, paperless marketing strategy that reduces the amount
of stationary resources that are dedicated to supporting
marketing campaigns. If the campaign needs to be changed
the paper resources are not wasted. Printing can be done
on location to eliminate shipping costs.

// delivery and updating of marketing more economical, less bulk

Single Point of Contact For Multiple Services

Distributed applications can also supply a single contact
point for a number of services. A number of banking
programs offer standard account services, investment
banking and bill paying all from the same web site.

// supplies a single service point for a number of services

Dynamic Information Gathering Across Large
Geographic Areas

A distributed application can be used to coordinate a
mobile work force like United Parcel Service where the
delivery of a parcel is tracked all along it's route. Each
station in the distributed network is adding information
that is used by coordination center and the customer.

// dynamic information gathering over large geographic areas

Resource Sharing

Another main advantage of distributed computing is
resource sharing. Simple networks like classrooms have
a good example in that a printer can be shared by many
stations. Distibuted applications can fine tune and expand
the sharing process to include communication channels,
supercomputer services, information data sources and
multiple databases.

// sophisticated resource sharing

Fault Tolerance

A distributed application can also provide fault tolerance
by replicating services. When error condition is detected
an alternate service path may be provided. The system
can be designed to scale easily by adopting the idea that
no single resource should be in restricted supply and can
always be augmented.

// provides fault tolerance and scalability

Allows Heterogeneous Systems to Communicate

One major advantage afforded by distributed applications
is they may supply the ability for heterogeneous systems
working with different operating systems, hardware and
programming dialects to communicate together in universal
systems.

// enable heterogeneous computer systems  to communicate

Beyond business, distributed computing applications have
obvious applications in the science, whether to coordinate
weather observations or to remotely control 'robots' doing
exploration on Mars.

All these advantage were not lost on the authors of Java
and they have supplied a number of APIs that allow the
developer to create distributed applications.

The same technologies that were described for use on
the middle tier of a database application are used in
the creation of distributed applications. In fact database
applications over multiple tiers meet the criteria of being
defined as distributed applications. 

The tasks of coordinating the front and back ends of
distributed applications are usually managed from the
advantage of the middle tier in a network architecture.
Programs that are dedicated to running from this vantage
point have come to be known as 'middleware'.

Java supplies a number of technologies to work in this
domain where servers on the web are being used
increasing to host for many middleware activities.

// middle comes from the middle tier of a three tier
// architecture between the client & the 'back end'.

Java APIs Used in Middleware Applications

• Servlets
• Java Server Pages // and related APIs
  
• RMI
  
• Enterprise JavaBeans
• the CORBA API
  
• Java Web Services // XML mediated Java Apps
  

In terms of Java RMI, CORBA, Java Messaging Service
and Enterprise JavaBeans are all APIs which can supply
middleware solutions. Servlets and Java Server Pages
are a dedicated type Java software that can be used to
create 'web applications', a variation of middleware.
Servlets are designed specifically to act as a replacement
for the zone defined by CGI or the Common Gateway
Interface that is described as part of the HTTP protocol.

In a simple Web application, servlets and or JSPs can
coordinate the client and the database back end on their
own. In more sophisticated web applications, the servlets
and JSPs form a Web tier that communicates with an
application layer which will be typically based on EJBs.

Example APIs Used to Create Middleware On Middle Tier

Client <->
         Servlet/JSP <->
          [opt. application layer (EJBs / RMI / JMS )] <->
                                                                Data Source

// Servlets & JSPs allow using HTTP as a portal

Another Simpler Configuration

Client <-> RMI / CORBA <-> Data Source

RMI

RMI is a 'all Java', 'in house' distributed computing API.
RMI can connect different platform types as long as they
are hosting a Java Virtual Machine.

CORBA

CORBA is a design that is in scope bigger then Java
in that it can allows applications written in a number of
different programming languages to communicate.
CORBA is a kind of 'United Nations' of distributed
computing with it's translators. Java supplies an API
to participate in CORBA based systems.

EJBs // build on RMI, add delegating container support to vendors

Enterprise JavaBeans or EJBs are a sophisticated
middleware solution that allows issues like security
and transaction management be delegated to vendors
of Containers. The Containers in turn run the developers
EJBs. Enterprise Java Beans build on RMI as well as
using aspects of other APIs like JDBC and CORBA.

EJBs seem to have had a few fumbles along the way when 
compared to wildly successful products like servlets and
JSPs. EJB's have been criticized in the early days for poor
performance. EJBs seem to be still be evolving, largely in
association with the open source movement and continue
garner a lot of interest.  // June 2010

RMI is 'Grass Roots' and Vendor Free

While, Web applications, CORBA and EJB applications
will typically involve the use of products supplied by large
corporate vendors, RMI is distinct in that it is a very
fundamental API of Java. A 'grass roots' developer can
create a robust distributed Java application using nothing
but the Java Development Kit and the RMI API. ( A naming
service like Java's JNDI would typically be added to make
the app more robust. )

// Open Source Apps are now available for Enterprise Java Beans

Before we look at RMI in detail we survey other general
distributed application solutions that have been been
developed.

The systems that have been developed to do commercial
distributed computing typically are comprised with a set
of cooperating services. The collection of services that
constitute a distributed architecture is called a distributed
framework. Following are major frameworks and the
organizations that sponsor them.

Distributed Framework

Distributed Framework =  { a set of cooperating services }

The Open Group & DCE  

The Open Group was originally called the Open Systems
Foundation. Open Group was merged with the X/Open
group in 1996. The X/Open group was famous for the
database connectivity standard that is used by both
Sun's JDBC and Microsoft's ODBC. The Open Group
can be found at www.osf.org. The X in X/Open seems
to have been dropped sometime after 1997.

// originally 'Open Systems Foundation'

The Open Group is dedicated to supporting technology
neutral solutions and improving the efficiency of information
systems. The Open Group provides testing and certification
services, advanced research and support for various
standards.

// dedicated to technology neutral solutions

The Open Group has major companies as sponsors
including Compaq, IBM, Hewlett-Packard, Sun, Fujitsu,
Siemens, and Motorola. The Open Group support an
API for allowing distributed programs to communicate
across heterogeneous platforms called DCE or
'Distributed Computing Environment'.

DCE

DCE is a suite of technologies. Many major vendors
provide DCE systems. Just to select a few names from
a long list of users, DCE systems are used by Barclays
Bank, Bell Atlantic Network Services,  Bell Northern
Research, Caterpillar, Citibank, The Jet Propulsion
Laboratory, LEXIS-NEXIS, NASA, Hughes Technology
Systems and the United States Army.

// DCE is platform neutral, operating system independent

DCE software services operate independently of the
operating system and networking technology that the
application uses. As a result, it enables interaction
between clients and servers in just about any type of
environment an organization may have in place.

DCE is a set of C interfaces that base their operations
in the distributed environment on Remote Procedure
Calls. DCE services include Security, Directory, Time,
Thread and Distributed File Services.

// C programs

RPCs Remote Procedure Calls  RPC an abbreviation of Remote Procedure Call is a technology  that was developed by Sun Microsystems to make remote method calls in a distributed environment. Sun submitted The Remote  Procedure Call Protocol Specification as an Request for Comment  to the Internet Advisory Committee as RFC 1050 in 1988. RPC is the forerunner of Java's Remote Method Invocation API which abbreviates to RMI. .

Microsoft's DCOM

Microsoft provides DCOM, a windows only version of
DCE. DCOM is an abbreviation for the Distributed
Component Object Model. DCOM was often contrasted
and compared in popular computer literature of the 1980's
and 1990's to CORBA. DCOM's distibuted object protocol
allows for the creation of distributed applications to be 
spread across a network, though the implementations are
characteristically limited to working only on the Windows
platforms only.

The Microsoft DCOM homepage is located on the web at:

http://www.microsoft.com/com/tech/dcom.asp.

DCOM was previously called Network OLE. DCOM is
based on the Open Group' DCE-RPC specifcation. 
In literature, DCOM has been described as able to work
with Java programs by wrapping the Java object inside
a COM-compatible wrapper.

OMG & CORBA

The OMG, an abbreviation of the Object Management
Group is today's dominant consortium for supporting the
famous distributed  computing architecture called CORBA.
It is also the custodian of several other important standards
such UML, the Unified Modeling Language.

The OMG homepage is at      http://www.omg.org.

// famous for custody of CORBA & UML

The OMG is a non-profit consortium of over 800 companies.
All the specifications that the OMG develop are available
for download free of charge. As we will see CORBA enables
object-oriented communications across networks comprised
of stations running heterogeneous languages, operating
systems and hardware. Java provides an implementation
of CORBA which we will look at in detail later in the
course.

RMI Programs Can Be Multi-Functional

RMI allows multiple functionality to be spread over a set
of remotely located, machines cooperating over a network.
An RMI program is not limited to calling a single type of
action on another machine. A remote invocation may be
a calculation, a database access or some kind of file
access. Anything that can be coded is available to be
called from within an RMI program.

RMI Is Written, No Surprise, in Java

Another key feature of an RMI program is that it is written
in the Java. (This isn't surprising but it is a key feature of
RMI!) The RMI API is designed to create object-oriented,
distributed programs written entirely in Java. RMI allows
the objects of one program to access the objects of another
program running on a distant machine.

Because of the object oriented nature of Java, RMI programs
then may be described as deploying distributed objects

Instead of a person clicking on a link to get as page
to load as one does on the web, in an RMI program, some
object in a program may call a method on an object that is
stored on the distant server. The client program sends
information in the form of method arguments, and gets
back data in the form of method return values.

RMI Hides the Sockets

Like the WWW, the business of creating sockets and dealing
with TCP/IP are all hidden away in the RMI architecture. In it's
place is the list of things a programmer needs to do and provide
to put an RMI system into place.

// RMI creates object-oriented, distributed programs written in Java.
// It's primary mechanism is the method call

RMI Descends From RPC, Remote Procedure Call

RMI is an abreviation for Remote Method Invocation. RMI is
an object-oriented, version of an older system deviced by Sun
Microsystems called RPC or Remote Procedure Call. In RMI
a remote object is by definition an object running on another
JVM or Java Virtual Machine. A number of different JVM's
can be running on the one machine or across a number of
machines which are remote to each other.

Using Localhost for Testing

Testing an RMI application using 'localhost' on a number
of local JVMs is a practical way for a programmer to
develop an RMI system before deploying over a network.

// use  local host for development

RMI is Similar to CORBA

RMI is similar to CORBA. The main difference is that
CORBA goes one step further than RMI. While RMI is
an all Java architecture, CORBA allows remote object
interaction between machines which are executing
applications written in different programming languages!

// RMI is like CORBA except not multi-lingual
 

JRMP, Java Remote Method Protocol

RMI uses a TCP/IP level protocol which has been named
called JRMP or 'Java Remote Method Protocol'. RMI has
been released in two versions. The first version that came
with JDK 1.1.x and earlier used classes referred to as
'stubs' and 'skeletons' to encapsulate TCP/IP socket
connections. The newer version of RMI that comes with
JDK 2 (version 1.2 and later) has eliminated the need for
the skeleton class.
 

What does RMI and CORBA have in common? 

CORBA and Remote Method Invocation both use special
compilers that generate, the connectivity parts of their
distributed systems. Both encapsulate and hide the 'net'
aspects of the distributed application, such as socket
creation, away from the programmer. You won't see overt
Socket objects being created in any of these systems but
they are there 'behind the scenes'.

Both CORBA & RMI use Special Compilers  // translators

Both systems use interfaces to specify operations that
will be supplied as services on remote machines and are
callable from within a client application. By following the
syntax recipe for the particular API being used, a method
can be called on the local machine and the actual code
will be supplied by the remote service. The code doesn't
appear to have done anything but make a local call. At
least this is the appearance RMI attempts to provide. 
give. The presence of URLs and network port numbers
allude to the fact that 'long distance' network calls are
being made behind the scenes in these applications.

// both systems hide away net aspects of the application

Some RMI CORBA Similarities

• both use custom compilers
• both specify operations in interfaces
• both hide away socket creation
• both create distributed applications

• CORBA unlike RMI is not language specific
• CORBA adds an additional translational stage
  

RMI is designed to work over networked systems. It was
built to take advantage of the relative autonomy each layer
of the network models have. The layers of RMI architecture
parallel the operations of the classic network models. The
RMI architects describe RMI at the Stub & Skeleton Layer,
The Remote Reference Layer and the Transport Layer.

Diagram of the RMI Architectural Layers

 Client                     Server
   |                          |
 Stub <-- not seen in code -->  Skeleton*
   |                          |
 Remote                     Remote
 Reference                  Reference
 Layer                      Layer
   |                          |
Transport <------------->  Transport

* Skeletons not part of newer RMI versions

The Stub ( & Skeleton Layer )

Mentioned earlier, the original RMI uses objects called
'stubs' and 'skeletons' while the newer version does not
use the skeleton. It doesn't impact the developer a great
deal except in terms of file housekeeping as these objects
are automatically created by the 'rmi' compiler. For the
discussion, we'll talk about the original RMI.

The stub and skeleton operate below the view of the
Java application. You don't see them in your code or
make any reference to these objects in a Java program.
The special tool 'rmic' which abbreviates 'rmi compiler',
resides in the  jdk1.x.x_xx\bin directory along with the
'javac' and 'java' commands.) The stub and skeleton
are responsible for packaging and transferring parameters
to the network layer for transport to the remote server.

// stubs and skeletons generated by the rmic tool
// package and transfer arguments for the network
// layer.

The stub interfaces the client to the the RMI protocol below.
The stubs provide proxies for remote services. The stubs
notifies the Remote Reference layer that a call needs to be
made. The stub passes parameters to the Remote Reference
layer and receive the return values when the methods have
returned.

The old terminology of RPC for managing the parameter
passing between the client and the remote service was
called 'marshaling' parameters.

// old RPC would talk of 'marshalling parameters'

The Remote Reference Layer

The Remote Reference Layer is primarily responsible for
making the correct representation of the data to Transport
layer. Different parameters may be passed over an RMI
system. They include RMI type objects, primitive types
or generic serializable Java objects. Each will result in a
different types of packaging for transport. These details
are handled by the Remote Reference Layer.  

//  handling the packaging of Java types for transport 
 

The Transport Layer

Below the Remote Reference Layer is the Transport
Layer. The Transport layer embodies the creation and
maintainence of a TCP/ IP socket connection. This
layer takes care of resolving the address of the target
remote service, creating a connection between the client
and server and streaming the data between the two.

Besides standard TCP/IP socket connections, the RMI
transport layer also defines firewall penetration schemes
such as HTTP protocol tunneling. Once data leaves the
RMI Transport Layer it is in packaged and transported
within the generic TCP/IP protocol packets used by the
Internet.     

// TCP/IP socket layer  
  

Layer Architecture Enables Migration To RMI-IIOP

One advantage of this separation of functions into layers
is that it allows the transport protocols to be interchanged
with other protocols without affecting the operation of the
top layers of the system. RMI in fact is so close to CORBA
in functionality that there is a strong movement to adapting
RMI for use with the CORBA architecture. In this scenario,
the CORBA IIOP protocol is used at the transportation
layer which lends the name RMI-IIOP to the hybrid scheme.

The name given for protocol that allows RMI to work over
TCP/IP is JRMP or Java Remote Method Protocol. Corba's
IIOP is Internet Interorb Protocol. Both are functionally
based on TCP/IP.
 

The Proxy Pattern

// RMI is a popular example of the Proxy Pattern

In the local client the stub is standing in for the remote server's
implementation of the function. The 'stand-in' code is acting
as a proxy on behalf of the remote service. RMI is according
described as an implementation of one of the design patterns
described in the famous book 'Design Patterns' by E.Gamma
et al ., The intent of the Proxy design pattern is described in
the book as follows.

The Proxy " provides a surrogate or placeholder for another
object to control access to it." In the RMI model the stub
adopts the role of the proxy and represents the remote
object in the local context.

// stubs & skeletons seen as proxies or placeholders

What we do now is splash an example of an RMI client and
server to provide a 'wide angle' overview of the process that
is involved in using RMI.  In the next section we will look at the
RMI process in more detail, analyzing the essential features
of the system and considering other practical aspects involved
in using RMI.

The RMI Remote Interface

The process begins by creating an RMI interface. The RMI
interface defines the method or methods that will be provided
by the remote service.
 

Example of an RMI interface

public interface InCoExchange extends java.rmi.Remote{
   public double lowest_asking( ) throws java.rmi.RemoteException;
   public double highest_bid( ) throws java.rmi.RemoteException;
   }

Supplying the Remote Service

An implementation of the interface has to be generated. There
are two components to providing a remote RMI service. First
there is a server component whose main job is to instantiate
the remote implementation object and to 'bind' the object with
a name, via a naming service. The second component is the
remote service implementation object itself.

// the server hosts the remote implementation object and registers the
// object with a naming service

The second component has to be built first before the server
can host it. There are two common approaches that can be
taken to build the remote service implementation object.

Two Approaches 

First, a class can be created that implements the remote
interface. This class is then instantiated inside a separate
server class. The second approach combines the server
and implementation by creating an RMI server that is also
serves as it's own implementation class.

Variations of  Supplying a Remote Object

Approach 1 

• Implementation implements Remote interface { }
• Implementation class is instantiated inside a server class

Approach 2 

• The server class itself implements the Remote interface{ }

In our first example we'll demonstrate the second approach.
In the next RMI note we will create an implementation class
which will be instantiated inside an RMI server.

// which is better depends on the purpose

Which is the Best Approach Depends on the Application

Which method is better depends on what is being done. 

The first technique is more modular and facilitates change.
If a server's role is to provide a set of services that may
be changed over time, for instance a set of financial or
math functions, creating implementation classes that are
instantiated inside the server might be the best way to go.

On the other hand, if the service will be dedicated to a
single task, it might be easiest to integrate the service
as a method of the Server class. The example that follows
shows a Server that is also the implementation class.

The RMI Server

Observe in the following code  the java.rmi packages are
imported. To qualify as a RMI remote object, the class
extends the RMI class, UnicastRemoteObject. This is not
the only way to become an RMI remote object but it is
likely the commonest. The second qualifier, the class
implements the remote interface we created earlier.

In this example the server is instantiated in main( ). This
is also where the service is 'bound' to a name using RMI's
built-in naming service. The server implements the remote
interface 'InCoExchange' (which we defined above) and
so serves the role of being the remote implementation.
As part of this 'contract' it supplies the implementations
for both methods that are defined in the remote interface.
We look at these details more later.

We bring the RMI java.rmi.Remote interface forward
so all the code is in the same place.

The Extension of the RMI Remote Interface  

An RMI Server also Acting as the Remote Implementation

import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
import java.rmi.RMISecurityManager;

public class InCoServer extends UnicastRemoteObject implements InCoExchange{
 public InCoServer( ) throws java.rmi.RemoteException {
   super( );
   }

// Implementations of the methods of the interface InCoExchange

/*1*/
public double lowest_asking() throws java.rmi.RemoteException{
 // getLowestAsking() returns 9.50 from somewhere and is assigned to asking
    double asking;
    asking=9.50;
    return asking;
    }

/*2*/
public double highest_bid() throws java.rmi.RemoteException{
   // getHighestBid() returns 7.50 from somewhere and is assigned to bid
      double bid;
      bid=7.50;
      return bid;
      }
//If you are getting a binding exception comment out the call to setSecurityManager( )

public static void main(String[] args){
 // System.setSecurityManager(new RMISecurityManager( ));
    try{
       InCoServer inco=new InCoServer();
       Naming.rebind("InCoServer",inco);
       }
       catch(Exception e){
       System.out.println
       ("Exception: instantiating & binding the remote");
       }
    }
 }
 
 

Notice the Security Manager statement was commented out  Involving the security manager would require setting a 'grant' by  creating a file called 'permit' that would be stored in a Java System  Security directory. The grant might look like the following:               grant{                       permission java.net.SocketPermission "*", "connect";                      permission java.net.SocketPermission "*", "accept";                      permission java.io.FilePermission "/tmp/*", "read";                      };  To use this permission at startup use the command as follows.      java -Djava.security.policy=permit WeatherServer .

The RMI Client

Now a client is created to take advantage of the remote
service. A key aspect of the client code is a 'lookup' to
locate a remote service. We describe this in more detail
in the next session. The client like the other code needs
to be compiled.

RMI Client Code

import java.rmi.*;

public class ExCheckClient{
public static void main(String[] args){
  try{
     Remote remote_object=Naming.lookup("//localhost/InCoServer");
     InCoExchange exchange=(InCoExchange)remote_object;

     double lowest_asking=exchange.lowest_asking( );
     double highest_bid=exchange.highest_bid( );
     System.out.println("The lowest asking price for in-company stock is "
     + "$" + lowest_asking);
     System.out.println("The highest bid for in-company stock is "
     + "$" + highest_bid);
     }
     catch(Exception e){
     System.out.println
     ("Exception: looking up and accessing the remote");
     }
   }
 }

The client and the server now both need to be compiled
just as any other Java source code.

// Compile client and server
 

The RMI Compiler

Having compiled the implementation class with the 'javac'
compiler, the RMI compiler, 'rmic', is then used to generate
the stub* class. The tool is run against the name of the
compiled implementation class as is shown in the following
example.
 
// * and skeleton using older JDKs

The RMI Compiler Example

 C:\> rmic  InCoServer    

// run rmic after compiling implementation class, InCServer

After running the RMI compiler a check of the directory
will show the following stub class will have been
generated.
 

Stub & Skeleton Examples

InCoServer_Stub.class
// InCoServer_Skel.class

// earlier versions would also have shown a Skeleton
// class like that which is commented out above

You do not have to process the Client with the rmic
compiler. Notice though, it is your client that needs
the stub to serve as a proxy for the RMI remote
server. 

The RMI Registry

The 'lookup' details in the client is related to a third
party in the RMI architecture. RMI like CORBA uses
a name service to locate RMI remote services. RMI
can work with JNDI, the Java Naming & Directory
Interface we mentioned in JDBC. It also supplies a
light weight registry called the RMI registry. This
registry needs to run in it's own process.

c:\> rmiregistry

/ running on it's default port, 1099

Running the RMI System

This bring us to the point where we can run the system
locally on a single machine that is being used to develop
this code. If using Windows three DOS sessions are
needed. The first DOS session is used to start the
naming registry.

Example 

C:\> rmiregistry

In another DOS window go to the directory you have
been using and start the Server as in the following.

Example 

C:\> java InCoServer

Finally the Client can be run in it's separate console
window.

Example 

java ExCheckClient

If everything works properly, the result should be
returned as follows on the client.

Example of Client Output

C:\> The lowest asking price for in-company stock is $9.5
        The highest bid for in-company stock is $7.5
 

We will continue in the next note on RMI with a more
detailed look at the process and other practical
considerations.

1) Which of the following is not an advantage conferred by distributed computing?

a) scalability
b) single contact point for multiple services
c) providing increased security for individual stations
d) expanded geographic reach

2) Which of the following is not rendered as a Java Middleware API?

a) RPC
b) CORBA
d) RMI
e) EJBs

3) Given the organizations the following organizations associate each by
letter a,b or c with the technologies that follow.

a) OMG
b) Sun
c) The Open Group

a) DCE  ______
b) RPC  ______
c) UML ______

Which of the following is a difference between RMI and CORBA.

4) What does RMI and CORBA not have in common?

a) architecture specific compilers
b) language specificity
c) encapsulated and hidden sockets
d) means of specifying and calling remote operations.

5) What do JRMP and IIOP have in common?

a) RMI
b) CORBA
c) TCP/IP
d) Java

6) In an RMI system, which of the following is responsible for marshalling
parameters from the client / server software?

a) Stub & Skeleton Layer
b) The Remote Reference Layer
c) The Transport Layer
d) The Physical Layer
 

Do A or B.

A

1) Cut, paste and compile the above code examples
and run the RMI application across three terminals
on your computer. Submit screen shots to show the
code ran.

2) Add an averageBid( ) method to the Remote interface
Definition that takes the asking amount and averages
it with the highest bid.  You will need to supply an
implementation of this method in the Server which
is supplying the remote services. Then modify your
client so that it calls the averageBid( ) method.

Using the formula described above compile the
code each in separate source files, use rmic on
the Server code to generate a stub class and run.

Recall you need to run the RMI naming registry
first before running the Server. After the server
is running run the client.

OR

2) By simply extending the formulas provided, create and
compile an RMI interface that contains three methods that
describe three services based on RMI. Dovetail these
services to be something we could apply to our Projects.
For instance, RMI would be good for an in-house information
system.

a) Employee Info Service   a) get Taxes paid for a given year
                                         b) get Sick Days for a given year
                                         c) get Number of hours overtime for a year.

// or

b) Re: Products                   a) Get the best selling product
                                          b) Get prices for a product
                                          c) Get new products list    

// could do against database

// or

c)  Any other idea that would fit. In a genero service, methods
RMIService1, RMIService2, etc would be fine too. 
 

Do not worry about algorithms. Simply return String values. We
are most interested in demonstrating how the RMI system works
and how easily it can be adapted to do work for us.