Getting Rid of the Skeletons

Because servers can implement more than one remote interface, these two requirements force rmic to work from the implementation files instead of the interfaces.

8.3.1 Getting Rid of the Skeletons

Earlier in this chapter, I noted that: Using different skeletons for different classes is not, strictly speaking, necessary. Well talk about why you want to get rid of them, and how to do so, later in this chapter. The reason many different types of skeletons arent necessary is plain: as part of a method call, RMI must already send over enough information to describe the method that needs to be called and the server object on which it should be called. A well-written generic dispatch method could then take this information and use Javas Reflection API to call the method directly without the intervention of a skeleton class. Early versions of RMI required skeletons. In Java 2, the skeletons were made optional. In order to build a system that doesnt use skeletons, you simply need to tell rmic that you are using the 1.2 protocol, as in the following example: rmic -keep -v1.2 -d d:\classes com.ora.rmibook.chapter8.Account_Impl com.ora.rmibook. chapter8.Account_Impl2 This will generate stub classes for Account_Impl and Account_Impl2 . However, it will not generate skeletons. The major reason for getting rid of skeletons is that doing so can simplify deploying and updating an application. The major reason to keep skeletons is that class-specific skeletons are slightly faster than generic ones, which must use the reflection API. In practice, theres not much difference either way, and I prefer to use skeletons simply because as a programmer who cut his teeth on CORBA, I feel that a distributed program without skeletons isnt quite proper.

Chapter 9. The Rest of the Application

In previous chapters, we discussed how to design and build servers. In this chapter, well finish the application off by building the launch code and assembling a simple client. In addition, well motivate much of the second section of this book by talking about the server lifecycle. By the end of this chapter, you will have seen all the steps involved in designing and building a distributed application using RMI and will be ready to start thinking about how to make your application scale. There is an apparent paradox here. The server code, while difficult to think through and frequently tricky to implement, is often less than half of the total application. The client code, which I relegate to Sect ion 9.4 , is a large and complex part of the application. There are two reasons for this apparently confusing situation. The first is that we have, to some extent, already discussed client-side issues when we discussed how to choose servers and design interfaces. A large percentage of that discussion was motivated by client-side concerns: what people will do with the application and how to design servers that support the intended uses. The second reason is quite simply that most of the client code doesnt involve the distributed parts of the application. While getting an instance of JTable to refresh properly is a difficult task, and people who write a good user interface are more than worthy of respect, this book is long enough without adding a guide to writing a client-server GUI.