Unit 7 The business tier Flashcards
What is similar and what is different between the implentation of remote method calls and remote procedure calls as presented in Unit 5-7.1?
(Part 2) 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.
Also, 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 of RMI corresponds to the RPC service layer.
The reasons for problems in the calls are also similar.
The main difference is that in RPC a procedure is called directly, while in an object-oriented approach a method is called through a particular object that was created at runtime. The implementation of remote method calls requires a registry and a unique name to look up the object reference.
What are a remote object, a remote interface and a remote method? How can they be detected in the server-side code?
(Part 2) 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, look for the following: a remote interface extends Remote, a remote method throws a RemoteException and a remote object’s class usually extends UnicastRemoteObject.
It was 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?
(Part 2) There is no contradiction remote methods may be called from a JVM not necessarily from a different host. To simplify the presentation of the RMI, this couse has created 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 remot object and then call a method on it. Take serialisation, threading and security issues into account. Explain:
- how the registry must be set up
- how the server makes the remote object available to clients and the purpose of proxies
- how the client obtains a reference to the remote object
- how a call to a remote object method is executed
- how and why security managers are used
(Part 2)
- 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 must be on the same host as the server applicaton
- 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 a unique symbolic name to a remote reference. The symbokic name is given by the server application and is made known to the clients. The remote reference is a stub object, 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 calls/arguments to the remote object.
- 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 in the same JVM heap.
- The client makes a normal call to a method of the stub object, passing other objects or primitives as arguments. The client thread executing the call then blocks. 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 unmarshall the arguments 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 the execution.
- If a JVM receives a serialised object of an unknown class (a class not on the JVMs 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 when applicable, the exceptions to be raised.
(Part 2)
- 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. The methods may need to be synchronised. 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 the code (usually in main)
- 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)
- create a registry by calling LocateRegistry.createRegistry
- create a remote object, i.e. an instance of the class defined in step 2
- 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.2
- Write the client-side code. It must at some point (usually in main)
- 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 remote methods)
- obtain a reference to the registry by calling Locateregistry.getRegistry
- call lookupon the registry obtained in step 4.2 with the name set in step 3.4 in order to get a reference to the remote object
- call the methods on the remote object
- Define any necessary and appropriate security policies for the client and the server (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 it is possible to start the registry in a seperate JVM and then use getRegistry in step 3.2 in the same way as in step 4.2
How are entity classes related to the relational schema and how are they defined?
(Part 4) 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 a 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;*
[The code that this question refers to is pages 34-35 in the Unit]
(Part 4) 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 implied that model must hold the record (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? (This has a similarity with thread pools in Unit 4 Subsection 3.6)
(Part 5) The rationale for using pools of resources is always 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?
(Part 5) If access is remote, client and bean are executing on different JVMs. If access is local, they are executing within the same JVM.
In Unit 7 it is assumed that the client is a seperate application - web clients are covered in the next unit, how will session beans be annotated?
(Part 5) 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 on Page 47.
