Beautiful Code [250]
20.6.1. Dynamic Reconfiguration
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.
20.6.2. Hot Swapping
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.
A Highly Reliable Enterprise System for NASA's Mars Rover Mission > Conclusion
20.7. Conclusion
The Collaborative Information Portal proves that it is possible—yes, even at a huge government agency like NASA—to develop a large complex enterprise software system on time that successfully meets strict requirements for functionality, reliability, and robustness. The Mars rovers have far exceeded expectations, a testament of how well the hardware and the software, both on Mars and on Earth, were designed and built, and of the skills of the builders.
Unlike smaller programs, beauty for a large application is not necessarily found only in elegant algorithms. For CIP, beauty is in its implementation of a service-oriented architecture and in the numerous simple but well-chosen components—the nails that master software builders know just where to pound in.
ERP5: Designing for Maximum Adaptability > General Goals of ERP
21. ERP5: Designing for Maximum Adaptability
Rogerio Atem de Carvalho and Rafael Monnerat
Enterprise resource planning systems are generally known as large, proprietary, and highly expensive products. In 2001, work on an open source ERP system known as ERP5 (http://www.erp5.com) began in