The common response to the problem of gathering, tracking, or manipulating data within an active business is to use spreadsheets. These bring their own problems, particularly apparent when one tries to share the resulting files with multiple users spread around the company. Trying to control data change and user updates is difficult. The usual result is multiple copies of files spread about the company, with some not being the same as others.
Attempts to manage these separate copies tend to add complication to the spreadsheets, making them more likely to fail and more difficult to support. For example, you might add a macro to automate a process within a spreadsheet, only to find that the macro does not run on all the computers because of a missing dependent file.
The answer is to centralize the data and then distribute tools that allow users to view, manipulate, add, and report on the data. In networking terminology, the central resource is the server, and the distributed end-user interface, the client.
The server part of the solution is a database: a central data storage system. In many ways, this part is easy. There are many database systems available, from personal desktop databases like Access and Open Office's "Base", to large corporate systems such as Oracle and Microsoft's SQL server. Many such as MySQL, PostgreSQL, and SQLite sit in the middle ground, providing excellent low cost database solutions for most everyday requirements, and are particularly suited to web applications. They are easy to find, and many are easy to install and use. Effective solutions can be created with the minimum of customization.
The client part is more problematic: provide a user with an input and output tool that is available wherever the information is required within the business. The output from the system needs to be tailored to the user's requirements, if they are to use the data most efficiently. The input must be controlled to maintain the quality and integrity of the data. "Rubbish in, rubbish out", is a cliché, but a useful one that highlights the fact that a data system is only as good as the data it holds. Without input control, a database can rapidly lose its value as it gets filled with data that cannot be searched nor compared easily. For example, it is surprising to see that the problems can be caused by entering the alphabetic character "o" where a zero should be added.
Most databases have administration interfaces that afford a user the ability to retrieve and input data, but by their nature they do so in an uncontrolled manner that is unsuitable for most end-user requirements. Instead a user interface is required.
The control of input and output is likely to be unique to the business requirement, and therefore, this element usually requires the most customization. This raises a problem that on first appearance may not seem to be too important, but on closer inspection has a fundamental effect on the performance and stability of the resulting application. The server part of the system will be located on a small number of easily controlled servers. The distributed client part will be spread around the business' desktop computers.
In many businesses (especially smaller businesses), desktop computers are often varied, with new computers added as they are needed. There is often a wide range of end-user computing hardware in place throughout a business. Servers, on the other hand tend to be small in number and are brought in to address a limited number of requirements.
Therefore, the straightforward server application (the database) is being held on the most easily controlled and defined area of the network; the server. The complicated client user interface is hosted on the most diverse part of the network; users' computers. So there is a problem in that the part of the system that needs most customization, and therefore is most likely to require maintenance, is located on the most diverse part of the network. This is a recipe for failure.
Deploying the client side of the system via a web service overcomes this problem. With a web service, the client application is split between a central web server, and a distributed web interface (the users' web browser). The two are connected over the network via a well-defined standard based protocol (HTTP). The majority of computation and logical operations are carried out at the web server. The user's web browser is used to display information and provide simple forms for user input.
In their simplest form, both the information display and input forms are presented via standard languages (HTML or XHTML). This reliance on simple defined open standards means that the work of the user's web browser is kept to a minimum, with most of the complicated work being carried out at the web server.
The result is that the least controlled part of the network (end user workstations) now hosts the simplest part of the system (receiving and displaying the HTML information). The more complicated parts of the system resides on the most easily controlled parts of the network: the web and database servers.
Extra functionality can be added to the web pages presented to the user, by the use of JavaScript (which allows logical operations to be carried out at the browser), XML (as either an alternative to HTML or as part of custom data transfer operations), and CSS (Cascading Style Sheets provide a way of improving the appearance of web pages without significantly increasing the complexity of the HTML code. In essence, the best way to convert drab web pages into attractive media experiences). These three systems are combined into a framework called AJAX, which is used to greatly enhance the user experience. There is a tradeoff between the addition of this extra functionality, and the additional complication that results, but with care the tradeoff is manageable, and resulting systems are still simpler than alternative solutions.
Therefore, a client/server based web application provides the ideal platform to store, manipulate, and present data throughout a dispersed business environment.