17.10. Your company wishes to move from using desktop applications to accessing the same functionality remotely as services. Identify three risks that might arise and suggest how these risks may be reduced.
1. Concurrency:
Many of the core functionalities of the application may be designed to be the exclusive user of a resource at any given time. For instance, opening a file which then stays open until the application is exited, which then overrides the saved file with the one in memory. This functionality, which is fine for the local app, would be ruinous for a networked software with shared resources, as one application may override the changes of another simply by having been opened first and closed last. This may be less significant of a risk if the application utilized network-friendly data storage methods, such as SQL.
To address this issue, care must be taken to ensure that there are no concurrency issues for all file/data-based operations. Moreover, data access cannot simply be rewritten to networked equivalents; in some cases the core logic of any given I/O operation may have to be revised.
2. Accessibility:
If the application has any large calculations which it performs, then these features must be implemented with great caution when put into a networked service. After all, if a client (or number of clients) connects to the service and ask it to run its most computationally intensive functionality, the service must be able to juggle its responsibilities such that no single client monopolizes the service; and that new users will be able to join and still have their user experiences unharmed.
To solve this, the application must be converted to utilize a task manager with hierarchies of tasks. This way, core communications can be given priority across all sessions and all users, while the expensive operations can be relegated to be given proportional distribution of the available remaining calculation space. Another option might be to make for ‘fat’ clients; where these heavy calculations are given to the client rather than the server; but this solution might not be available depending on the specifications of the project, and comes with its own issues.
3. Security:
The most significant feature which a local application does not have to account for is security; after all, if you’re logged into the computer and able to open the app, you’re probably supposed to be there. However, networked services have no such protection; anyone in the network (which could likely be the global web) may interface with the service. This means that security becomes a significant issue; by having every application user’s information stored and computed within this networked service, it creates a significant potential for a malicious entity to intercept, view, or alter this data; with potentially ruinous effects on the individuals under attack. Therefore, remote services must have significant and extensive security in place, to protect the confidentiality and integrity of its processes.
The only way to solve security is to take it seriously. Most likely, all aspects of validation, verification, and communication between client and server will have to be redesigned in order to take advantage of modern network security frameworks; luckily, many of these frameworks are becoming increasingly well-designed and easy to implement, making security approachable as a requirement, despite never being truly solvable.