The following are implementations of Distributed Object Systems (DOS):
- Java RMI, CORBA, and DCOM.
- Sockets, RMI, CORBA.
- HTTP, FTP, SMTP
- None of these choices is an implementation of a DOS.
- C++, Java.
Well, DCOM likes to call itself a component object model, but it is also a DOS.
The primary goal of a Distributed Object System is to:
- Enable the invocation of methods on objects that are hosted by a different machine.
- Enable the construction of objects whose parts can then be distributed among different machines.
- Enable to contruction of an object that can move between machines.
- Enable the construction of compilers that can be run on various platforms.
- Enable the implementation of objects using different machines.
Which one of the following is not a feature of a Distributed Object System.
- There is no need to set up server processes.
- The ability to easily distribute applications among machines.
- There is no need to define a new interaction protocol.
- There is no need to deal with data conversion.
- It is easy to manage how the application is distributed.
Distributed objects are always served by a server.
In a Distributed Object System the object to be distributed has
to be split into two parts: the stub and the skeleton. These two
parts:
- Are automatically generated from the interface definition and remote implementation.
- Are generated by the software engineer to handle the the remote object invocations.
- Are placed on the Registry.
- Are executed on the server machine.
- Are executed on the client machine.
It would be a pain to have to generate those two by hand!
In a Distributed Object System the Registry is used for:
- Locating the machine that serves a particular object.
- Locating a remote interface.
- Locating an instance of a remote object.
- Controling the number of existing instances of an object.
- Forwarding messages from the stub to the skeleton, and viz.
In Java RMI the registry is called
- Only to register an object server, and to find an object server.
- On each call to a member function of a remote object.
- Only when a new object server is started.
- Whenever a new object instance is created.
- Only when the client is started.
Whenever a new object instance is created. is wrong because the object could be non-remote.
In a Distributed Object System each call to a member function of
a remore object instance is sent to the object server as a
message containing (pick best):
- The ID of the actual instance, the method ID, and the parameter values.
- The code for the method instance and the parameter values.
- The parameter values.
- The class name and the parameter values.
- A magic string and the parameter values.
Generally, all that information needs to be there. In RMI
the code can later be retrieved because the instance also contains
a URL to the codebase.
The following code:
public interface Hello extends Remote {
String sayHello() throws RemoteException;
}
- Is a correct declaration of a remote interface.
- Is a correct implementation of a class that implements a remote interface.
- Is incorrect because you cannot extend
Remote
.
- Is incorrect because the method throws
RemoteException
.
- Is incorrent because it does not define a constructor.
It is an interface declaration, not a class that implements the interface.
In Java, objects are passed (when used as arguments to a member
function of a non-remote object) as:
- pass-by-reference
- pass-by-value
- It depends on whether it is a remote, or a non-remote object.
- It depends on whether the object is a primitive data type or not.
- Pointers to the objects are passed-by-value.
They are non-remote!
In Java, objects are passed (when used as arguments to a member
function of a remote object) as:
- It depends on whether the object is remote, or non-remote.
- pass-by-value
- It depends on whether it is a primitive data type or an Object.
- pass-by-reference
- Pointers to the objects are passed-by-value.
They are remote!
If you could see inside an instance of a Java object (as you
can, when you serialize it to the screen), you would see references to:
- The variable values, the class name, and the codebase URL.
- The variable values, the function definitions, the class name, and the codebase URL.
- The variable and function names.
- The variable values.
- The codebase URL.
A Java class that implements a remote object must (pick best):
implements
a remote interface and
extends
either Activatable
or
UnicastRemoteObject
.
implements
either Activatable
or UnicastRemoteObject
.
extends
a remote interface.
extends RMIRemoteObject
.
implements RMIRemoteObject
There is no such thing as RMIRemoteObject
.
In a remote object implementation that uses
UnicastRemoteObject
, the object server starts serving objects:
- When the
UnicastRemoteObject
constructor is called.
- When the
start
method is called.
- When the object is bound to the registry.
- When the program starts to run.
- When a call is made by a client that wants a new instance or the remote object.
The binding to the registry of a remote object RemoteObject
:
- Can be done by any program with access to the
RemoteObject
.
- Needs to be done by the
main
in RemoteObject
.
- Should only be done when the registry runs on a different
machine from
RemoteObject
.
- Requires
RemoteObject
to implement the UnicastRemoteObject
interface.
- Is not safe under Java 2.
Given that the following function is a member function of a remote interface:
void foo (MyClass argument)
and MyClass
is non-remote, then:
MyClass
must implement the serializable interface.
-
argument
will be sent call-by-reference.
-
MyClass
must be defined in the server machine.
-
MyClass
must be a remote class (i.e., trick question).
-
foo
will send the stub of argument
.
The following code is (assume the ... are replaced by the appropiate code):
public interface Hello extends Remote {
String sayHello() throws RemoteException;
}
public class HelloImpl extends UnicastRemoteObject
implements Hello {
public HelloImpl() throws RemoteException { ...};
public String sayHello() { ... }
private String sayGoodbye(){ ... };
}
- Correct.
- Incorrect because
sayGoodbye
is not on the interface.
- Incorrect because
HelloImpl
should not implement Hello
.
- Incorrect because
sayGoodbye
does not throw RemoteException
.
- Incorrect because
String
is non-remote.
What is the effect of the following code:
HelloImpl obj = new HelloImpl();
Naming.rebind("HelloServer", obj);
- To send an instance of the stub of
obj
to the registry and
bind it to the name "HelloServer"
- To send an instance of
obj
to the registry and
bind it to the name "HelloServer"
- To send an instance of the skeleton of
obj
to the registry and
bind it to the name "HelloServer"
- To send a copy of the class of
obj
to the registry and
bind it to the name "HelloServer"
- To send a copy of the class of
obj
, and its
skeleton, to the registry and bind it to the name
"HelloServer"
Which one of the following is not true.
- An application can bind/unbind to a registry running on any machine.
- A remote object server can run on any machine with a JVM.
- An application can do a lookup on a registry running on any machine.
- A remote object implementation can implement many remote object interfaces.
- A remote interface must implement
Remote
.
The steps to get an RMI system running are:
-
- Compile with javac.
- Compile with rmic.
- Run rmiregistry.
- Run object server.
-
- Compile with javac.
- Run rmiregistry.
- Run object server.
- Compile with rmic.
-
- Compile with javac and "-rmic" option.
- Run rmiregistry.
- Run object server.
-
- Compile remote interface.
- Compile implementation.
- Run rmiregistry.
- Run object server.
-
- Compile remote implementation.
- Compile remote object
- Run rmiregistry.
- Run object server.
Oh, and saying a little prayer never hurts.
The codebase property value contains:
- A list of URLs.
- A list of filenames.
- A list of classnames.
- A list of remote interfaces.
- A list of object implementations.
The codebase is (pick best):
- The place where a remote process can find the .class files for local objects.
- The place where the compiler can find the imported libraries.
- The place where the remote interfaces are placed.
- The place where the .class files are placed after a compilation.
- The machine where the object server runs.
When a client does a succesfull lookup on the registry for some remote object, it ends up with:
- An instance of the stub of the remote object.
- The stub of the remote object and its class definition.
- An instance of the skeleton of the remote object.
- A copy of the remote object.
- A local reference to the remote object.
The registry only returns an instance, the actual classes
are fetched later when the client calls a method on the
object. They are fetched using the codebase that was annotated on
the stub instance.
The following code is incorrect because:
public interface Hello extends Remote {
String sayHello(HelloImpl a, int x) throws RemoteException;
}
public class HelloImpl extends UnicastRemoteObject
implements Hello {
public HelloImpl() throws RemoteException { ...};
public String sayHello(HelloImpl a, int x) { ... }
}
- The argument
a
should be of type Hello
- It is correct.
- Primitive data types are not allowed as arguments.
- The constructor is not defined on the interface.
- The
HelloImpl
should extend Hello
.
You might want to implement your own RMI Socket Factory if you:
- Want RMI calls to go thru an encrypted socket.
- Want RMI to use sockets instead of its own communications classes.
- Want to control the number of sockets RMI creates.
- Want to extend RMI to handle asynchronous calls.
- Want to extend RMI to handle communications with other systems.
Once you have defined your RMIClientSocketFactory
and RMIServerSocketFactory
, you
can make your UnicastRemoteObject
server use them by:
- Given them as parameters to the
UnicastRemoteObject
constructor.
- Registering them with the rmiregistry.
- Calling the
setFactory
method.
- Compiling them.
- Registering them with
rmid
.
An Activatable
object is a remote object:
- That does not need an object server to be running all the time.
- Whose object server goes to sleep in between client calls, but continues to run.
- That can sometimes act as a non-remote object.
- That needs to be activated by hand each time the server runs.
- That can register itself many times with the rmiregistry.
The rmid
is a program that:
- Starts
Activatable
objects when they are called.
- Registers new
Activatable
objects with the rmiregistry.
- Handles stub and skeleton communications.
- Compiles interfaces and implementations into stubs and skeletons.
- Checks for errors in the generated stubs and skeletons.
In terms of using it as an enterprise solution, the main disadvantage of RMI is:
- That all objects need to be written in Java.
- That it is not object-oriented.
- That it does not provide facilities for code migration.
- That it does not provide security mechanisms.
- That it does not provide distributed garbage collection.
Ok, this is not completely true because of RMI over IIOP, but its the best choice.
The RMI class hierarchy is:
- Activatable and UnicastRemoteObject extend RemoteServer which extends RemoteObject which implements Remote interface
- Activatable and UnicastRemoteObject extend RemoteObject which implements Remote interface.
- RemoteObject extends Activatable which extends UnicastRemoteObject which extends RemoteObject which implements Remote interface.
- Activatable and UnicastRemoteObject implement Remote interface.
- Activatable and UnicastRemoteObject extend Remote which implements RemoteObject interface.
Which of the following choices is something that an RMI remote interface does not need to do?
- Declare the interface as public.
- Extend
Remote
, directly or indirectly.
- Each method must throw a
RemoreException
, or higher.
- Every argument that is a remote object must be declared with the remote interface type.
- Import java.rmi.Remote.
If you declare it as private then only other classes within the package can use it, but that might be OK with you, right?
In RMI, when can a remote interface extend a non-remote interface?
- When all of the non-remote interface methods satisfy the requirements for a remote interface.
- It cannot extend a non-remote interface.
- When the non-remote interface implements
Serializable
.
- When the non-remote interface extends
RemoteException
.
- When the remote interface is
Activatable
.
Yup, thats it.
A RemoteException
is thrown by an RMI invocation when:
- There is a communication, marshaling, or protocol error.
- The remote object cannot be found in the rmiregistry.
- The remote interface implementation failed to completely implement the remote interface.
- One of the arguments is a non-serializable non-remote object.
- One of the arguments is a remote object.
The RemoteObject
extends Object
and implements (overrides) which methods?
- hashCode, equals, and toString.
- None.
- The constructors.
-
RemoteObject
does not extend Object
.
- All methods defined in the remote interface.
Say your RMI client has a reference to a remote object which
extends UnicastRemoteObject
. Then, the server for
that object dies but is quickly restarted. If you were to invoke
a method call on that object, what would happen?
- You would get an exception since the object is no longer valid.
- Everything would work fine.
- The call would be made but it might never return.
- It would return some unpredictable value.
- It depends on whether rmid was running or not.
Which one of the following statements is not true. An implementation of a remote interface can:
- Implement any given non-remote interface.
- Extend
UnicastRemoteObject
or Activatable
.
- Implement any number of remote interfaces.
- Define methods that do not throw
RemoteException
- Throw
Exception
instead of RemoteException
Because, that interface might have methods that do not conform.
Your boss asks you to build a system that will allow people on
their workstations to do their heavy computing work on the
supercomputer. You decide to use RMI and implement remote
object. Your deployment will look like:
- The supercomputer runs the object server and rmiregistry, the workstations are the clients.
- The supercomputer runs the client, while the workstations run the object servers and rmiregistry.
- The supercomputer run the object server, while the workstations run the clients and rmiregistry.
- There is not way to do this with RMI.
- The object server code can migrate from the worksations to the supercomputer, which runs the rmiregistry.
In RMI, if you want to automatically migrate compiled code
(i.e., .class) for class Foo
from machine A to
machine B, you make this migration happen by:
- A passes an argument of type
Foo
to a method of a remote object that runs on B.
- A sets its codebase to point to where the compiled code is located.
- A defines remote object class which extends
Foo
, which B then uses.
- B sets its codebase to point to where the
Foo
classes are defined.
- This cannot be done in RMI.
That is, assuming you set the proper codebase.
When an RMI client invokes a method on a remote object:
- It blocks until the remote object server returns from the invocation.
- The stub sends the message and the program continues. When the reply arrives it is updated.
- It calls the rmiregistry to find where the object is located.
- It downloads the .class files from the codebase.
- It defines a new interface.
It defines a new interface. How the heck could that happen! Im tired.
If you were to deploy an RMI system in a company with thousands of PCs, which one of the following is not
an advantage of your RMI system.
- The increased parallelism it provides.
- The code-migration abilities.
- It is easier to use because it is all object-oriented.
- It can be deployed on many different architectures (i.e., operating systems).
- The added security.
Oh, and it can alter the space-time continoum.
The RMISecurityManager
:
- Reads a policy file.
- Prevents programs from doing nasty things.
- Is only needed for applets.
- Runs in the background.
- Is used only by the object server.
Nope, the JVM does the preventing, the RMSecurityManager
only gives the rules.