Change is inevitable, and beautiful code can handle change gracefully even after going into operation. We took a couple of measures to ensure that CIP is robust and can deal with changes in operational parameters:
We avoided hardcoding parameters in the middleware services.
We made it possible to make changes to the middleware services that are already in operation with minimal interruption to the client applications.
Most of the middleware services have certain key operational parameters. For example, as seen above, the streamer service downloads file contents in blocks, and so it has a block size. Instead of hardcoding the block size, we put the value in a parameter file that the service reads each time it first starts up. This happens whenever the streamer service provider bean is loaded (lines 3–5 in the code under the section "Logging").
A middleware.properties file, which all the middleware services share and load, contains the line:
middleware.streamer.blocksize = 65536
The file reader bean's readDataBlock( ) method can then refer to the value (line 183).
Each middleware service can load several parameter values at startup. One of the skills of a master software builder is knowing which key values of a service to expose as loadable parameters. They are certainly helpful during development; for instance, we were able to try different block sizes during development without having to recompile the streamer service each time.
But loadable parameters are even more critical for putting code into operation. In most production environments, it is difficult and expensive to make changes to software that is already in operation. This was certainly true for the MER mission, which had a formal Change Control Board that scrutinized the justifications for making code changes once the mission was under way.
Avoiding hardcoded parameter values is, of course, a basic Programming 101 dictum that applies to small and large applications alike. But it is especially important with large applications, which may have many more parameter values that are scattered throughout large bodies of code.
Hot swapping is an important feature of the commercial application server that we employed in the CIP middleware. It is possible to deploy a middleware service that replaces one that is already running without first bringing down the middleware (and CIP altogether).
We use hot swapping whenever we need to force a service to reload its parameter values after a change, which we accomplish simply by reloading a service on top of itself. Of course, a service such as the streamer service that uses stateful session beans (the file reader and writer beans) would lose all state information. So, we can hot swap such a service only during "quiet" periods when we know the service is not currently being used. For the streamer service, we can use the Middleware Monitor Utility's Files tab (see Figure 20-8) to let us know when that's the case.
Hot swapping makes most sense in the context of a large enterprise application, where it's important to keep the rest of the application running while you are replacing part of it. With a small program, you'd probably just rerun the program to make a change.