Field vs. Web: Is there a difference

What is a field application expected to be?

From a User Standpoint

Take anywhere, 100% information availability.
Part of a small selection of applications, maybe the only one used in the field.
Tailored and focused on job requirements. The user interface and functional fit are oflen critical to success.
May permit view, redline, and true update of graphics and attributes.
May be complex and sophisticated to support field activities.

From a Technical Standpoint

Almost all data needs to be stored persistently on local storage.
Provide all functionality as a stand-alone application, except possibly for integrating information back into the server databases.
Maintain data model and data integrity for communication with host,
Allows for a huge range of communications protocols and speeds. None of them are expected to be always available.
Has a user interface that can cope with sophisticated editing.

Conceptual Models
The distinctions between the types of applications become easier to understand if we consider some conceptual models underlying these software architectures. These models define scales by which a particular solution can be measured and classified. Most of the rest of this paper will refer to the three architectures defined below, as they are more neutral terms relative to the use that is made of the system. In the final section of the paper, the pros and cons of implementing each architecture for particular purposes will be examined.

Master-Slave, Client-Server, and Peer-Peer
These three pairings effectively define a scale of the “intelligence” level of the client. The functionality of the server does not vary much between the extremes of the client, although the way in which it interacts with the client does.

Master-Slave
At this end of the scale, the client contributes little or nothing to the overall system beyond giving access to the resources and intelligence of the server. Terminal emulators and X-windows terminals exemplifi the extreme “slaves”. Every aspect of the user’s interaction with the system is controlled and managed by the server. Because of the low intelligence of the client, almost everything the user does requires messages to go back to the server to determine the response. This architecture is now often referred to as “Thin Client”

Client-Server
In a client-server architecture, there is a more even division of labor, and the client is more intelligent. Classic examples are traditional database applications, where the server is responsible for data storage, management and retrieval, and the client is responsible for presentation and manipulation of the information. There is a good deal of variation in the intelligence levels of the clients and whether various levels of application logic are implemented at the clients or in the server portion. This is traditionally the “Thick Client” in contrast to the “Thin Client”