Beautiful Code [246]
Why does each file reader and file writer have to be a stateful session bean? Unless the file is small, the streamer service transfers the file contents one block at a time in response to "Read Data Block" or "Write Data Block" requests from the client. (The download block size is configurable on the middleware server. The client application chooses the upload block size.) From one request to the next, the stateful bean keeps track of the open source or destination file on the mission file servers and the position within the file of the next block to be read or written.
This is a very simple architecture, but it very effectively handles multiple downloads simultaneously from multiple users. Figure 20-4 shows the sequence of events for downloading a file from the mission file servers to a user's local machine.
Figure 20-4. How the two-layer service handles a file read
Note that the Streamer Service Provider bean does not maintain any state between service requests. It functions as a rapid service dispatcher that parcels work out to the stateful File Reader beans. Because it doesn't need to track requests or maintain state, it can handle requests intermingled from several client applications. Each File Reader bean maintains state information (where to get the next block of data) for a single client application as the application makes multiple "Read Data Block" requests to download a complete file. This architecture enables the streamer service to download multiple files to multiple clients simultaneously while providing acceptable throughput for all.
The sequence of events for a file upload from a user's local machine to the mission file servers is just as straightforward. It's shown in Figure 20-5.
Figure 20-5. How the two-layer service handles a file write
These tables don't show it, but besides a file token, each client request also includes a user token. A client application first obtains a user token when it makes a successful login request (with a user name and password) to the middleware's user management service, thus authenticating the user. A user token contains information that identifies a particular user session, including the user's role. It enables the streamer service to verify that a request is coming from a legitimate user. It checks the user's role to ensure that she has the right to download a particular file. For example, the MER mission disallowed users from foreign (non-U.S.) countries from accessing certain files, and CIP respected all such security restrictions.
A Highly Reliable Enterprise System for NASA's Mars Rover Mission > Reliability
20.5. Reliability
Reliable code continues to perform well without problems. It rarely crashes, if ever. As you can imagine, code that is on board the Mars rovers must be extremely reliable because making on-site maintenance calls is somewhat difficult. But the MER mission wanted earthbound software used by mission control to be reliable, too. Once the mission was underway, no one wanted software problems to disrupt operations.
As noted earlier, the CIP project took several measures to ensure the intrinsic reliability of the system:
Adhering to industry standards and best practices, including J2EE
Using proven COTS software wherever practicable, including a commercial application server from an established middleware vendor
Using a service-oriented architecture with modular services
Implementing simple, straightforward middleware services
We further enhanced reliability with extra nails: service logging and monitoring. While these features can be useful for debugging even small programs, they become essential for keeping track of the runtime behavior of large applications.
20.5.1.