This is another article found in the depths of our archives about Client Server architecture. It contrasts the Fat Client implementation of MAS 90 with the Thin Client of MAS 200. This white paper was written to help our clients understand the difference between Sage MAS 90 and Sage MAS 200.
Here is the original article written by our founder, Phil Martin.
Hold on, this may get a bit technical...
Most Local Area Networks or LANs run as file servers, meaning they operate as a shared remote disk drive for client workstations. These networks are optimal for document based processing such as word-processing and spreadsheet applications because they provide a dedicated processor for working with large amounts of data in memory and share the infrequent access to disk drives. Transaction based systems, such as accounting applications, are the opposite. They process a single transaction at a time requiring little memory and processor resources and spend most of their time moving data between memory and the disk drives. For example, processing a sales order is not much more than extending the quantity by the price but records from many files - the Customer Master, Terms Code, Salesman, and Inventory files, to name a few - must be read and written over the network. Not the same as reading a document, moving lots of data around for a few minutes, then writing it back. So, for transaction based applications, forget about performance on a File Server LAN. The dedicated processor and abundant memory are wasted and the slowest link, the remote disk access, is overworked.
And what about reliability? While the programs do reside on the File Server host, they must be downloaded and actually execute on the workstation. Because moving data in memory is so much faster than accessing the disk drive, the workstation hoards as much data from the server's disk files as possible in large blocks of memory called buffers. As data is needed, the computer first reads a segment of the disk file into a buffer and then uses the memory based version for the program's subsequent access to that portion of the file. Consequently, during a program's execution, data in the buffers get "out of sync" with their disk file counterparts. If no unused buffers are available, the oldest used buffer is written back to the disk file and it becomes available for reuse. Individual buffers usually hold only a fraction of a complete file. Therefore, the disk files being updated by a program become "corrupted" with these partial write backs until the program ends and all of the remaining buffers are written back to the disk. While the program is running, the disk files are vulnerable. If the network connection is dropped or the workstation is restarted, data being held in the buffers is lost and can never be written back to "resync" the disk files. Database Server applications using products such as SQL Server overcome the "dirty buffer" problem by keeping the data file access on the server. This improves reliability but doesn't do so much for performance because the programs are still downloaded and all of the application's data records, not just the portion required for the user's screen display, are read and written over the network to be processed at the workstation.
The Application Server environment of MAS 200 is similar to the internet. Everything is on the host except the user interface. No programs are downloaded and no application data files are opened on the user's workstation.; But unlike the internet, there is no delay for graphical images to be downloaded for display. In fact, MAS 200 actually runs on the server in character mode. The thin-client "browser" running in Windows on the workstation receives a text command from the host with the specifications for each Windows "object" to be drawn on the workstation's display followed by the text designated for the data fields on the displayed form. Also, to minimize network traffic, static MAS 200 components such as the Help text files are kept on the workstation in a local "cache". Remote users really benefit from MAS 200 because they can make a TCP/IP connection either over the Internet or by dial-up directly to the server. It is not necessary to connect through products such as Microsoft Terminal Server or pcANYWHERE. These methods remotely control software running locally by extending the display and keyboard functions over the connection. They must duplicate the bit-map of the application's screen image on the remote computer. Even over high-speed lines, there can often be a tedious wait for the screen to display.
The Client/Server implementation of MAS 200 embodies a "Unix" style architecture. Applications run on the server and have direct, high-speed access to data on a local drive or from a SQL database server. They communicate with an intelligent client at the workstation that locally implements the Windows interface. Consequently, performance benchmarks on updates may be over 10 times that of a comparable LAN implementation. There is no processing delay to download the program over the network to the workstation and there is no overhead to read and write large data buffers across the network. Data is buffered at the server and only display data is sent to the workstation. The vulnerability of the database to corruption by stranded data on the workstation is eliminated.