What These Changes Entail

3.5.1 What These Changes Entail

What were seeing is a fundamental fact of life in distributed applications. As a socket-based distributed application grows more complex, the socket-level protocol it uses tends to evolve into something that looks more like the method-dispatch mechanism of an object-oriented programming language. Moreover, as the application evolves, a significant percentage of the additional code deals with protocol changes: marshalling and demarshalling objects, specifying additional methods that can be invoked, and so on. This additional code has three bad properties: theres a lot of it, its tedious to write, and it needs to be maintained. Versioning issues can also arise. It can be inconvenient to reinstall the client application everywhere whenever a new feature is added. But since new features translate almost directly into protocol changes, this means that a robust application has to account for the possibility that the client and server were compiled at different times, from different versions of the code base and, therefore, use different protocols. This is usually handled by sending additional metadata specifying the protocol version along with every request.

Chapter 4. The Same Server, Written Using RMI

In this chapter, we continue our discussion by reimplementing the printer server using RMI as a distribution mechanism instead of sockets. As part of doing so, I will introduce the core infrastructure of RMI in a familiar setting. In fact, the application itself will look remarkably similar to the socket-based version. By the end of this chapter, you will have received a glimpse at how an RMI application is structured and the basic sequence of steps required to build one.

4.1 The Basic Structure of RMI

In the previous chapter, we covered the basics of implementing a socket-based distributed application. In doing so, we reinforced the lessons of the previous two chapters on streams and sockets. In addition, we discovered that the code necessary for writing a socket-based distributed application falls into five basic categories: • Code that actually does something useful. This code is commonly referred to as business logic. [ 1] An example is an implementation of the Printer interface. [ 1] Business logic is actually a generic term that refers to the code that justifies the applications existence e.g., the code that actually implements the desired functionality. • User interface code for the client application. • Code that deals with marshalling and demarshalling of data and the mechanics of invoking a method in another process. This is tedious code, but it is straightforward to write and is usually a significant percentage of the application. • Code that launches and configures the application. We used a number of hard-wired constants in NetworkBaseClass to enable the client to initially connect with the server. And we wrote two main methods™one to launch the client and one to launch the server. • Code whose sole purpose is to make a distributed application more robust and scalable. This usually involves one or more of the following: client-side caching so the server does less work; increasing the number of available servers in a way thats as transparent as possible to the client; using naming services and load balancing; making it possible for a