|
|||||
|
|
|||||
| Writing robust server programs | |||||
Server programs have a requirement for robustness that is greater than for most other types of software, since they usually run without direct human supervision or input. For this reason, programming an OmniMark server forces you to think about robustness in a way that you would not necessarily have to do if, for instance, you were writing a batch translation program.
In a "batch" environment you have the opportunity to proofread your output. It is often sufficient for a non-critical batch program that receives garbage to produce garbage, if there's some human who can look at the output and say "that's garbage", and proceed to examine the input with a view to either correcting the situation or abandoning the processing attempt. It's sufficient that the program doesn't corrupt other programs or data. In a similar fashion, it's reasonable to respond to a garbled online search command with data that isn't expected by the user -- the normal user response will be to go back to the search command, rephrase it, and try again.
However, in more critical cases, especially where there is no human checker involved, or if careless interpretation of erroneous input can damage a system or other processes, then a program must be written so as to recognize the garbage and respond in a responsible way: report it or "correct" it.
The sort of unsupervised criticality that requires an extra degree of "good citizenship" is a characteristic of server-side programs -- servers themselves and the programs they invoke. Batch programs and client-side programs can more often count on a human validation of what they do.
Not only do server-side programs need to be written to take more responsibility for stability and reliability than do batch programs, but they also pose new difficulties in implementing policies that support stability and reliability. One such new problem is in the nature of how data flows over a network, and how it is presented to server-side programs. For batch programs, data is typically available in self-contained units such as files or data base records. The system -- the file system or database system -- usually takes care of identifying the end of input and signaling it to a program. Server-side programs, on the other hand, may get their input from a TCP or other network connection that remains open across many transactions. A "file" may not have an out-of-band signal indicating its end, and the server-side program may need to detect the end of data in some other manner -- often by examining the data itself for some application-specific characteristic.
The consequences of not correctly identifying the end of a data stream can be quite severe. One of the simplest problems that can occur is a program's hanging -- waiting for more input when there is no more input. This can happen, for example, because errors in the input have caused the server program to skip over the indication of the data end in search of something else. Hanging programs can have the effect of stopping a system from doing anything -- because even when a system can run more than one program, the thing that causes one to hang will, typically, eventually cause all the others to hang, and systems don't have infinite resources.
A useful way of looking at how to deal with erroneous input is to consider input data to be in a language that has a grammar. The program is effectively a parser for that grammar. A responsible program must incorporate into its grammar all input possibilities, not just one "correct" one. And there must be processing corresponding to all paths through the grammar. This is an especially useful approach in conjunction with OmniMark, as OmniMark strongly supports a linguistic approach to data processing.
| ---- |
