Beautiful Code [50]
Martians have zero tolerance for ugly software. For CIP, the notion of beauty is not so much about elegant algorithms or programs that you can stand back and admire. Rather, beauty is embodied in a complex software structure built by master builders who knew just where to pound in the nails. Large applications can be beautiful in ways that small programs often are not. This is due both to increased necessity and to greater opportunity—large applications often have to do things that small programs don't need to. We'll take a look at CIP's overall Java-based service-oriented architecture, and then, by focusing on one of its services as a case study, examine some code snippets and study some of the nails that enable the system to meet the functionality, reliability, and robustness requirements.
As you can imagine, software used on NASA space missions must be highly reliable. Missions are expensive, and years of planning and many millions of dollars cannot be jeopardized by faulty programs. The most difficult part of the software work, of course, is to debug and patch software used onboard a spacecraft that is millions of miles from Earth. But even ground-based systems must be reliable; nobody wants a software bug to interrupt mission operations or cause the loss of valuable data.
There is a bit of irony in writing about beauty for this type of software. In a multitiered service-oriented architecture, the services are implemented in a middleware tier that resides on a server. (We developed shared reusable components in the middleware, which greatly reduced development time.) The middleware decouples the client applications from the backend data sources; in other words, an application doesn't have to know where and how the data it needs is stored. Client applications make remote service requests to the middleware and then receive responses that contain the requested data. When all the middleware services are doing their jobs well, the end users of the enterprise system should not even know that their client applications are making remote service requests. When the middleware is operating smoothly, users should believe that they are directly accessing the data sources and that all the data processing is happening locally on their workstations or laptops. Therefore, the more successful the middleware is, the less visible it becomes. Beautiful middleware should be invisible!
20.1. The Mission and the Collaborative Information Portal
The primary goal of the Mars Exploration Rover, or MER, mission is to discover whether liquid water once flowed on the Martian surface. In June and July 2003, NASA launched two identical rovers to Mars to operate as robotic geologists. In January 2004, after separate seven-month journeys, they landed on opposite sides of the planet.
Each rover is solar-powered and can drive itself over the surface. Each one has scientific instruments such as spectrometers mounted at the end of an articulated arm. The arm has a drill and a microscopic imager to examine what's beneath the surface of rocks. Each rover has several cameras and antennas to send data and images back to earth (see Figure 20-1).
Unmanned NASA missions are a combination of hardware and software. Different software packages onboard each Mars rover control its operation autonomously and in response to remote commands issued from mission control at NASA's Jet Propulsion Laboratory (JPL) near Pasadena, California. Earth-based software packages at mission control enable the mission managers, engineers, and scientists to download and analyze the information sent by the rovers, to plan and develop new command sequences to send to the rovers, and to collaborate with each other.
At the NASA Ames Research Center near Mountain View, California, we designed and developed the Collaborative Information Portal (CIP) for the MER mission. The project team consisted of 10 software engineers and computer scientists. Another nine team