Elements of Advanced JAVA Programming : Part-2

Distributed Computing:

• There are JAVA technologies available for creating distributed computing environment. Two popular technologies are the remote method invocation (RMI) and the common object request broker architecture (CORBA).
• RMI analogous to the remote procedure call (RPC) and is preferred by programmers of the JAVA programming language.
• The CORBA does provide flexibility in heterogeneous development environments.
• The RMI featuresdo enable a program running on a client computer to make method call on an object located on a remote server machine.
• It gives a programmer the ability to distribute computing across a networked environment. An Object Oriented design does require that every task be executed by the object most appropriate to that task.
• The RMI does take this concept one step further by allowing a task to be performed on the machine most appropriate to the task.
• RMI defines a set of interfaces that you can use to create a remote object.The client can invoke a method of a remote object with the same syntax that it uses to invoke methods on a local object.
• The RMI API provides classes that handle all of the underlying communication and parameter referencing requirements of accessing remote methods.
• With all of distributed computing architectures, an application process or object server (daemon) advertises itself to the world by registering with a naming service on the local machine (node).
• In the case of the RMI, a naming service daemon called the RMI registry  runs over an RMI port that by default listens over IP Port 1099 on that host.
• The RMI registry contains an internal table of remote  object references. For each remote object, a table does contain a registry name and a reference to that object.
• You can store multiple instances for the same object by instantiating and binding it multiple times to the registry, s=using different names.

Remote Method Invocation (RMI):

• When an RMI client binds a remote object through the registry, it receives a local reference to the remote instantiated object through its interface and communicates with the object through that reference.
• Local references to the same remote object can exist on multiple clients; any variables and methods contained within the remote object are shared.
• The applet begins by importing the appropriate RMI packages and creating a reference to the remote object. After the applet does establish this link, it can call the remote object’s method as if they were locally available to the applet.

RMI Architecture:

• The RMI architecture provides three layers: Transport layer, Remote Reference layer, and Stubs/Skeleton layer.
• The figure given below shows those layers:

• The Transport layer creates and maintains physical connections between the client and server. It does handle the data stream passing through the Remote/Reference layers (RRLs) on the client and server side.
• The Remote reference layer provides an independent reference protocol for establishing a virtual network between the client and server.
• It establishes interfaces to the lower Transport layer and the upper Stub/Skeleton layer.
• A Stub is a client side proxy representing the remote object. The client interacts with the stub through interfaces.
• The stub appears as a local object to the client.The Skeleton on the server side acts as an interface between the RRL and the object implemented on the server side.

Creating an RMI Application:

This guides you through the steps for creating, compiling, and running the RMI application. The following steps illustrate the process:

1. Define interfaces for remote classes.
2. Create and compile implementation classes for the remote classes.
3. Create Stub and Skeleton classes using rmic command.
4. Create and compile the server application.
5. Start the RMI registry and the server application.
6. Create and compile a client program to access the remote objects.
7. Test the client.

Common Object Request Broker Architecture (CORBA):

• CORBA is a specification that defines how distributed objects can interpolate. The CORBA specification is controlled by the Object Management Group (OMG), an open consortium of more than 700 companies that work together to define open standards for distributed computing.
• You can write CORBA objects in almost any programming language, including C and C++. Those objects can also exist on almost any platform, including the Microsoft Windows,Solaris OS, Digital Unix,open VMS, HP-UX, and many others.
• This means JAVA application running on a Microsoft Windows platform can interact over a network with C++ objects on a UNIX system.
• The Language independence is possible using the construction of interfaces to objects using the Interface Definition Language (IDL).
• The IDL does allow all CORBA objects to be described in the same manner; the only requirement is a bridge between the native language (C/C++, COBOL,JAVA) and IDL.
• At the core of CORBA is the Object Request Broker(ORB). The ORB is the principle component for the transmission of information between the client and the server of the CORBA application.
• The ORB does manage marshaling requests, does establish a connection to the server, does send the data, and executes the requests on the server side. The same process does occur when the server does want to return the results of the operation.
• ORB’s from different vendors communicate over a network (often, but not necessarily using TCP/IP) using the Internet Inter-ORB Protocol (IIOP), which is a part of the CORBA 2.0 standard.

Thy JAVA IDL:

• The JAVA IDL does add CORBA capability to the JAVA programming language, providing standards based Interpol arability and connectivity.
• The JAVA IDL does enable distributed JAVA applications to transparently invoke operations on remote network services, using the industry standard IDL and IIOP.
• JAVA IDL is not an implementation of OMG’s IDL. It is, in fact, the  CORBA ORB that does usethe IDL to define interfaces.
• The idltojava compiler generates portable client stubs and server skeleton.The CORBA client interacts with another object running on a remote server by accessing a reference object through its naming service.
• Like the RMI registry, the naming service is an application that runs as a background process on a remote server.  It holds a table of named services and remote object references used to resolve client requests.

The steps involved in setting up the CORBA object can be summarized as follows:

1. Create the object’s interface using the IDL.
2. Convert the interface into the Stub and skeleton objects using the javatoidl compiler.
3. Implement the skeleton object, and  creating the CORBA server object.
4. Compiler and executer the server object, andbinding it to the naming service.
5. Create and compile a client object, which invokes the methods within the server object.
6. Execute the client object, accessing the server object through the CORBA naming service.

RMI Compared with CORBA:

• RMI’s biggest advantage stems from the fact that it fully object oriented. By contrast, CORBA provides a largely procedural mechanism for connecting distributed objects.
• Consider the command pattern. This pattern provides excellent flexibility and maintainability, but it cannot be implemented properly between two CORBA systems because it requires that objects (both state and behavior)be moved from the client to the server.
• RMI can do this as a direct consequence of the platform independent bytecode.
• One of the key benefit often cited for CORBA is its language independence. In fact, RMI can provide this too by using the JAVA Native interface.
• CORBA services are available for a significant variety of both vertical and horizontal problems, these services are often well understood and mature.The Examples of potentially important features of services are transactions and security.
• CORBA’s language independence adds significant complexity to the development cycle and precludes garbage collection features that RMI supports.
• In many cases, the choice between the RMI and the CORBA is most likely to be made largely on political and environmental grounds, rather than on purely technical ones.
• A company that already has CORBA would need a compelling reason to introduce a new technology, especially if the change would render a substantial investment in services redundant.
• The new systems, however, are likely to benefit from the use of RMI, provided that higher management do not perceive this as an immature technology.