M362 - 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 Figure 1 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 and 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.
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) how the registry must be set up;
(b) how the server makes the remote object available to clients and the purpose of proxies;
(c) how the client obtains a reference to the remote object;
(d) how a call to a remote object method is executed;
(e) how and why security managers are used.
(a) A registry service is started on a port known to the client and server applications. The service may run in its own JVM but, for security reasons, it must be on the same host as the server application.
(b) 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.
(c) 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.
(d) 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.
(e) 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.
- Write a remote interface, extending Remote, that declares the methods the client may call. Each method may throw a RemoteException.
- 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.
- Write the rest of the server-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 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). - 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 have to be loaded at runtime (due to the return values of the remote 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. - Define any necessary and appropriate security policies for the client and the server (this will be discussed in Unit 10).
- 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.
What are the two kinds of entity manager?
he 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 by default implicitly created and committed at method call and return.
What are the two kinds of persistence context?
There are two kinds of persistence context:
- extended contexts are created when an entity manager is created (by the application or the container), and cease to exist when the entity manager is closed (by the application or by the container);
- transaction-scoped contexts are created when a transaction starts, and cease when the transaction commits or rolls back.
Which kinds of persistence context can be used with which kinds of entity manager?
Persistence contexts are always extended if the entity managers are application managed, whereas both kinds of context can be used with container-managed entity managers.
At the start of Section 4, we said that using the Java Persistence API promotes a succinct coding style that favours using defaults. Name some of those defaults.
By default, the Java Persistence API assumes that:
1 a table has the same name as the entity class, and the columns have the same names as the instance variables;
2 persistence contexts are transaction scoped when using container-managed entity managers;
3 when using container-managed entity managers, each method executes within the current transaction, or else starts a new transaction and commits it when the method terminates.
Summarise the rationale for using transfer objects.
Transfer objects aggregate data according to the client’s view, thereby shielding entities from clients. Transfer objects simplify business interfaces and reduce network load, by reducing the number of methods and calls necessary to transfer data between clients and session beans.
