Introduction

The client and server code given so far is very procedural. In fact, the best way to express the server is as a finite-state machine, and this works well for the client too.

A finite-state machine isn't an O/O representation. How does this fit in with O/O design representations such as UML? It doesn't. So if you want to use UML, you have to hide the finite-state machine.

Standalone FTP application

A simple UML diagram for a standalone FTP application could be

Half Object plus Protocol (HOPP)

To change this to a client/server system, the FTP object needs to be split in two: one half in the client address space, the other half in the server address space. The two half-objects will communicate using a private protocol that is unknown to the rest of the application.

The private protocol will here be "message passing using sockets". Other implementations may use CORBA, RMI, JXTA, etc. This allows the implementation of the HOPP objects to be changed without affecting the rest of the application.

HOPP FTP Server

The server from the lecture on protocols nearly fits this design pattern. The changes are

• All the file handling code goes into its own class FileTransferServerHOPP
• The methods of this class are
  • String[] dir()
  • boolean chdir(String dir)
  • String getdir()
  • ...
• The server creates a SocketHandler in a new thread for each new socket
• The SocketHandler has a FileTransferServerHOPP to which it delegates all file calls.

HOPP FTP Client

The client in the lecture on protocols does not fit this design pattern and does need to be changed. It mixed up UI and protocol calls, and these should be separated.

A revised client, made up of FileTransferClientHOPP and FileTransferClientUI follow. Points to look out for

• All networking code is in the HOPP. None is in the UI
• All communication to the user is in the UI. None is in the HOPP.
• All socket messages are accessed by methods of the HOPP, with hidden implementation.
• The implementation of the HOPP can be changed if the transport protocol changes, without changing the client UI. e.g to CORBA, RMI, etc
• The HOPP returns booleans, strings or throws exceptions as appropriate. It never writes error messages to the console
• The methods of the client HOPP are
  • String[] dir()
  • boolean chdir(String dir)
  • String getdir()
  • ...

The client HOPP is

The Client UI is

Changing protocols

• If the protocol changes, you only need to change the client HOPP and the server. The rest should remain essentially unaltered
  
• See many examples in later lectures
• Sometimes a middleware system will force minor changes on other parts e.g. RMI will require all methods to throw RemoteException