Unit 7 Flashcards
What is similar and what is different between the implementation of remote method calls and remote procedure calls as presented in Unit 5, Subsection 7.1?
Both remote method calls and RPC are blocking forms of communication:
the caller cannot proceed with its execution until the called method or procedure has returned.
Moreover, as with RPC, the method call has to go through various layers that abstract away data marshalling and the low-level network protocols.
For example, the runtime support layer in Figure1 corresponds to the RPC service layer. The discussion on what can go wrong in an RPC call(e.g. network disruption) also applies in the distributed object context and has therefore been omitted from the presentation above.
What are a remote object, a remote interface and a remote method? How can they be detected in the server-side code?
A remote object is an instance of a class that implements at least one remote interface.
A remote interface is an interface that declares one or more remote methods.
A remote method is a method that can be called from another JVM.
In the code one has to look for the following:
- a remote interface extends Remote,
- a remote method throws a RemoteException
- a remote object’s class usually extends UnicastRemoteObject.
We have previously said that the default registry implementation provided by the Java library requires the registry to run on the same host as the server application. Does this contradict the above sentence stating that the registry’s services are remote methods?
There is no contradiction: remote methods may be called from a different JVM not necessarily from a different host.
To simplify the presentation of RMI, in this course we create the registry from within the server application, but there are ways to have the registry run on its own JVM.
how the registry must be set up;
Summarise the steps that are taken by the programmer and the runtime infrastructure to set up a remote object and then call a method on it. Take serialisation, threading and security issues into account. In particular, explain:
A registry service is started on a port known to the client and server applications.
The service may runin its own JVM but,for security reasons, it must be on the same host as the server application.
how the server makes the remote object available to clients and the purpose of proxies;
Summarise the steps that are taken by the programmer and the runtime infrastructure to set up a remote object and then call a method on it. Take serialisation, threading and security issues into account. In particular, explain:
The server application creates a remote object and exports it, so that it is ready to receive incoming calls.
The server application then asks the registry to bind (i.e. associate) a unique symbolic name to a remote reference, i.e. a reference to the remote object.
The symbolic name is given by the server application and is somehow (e.g. on a public website) made known to the clients.
The remote reference is a stub object, i.e. a proxy that acts as a representative of the remote object.
The stub object implements the same interfaces as the remote object, but the implementation of each method just forwards the call and the arguments to the remote object.
how the client obtains a reference to the remote object;
Summarise the steps that are taken by the programmer and the runtime infrastructure to set up a remote object and then call a method on it. Take serialisation, threading and security issues into account. In particular, explain:
When the client wishes to make the remote call, it looks up the name in the registry.
The registry returns (using serialisation) a copy of the stub object. The client now has a local reference to a stub object residing on the same JVM heap.
how a call to a remote object method is executed;
Summarise the steps that are taken by the programmer and the runtime infrastructure to set up a remote object and then call a method on it. Take serialisation, threading and security issues into account. In particular, explain:
The client makes a normal call to a method of the stub object, passing other objects or primitive data as arguments. The client thread executing the call then blocks, as it cannot continue until the call completes.
The runtime support layer serialises the object arguments and uses the network support layer to send everything to the server.
On the server JVM, the network and runtime support layers reverse the process, unmarshalling the arguments and making a local call to the corresponding method of the remote object.
The return value or exception object is serialised and then passed back to the caller, which resumes execution.
how and why security managers are used.
Summarise the steps that are taken by the programmer and the runtime infrastructure to set up a remote object and then call a method on it. Take serialisation, threading and security issues into account. In particular, explain:
If a JVM receives a serialised object of an unknown class (i.e. a class that is not on the JVM’s class path), it must use a security manager to check whether the user-defined security policy allows downloading and executing of the code from the location given in the java.rmi.server.codebase property set by the JVM that sent the object.
Describe, in the correct sequence, the main steps in developing a simple client–server application using RMI. Identify in each step the interfaces or classes to be extended, the methods to be called, and, if applicable, the exceptions to be raised.
1 Write a remote interface, extending Remote, that declares the methods the client may call. Each method may throw a RemoteException.
2 Write a remote class that extends UnicastRemoteObject and implements the remote interface written in step 1. Remember that the methods may need to be synchronised. Furthermore, all the class constructors must eventually call the UnicastRemoteObject constructor, which can throw a RemoteException.
3 Write the rest of the server-sidecode. It must at some point in time (usually in main):
(a) make sure that a security manager(e.g. RMISecurityManager)is in place if new classes have to be loaded at runtime(due to the arguments passed to remote methods);
(b) create a registry by calling LocateRegistry.createRegistry;
(c) create a remote object, i.e. an instance of the class defined in step 2;
(d) bind the remote object to a fixed name in the registry, by calling the bind or rebind method on the registry obtained in step 3(b).
4 Write the client-side code. It must at some point in time(usually in main):
(a) make sure that a security manager(e.g. RMISecurityManager)is in place if new classes havetobe loaded at runtime(duetothereturn valuesoftheremote methods);
(b) obtain a reference to the registry by calling Locateregistry.getRegistry;
(c) call lookup on the registry obtained in step 4(b), with the name set in step 3(d), in order to get a reference to the remote object;
(d) call the methods on the remote object.
5 Define any necessary and appropriate security policies for the client and the server (this will be discussed in Unit 10).
6 Start the server JVM and one JVM per client. Set for each JVM the java.rmi.server.codebase property with the location of the classes of the objects that the JVM sends to other JVMs.
Note that it is possible to start the registry in a separate JVM and then use getRegistry in step 3(b) in the same way as in step 4(b).
Summarise how entity classes are related to the relational schema and how they are defined.
An entity class corresponds to a table, each instance of it to a record in the table and each column to an instance variable.
To define an entity class for table T1, declare one private instance variable per column and access it through a pair of setter and getter methods.
If a column is a foreign key to table T2, the corresponding variable is typed by the class corresponding to T2.
If T1 has a one-to-many relationship to T2, then the class may have an additional instance variable holding a collection of instances of the class corresponding to T2.
Explain whether the following declaration is correct or not.
@Column(name = “MODEL_ID”)
private InstrumentModel model;
It is incorrect because the annotation and the type of model are incompatible.
The @Column annotation implies that model must hold the string contained in the MODEL_ID column, while the InstrumentModel type implies that model must hold the record (i.e. entity) referred to by the MODEL_ID column.
In other words, the annotation indicates that the MODEL_ID column should be interpreted as a normal string, while the type indicates that it should be interpreted as a key.
What is the rationale for using a pool of stateless beans? You may wish to remind yourself of the thread pools discussed in Unit 4, Subsection 3.6.
The rationale for using pools of resources is always the same: performance.
Requests can be serviced faster by an already available and reusable resource, instead of creating a new one when the request arrives and then garbage collecting it after the request terminates.
What do the terms remote access and local access mean?
If access is remote, client and bean are executing on different JVMs;
if access is local, they are executing within the same JVM.
In this unit we assume that the client is a separate application – web clients are covered in the next unit. How will session beans be annotated?
They will be annotated with @Remote, because separate client applications do not run on the same JVM as the server, as stated under the ‘Client type’ bullet item below.
Client type. Bean methods can be called by stand-alone client applications, by web tier components (explained in the next unit) or by other beans. If the client is an independent application, then access must be remote, because separate client and server applications run on separate JVMs. If the client is another bean or a web component, the access mode can be either local or remote.
What are the two kinds of entity manager?
The two kinds of entity manager are:
- application-managed entity managers are explicitly created and closed by the application, and they explicitly start and end transactions;
- container-managed entity managers are implicitly created and closed by the EJB container, and transactions are bydefault implicitly created and committed at method call and return.
