Beautiful Code [245]
Modularity
The importance of modularity increases exponentially with the size of the application. In CIP, each service is a self-contained middleware component that is independent of the other services. If one service needs to work with another service, it makes a service request of the other service just as if it were a client application. This allowed us to create the services separately and added another dimension of parallelism in our development. Modular services are beautiful artifacts that are often found in large, successful SOA applications.
In the client tier, the application programs often compounded the services, either combining the results of multiple services or using the results of one service to pass in a request to another service.
Scalability
CIP usage levels spike whenever mission control releases processed data and image files, especially after an interesting discovery by one of the rovers. We had to ensure that the CIP middleware can handle such spikes, particularly when the users are anxious to download and view the latest files. A slowdown or, worse, a crash, at such times would be highly intolerable and highly visible.
One of the beauties of the J2EE infrastructure is how it handles scalability. The application server maintains bean pools, and based on demand, it can automatically create more instances of our stateless session bean service providers. This is a significant "free" J2EE feature that the middleware service developers were happy to accept.
Reliability
As a standard that had undergone much vetting by industry, the J2EE infrastructure proved to be extremely reliable. We avoided pushing the envelope of what it was designed to do. So after two years of operation, CIP achieved an uptime record of over 99.9 percent.
We went beyond what J2EE intrinsically provided for reliability. As you'll see in the following case study, we pounded a few extra nails into our services to further increase their reliability.
A Highly Reliable Enterprise System for NASA's Mars Rover Mission > Case Study: The Streamer Service
20.4. Case Study: The Streamer Service
You've seen some of the beauty of CIP at the architectural level. It's time to focus on one of its middleware services—the streamer service—as a case study, and examine some of the nails that allowed us to meet the mission's strict functional, reliability, and robustness requirements. You'll see that the nails were not particularly fancy; the beauty was in knowing just where to pound them in.
20.4.1. Functionality
One of the MER mission's data management needs is to allow users to download data and image files from the mission file servers located at JPL to their personal workstations and laptops. As described earlier, CIP data-tier utilities generate metadata that allow users to find the files they want based on various search criteria. Users also need to upload files that contain their analysis reports to the servers.
CIP's streamer service performs file downloading and uploading. We gave the service that name because it streams the file data securely across the Internet between the mission file servers at JPL and users' local computers. It uses the web services protocol, so client applications can be written in any language that supports the protocol, and these applications are free to devise whatever GUI they deem suitable.
20.4.2. Service Architecture
Like each of the other middleware services, the streamer service uses web services to receive client requests and to return responses. Each request is first fielded by the streamer service provider, which is implemented by a stateless session bean. The service provider creates a file reader, implemented by a stateful session bean, to do the actual work of downloading the requested file contents to the client. Conversely, the service provider creates a file writer, also implemented by a stateful session bean, to upload file contents (see Figure 20-3).
Figure 20-3. The streamer service architecture
At any given moment, multiple users can be downloading or uploading files,