Learning objective: This set of exercises will introduce you to dynamic invocations, how they are used, and what their performance is like.

Communication scenario description (the same as for assignment 1):

The bank's server gateway offers operations to authenticate clients and to transfer variable size messages to the bank.

Client authentication includes a time-stamped client ID, a (public) key, a transaction ID, and a client location identifier. Either the client is authenticated or not, which must be communicated back to the client application program. In your program you may assume that the server gateway is known to the client program, i.e., the client has an (object) reference to the server gateway object.

The message transfer service permits to submit character messages and numeric messages from the client to the server. Each message is digitally signed and the signature is also sent with the message to the server. Message size is determined at run-time and cannot be assumed a priori. For both message types the server returns an ID and a digital signature.

Note, you do not have to implement the actual code that computes signatures etc., you should only worry about how to model the service interfaces and how to do communication. All object implementations may be dummy functions, only the operation signatures must be correctly defined and represented in your programming language of choice (Java or C++).

Question 1: (6 Pts.) Dynamic invocations

Based on the CORBA dynamic invocation interface implement the communication mechanism between the client and the bank's gateway, as described above. Hint: You may re-use parts of your implementation of assignment 1. The only code that changes is the client code, which should be based on the DII rather than on static invocations.

For the implementation you may either use the Java-based JacOrb or the C++-based OrbAcus. Both are installed on the eecg machines. Manuals are available in the class reader directory. There are also lots of examples in the OrbAcus distribution, for you to look at (examples are also available in the JacOrb distribution). You may also use any ORB of your choice.

a.) Briefly describe the client implementation.

b.) Measure and report the cost of one invocation as the average over a number of invocations including variance. Describe your methodology and experimental setup (somebody reading your report, must be able to repeat your experiments and should get similar results). To measure execution time you can either use the time system call or the getrusage system call (Linux).

c.) For the messaging service measure and report the communication cost for increasing message size of character messages vs. numeric messages (plot your results - message size vs. communication time). The measure should include the entire cycle client to server and back to client.

d.) Analyze your findings and compare your performance results with the results you achieved in assignment 1. What do you conclude ? (You do not have to repeat your results from assignment one, just reference them.)

Question 2: (4 Pts.) DII/DSI based ORBs

a.) Is it possible to base an ORB design / implementation entirely on the DII and the DSI (dynamic skeleton interface). The DSI is the same as the DII, except that it operates on the server side. Since we did not discuss the DSI in class, you may base your discussion on the client-side ORB only, if you wish. Explain if such a design / implementation would be possible or not.

b.) As you probably noted in question 1 above, it is rather tedious to use the DII. Consider the situation in which the interface of the remote object is given at the time the client is developed. Is it possible to support the programmer with a stub-compiler, even if the ORB design did not foresee a static invocation interface, i.e., does not provide a stub-compiler that generates stubs that talk to proprietary ORB interfaces. Explain your answer.

c.) What are advantages and disadvantages of basing an ORB entirely on the DII/DSI ?