Skill-Building Exercises

Summary

Simple socket-based server applications utilize a ServerSocket object to listen for incoming client connections. A ServerSocket object listens for incoming connections on a specified port. Client applications utilize a Socket object to connect to a server application on a specified URL or IP address and port number. The localhost IP address can be used during testing.

The Socket object is used to create the IOStream objects using the getInputStream() and getOutputStream() methods. Once the IOStream objects are created on both the client and server ends the applications can communicate with each other via an established set of rules. (a.k.a., custom application protocol). A client-server protocol is connection oriented if a socket connection is maintained open between the client and server applications for the duration of their communication session.

Proceed first with a client-server project by giving sufficient analysis to the project specification. Use noun-verb analysis to discover candidate application components and actions. Sketch out a rough application design to use as an implementation road map. Make a list of candidate application classes and assign to them an initial set of responsibilities. The objective of the analysis and design phase is to provide a starting point for implementation and get the creative juices flowing.

Socket-based client-server applications will utilize classes found in the java.net package. RMI-based client-server applications will utilize classes found in the java.rmi package and its related packages. However, to fully implement a client-server application requires the utilization of many different Java platform classes.

When ready to proceed with the implementation phase select the smallest subset of the design that results in a set of application functionality that can be tested. Some code written during the implementation may be ultimately discarded before the final application is released.

Remote Method Invocation functionality is often easier to implement than socket-based functionality. This is because the RMI runtime handles socket communication and thread management issues behind the scenes. Implementing RMI functionality, however, requires the programmer to generate the necessary stub files for deployment with the server and client applications. RMI servers must bind an instance of the RMI object to a service name in an RMI registry.

RMI-based clients gain access to an RMI object via its service name. The remote object’s interface and stub classes must be deployed with the client application. Calls to the remote object look like ordinary method calls. All network communication required between the RMI-based client and remote object is handled by the RMI runtime environment.

The RMI runtime manages client access to RMI server-side objects. In cases where RMI-based clients must have access to dedicated server-side remote objects a factory class can be employed to create the dedicated remote objects as required. RMI-based clients must first get a reference to the server-side factory object and use it to create the dedicated remote object it requires. This solves the dedicated remote object problem but raises the level of application complexity. In addition to the dedicated remote object interface and stub classes, the factory interface and stub classes must also be deployed with the server and client applications.

Programming a socket-based client-server application requires attention to lower-level details when compared with RMI-based applications. To handle multiple socket-based client connections, a socket-based server application must be multi-threaded. The socket-based server must also establish an application protocol so the client application can effectively communicate with the server application.

Hard-coded magic values render it difficult to change an application’s configuration settings. The Properties class can be used to store and retrieve application property values.

There is no guarantee when the JVM garbage collector will run and remove unreferenced object from memory. Objects referenced by the RMI runtime will generally be held longer that objects referenced by independent threads.