Role of RMI Skeleton class

Every text book I read states the following:

    remote object's skeleton class should be with the server
    remote object's stub class should be with the client

But, my testing with JDK 1.2  tells me:

    remote object's skeleton class has no use
    remote object's stub class should be present in both of the
           server side and the client side

********************************************
Would somebody enlighten me by pointing out
where I messed 'em up?
Thank you.
********************************************

I think any example will prove my point, but here is
sample Java files: Hello.java HelloClient.java HelloImpl.java

// *************
// Hello.java
// *************

package hello;

import java.rmi.*;

public interface Hello extends Remote {

        public String sayHello() throws java.rmi.RemoteException;

}



// ****************
// HelloClient.java
// ****************

package hello;

import java.rmi.*;

public class HelloClient {

        public static void main(String[] args) {
       
                System.setSecurityManager(new RMISecurityManager());

                try {
                        Hello h = (Hello) Naming.lookup("rmi://mycom.soongsil.ac.kr/hello");

                        String message = h.sayHello();
                        System.out.println("HelloClient: " +message);
                } catch(Exception e) {
                        System.out.println("Exception in main: "+ e);
                }
        }
}


// ****************
// HelloImpl.java
// ****************

package hello;

import java.rmi.*;
import java.rmi.server.*;
import java.net.*;

public class HelloImpl extends UnicastRemoteObject implements Hello {

        public HelloImpl() throws RemoteException {
                super();
        }

        public String sayHello() throws RemoteException {

                return "Hello World";
        }

        public static void main(String[] args) {
                System.setSecurityManager(new RMISecurityManager());

                try {
                        HelloImpl h = new HelloImpl();
                        Naming.rebind("//localhost/hello", h);
                        System.out.println("Hello Server ready");
                } catch (RemoteException re) {
                        System.out.println("Exception in HelloImpl.main: " + re);
                } catch (MalformedURLException mfe) {
                        System.out.println("MalformedURLException in HelloImpl.main" + mfe);
                }
        }
}

gsrhee1Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sgomsCommented:
"RMI treats a remote object differently from a nonremote object when the object is passed from one
          virtual machine to another. Rather than making a copy of the implementation object in the receiving
          virtual machine, RMI passes a remote stub for a remote object. The stub acts as the local
          representative, or proxy, for the remote object and basically is, to the caller, the remote reference.
          The caller invokes a method on the local stub, which is responsible for carrying out the method call
          on the remote object.

          A stub for a remote object implements the same set of remote interfaces that the remote object
          implements. This allows a stub to be cast to any of the interfaces that the remote object implements.
          However, this also means that only those methods defined in a remote interface are available to be
          called in the receiving virtual machine. "

check out,
http://www.rmi.net/home/support/tutorials.shtml
http://java.sun.com/docs/books/tutorial/rmi/overview.html
for further info.

-sgoms
0
gsrhee1Author Commented:
Thank you for your answer, but you didn't explain

(1) the exact role of the skeleton class

(2) why every authors state that the server side
     requires just the skeleton class, not mentioning
     the stub class. Most books even have diagrams
     like

     client --> stub ---|-----> skeleton --> server

0
sgomsCommented:
"RMI applications are often comprised of two separate programs: a server and a client. A typical server application creates some remote objects, makes references to them accessible, and waits for clients to invoke methods on these remote objects. A typical client application gets a remote reference to one or more remote objects in the server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application. "

so basically ur client creates a stub of the remote method & works on it, while ur server has implements the remote object.
___________________________________________________________
RMI uses a standard mechanism (employed in RPC systems) for communicating with remote objects: stubs and skeletons. A stub for a remote object acts as a client's local representative or proxy for the remote object. The caller invokes a method on the local stub which is reponsible for carrying out the method call on the remote object. In RMI, a stub for a remote object implements the same set of remote interfaces that a remote object implements.

When a stub's method is invoked, it does the following:
      1.initiates a connection with the remote VM containing the       remote object.
      2.marshals (writes and transmits) the parameters to the remote VM
      3.waits for the result of the method invocation
      4.unmarshals (reads) the return value or exception returned
      5.returns the value to the caller

The stub hides the serialization of parameters and the nettwork-level communication in order to present a simple invocation mechanism to the caller.

     In the remote VM, each remote object may have a corresponding skeleton (in JDK1.2-only environments,
     skeletons are not required). The skeleton is responsible for dispatching the call to the actual remote object implementation. When a skeleton receives an incoming method invocation it does the following:

1.unmarshals (reads) the parameters for the remote method
2 invokes the method on the actual remote object implementation
3.marshals (writes and transmits) the result (return value or exception) to the caller
____________________________________________________________

so do u undrestand why client intercats with stub & server with thhe skeleton?

-sgoms
0
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

gsrhee1Author Commented:
Thank you for your answer, but you didn't explain

(1) the exact role of the skeleton class

(2) why every authors state that the server side
     requires just the skeleton class, not mentioning
     the stub class. Most books even have diagrams
     like

     client --> stub ---|-----> skeleton --> server

0
sgomsCommented:
still not clear? why did u post ur comment twice?


-sgoms
0
gsrhee1Author Commented:
Thanks again, but something is still missing.

(1) You pointed out that in JDK1.2-only environments,
                                      skeletons are not required.
     Then who handles the chores for which the skeletons
     are responsible?

(2) The server side seems to require the stub class.
     What does the stub class do in the server side?
0
JodCommented:
In JDK1.2 and additional stub protocol was introduced that eliminates the need for skeletons in JDK1.2-only environments. Instead, generic code is used to carry out the duties performed by skeletons in JDK1.1.

In other words, skeleton "chores" are now built into the generic Java runtime.

A stub is a proxy for a remote object which is responsible for forwarding method invocations on remote objects to the server where the actual remote object implementation resides. A client's reference to a remote object, therefore, is actually a reference to a local stub. The stub implements only the remote interfaces, not any local interfaces that the remote object also implements.

The RMIREGISTRY and the client require that the stub be present on the server for binding purposes. Also note, that when passing a remote object as a parameter, the stub for the remote object is passed.

Also, The RMIClassLoader is used to load those classes not directly used by the client or server application: the stubs and skeletons of remote objects, and extended classes of arguments and return values to RMI calls.

The RMIClassLoader looks for these classes in the following locations, in the order listed:

a. The local CLASSPATH. Classes are always loaded locally if they exist locally.

b. For objects (both remote and nonremote) passed as parameters or return values, the URL encoded in the marshal stream that contains the serialized object is used to locate the class for the object.

c. For stubs and skeletons of remote objects created in the local virtual machine, the URL specified by the local java.rmi.server.codebase property is used.


Another example is the typical closed-system scenario where the server configured to load no classes. The services it provides are defined by remote interfaces that are all local to the server machine. The server has no security manager and will not load classes even if clients send along the URL. If clients send remote objects for which the server does not have stub classes, those method invocations will fail when the request is unmarshaled, and the client will receive an exception.

Finally, server processes must declare to the RMI runtime the location of the classes (stubs and parameters/returns) that will be available to its clients. The java.rmi.server.codebase property should be a URL from which stub classes and classes used by stubs will be loaded, using the normal protocols, such as http and ftp.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gsrhee1Author Commented:
Thank you for the answer.
Is there any online resource for that kind of detailed information about RMI? If you have any info, please send me an e-mail. (rhee@sookmyung.ac.kr)
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.