Defining the Solution

The new system will use a centralized server that hosts a database of shared information. Clients will retrieve information from the database using a set of dedicated XML Web service methods that wrap all the required functionality.

To ensure optimum performance, the XML Web service should be devoted solely to performing database operations and returning information. A separate server-side component can run continuously (unless stopped by an administrator), performing the actual rendering operation. Figure 18-1 shows a high-level diagram of the system.

Figure 18-1. The SuperCompute system architecture

One detail Figure 18-1 doesn't show is that the client retrieves the rendered file directly from the server (using a UNC file path stored in the database). It is possible to force the client to work through the XML Web service and to use the "downloading" technique shown in Chapter 15. This approach isn't practical, however, because of the sheer size of the rendered files (potentially hundreds of megabytes). Even though the ASP.NET worker process can easily handle the task, multiple downloads would tie up all the available worker threads, rendering the server unable to handle other requests. This would seriously affect scalability and reduce the overall reliability and availability of the XML Web service.

The final part of the SuperCompute architecture is the authentication model. Even though Trey Research has modest security needs, you need a disciplined system in place that ensures that tasks are linked to users. This not only makes it easier for clients to retrieve information about the tasks they have submitted, but it also enables the system administrator to track usage information and determine which users and projects have the highest processing requirements.

Trey Research has the choice of either using Windows authentication and leveraging the current set of user logins on the network server or developing a custom authentication system that retrieves user account information from the network server. Trey Research favors the latter because it allows task records to be easily linked to the corresponding user record in the database. It also separates the information, allowing the network and rendering-service users to be managed separately (one group by the network administrator and the other group by the graphic coordinator). In the future, this system could be the foundation for a more elaborate permission-based system that imposes strict limits on the types of projects that can be submitted and how the processor prioritizes them.

Figure 18-2 shows the current system, which uses the ticket approach described in Chapter 13. When a ticket is generated (by the Login method), a record is written to the database with a GUID, identifying the client. On subsequent requests, the ticket is used to validate the session. Finally, the ticket is removed using a dedicated Logout method, custom expiration logic in the XML Web service, or a stored procedure that performs batch cleanup.

Figure 18-2. Authentication with a custom ticket system

By default, this custom authentication system is less secure at the transport level than Windows authentication is. This means that it is technically possible for network traffic between the client and XML Web service to be intercepted and passwords to be "sniffed" out. To defend against this possibility, Trey Research plans to install a server certificate and enable SSL security before rolling out the new application.

The security model has one limitation as it stands. Because users download their rendered files manually, without connecting through the XML Web service, it is possible for users to download rendered files that they did not create. The network administrator can apply directory restrictions that limit which groups of users can access rendered files, but there is no automatic way to set up a finer-grained system that sets individual permissions on each file. In the internal network used by Trey Research, this isn't considered a problem. However, the company might want to improve on it in a number of ways in the future. One approach would be to store files in a virtual directory and expose them over HTTP. This directory would not allow file browsing, so users would be restricted to making requests for specific files. Because the filename uses a GUID, it is unique enough to ensure that no user could ever guess another user's filename (and hence download it).

Note

Security-free downloading is desirable under certain circumstances because it allows easier team use. (One user can upload the file, for example, and another can download it.) If security is added at a later date, this requirement should still be considered. GUID filenames represent a good compromise because all members of a team can be informed about a given project file, and passwords need never be shared.