Field vs. Web: Is there a difference
lain Cooke Conic Systems Inc 1919 Oakwell Farms Parkway, Suite 240 San Antonio, Texas 78218
Web, Field - Whatever: What is the problem?
Web GIS and Field GIS applications have a lot in common. Both provide low cost access to complex data held in a “host” GIS. As such, they are attractive for organizations wishing to get full benefit from their investment in GIS data. If they both do the same job, why can’t you just choose one product and use it for all your needs? Although there are very real differences between the systems, for any sweeping generalization, there will be individual products that are exceptions to the rule. A good analogy would be classifications of vehicles – there are many different designs out there, and although you could choose one type to cover a multitude of different needs, the chances are that you will be better off buying different models for different drivers. If linemen need trucks and salesmen need passenger cars, you don’t have them all drive a Chevy Suburban. What is a Web Solution expected to be? From a User Standpoint
A web application is normally expected to be downloadable in a matter of seconds. Some web applications make use of client-end plug-ins. The download time for the plug-in is often not counted, which some vendors have exploited by making their plug-ins quite large (more than 1 or 2 MB). What is a field application expected to be? From a User Standpoint
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” Peer-Peer A peer-to-peer architecture has two systems that are each responsible for maintaining and manipulating their own information according to their own rules, but they communicate information between them. The key distinction is that either system is effectively independent of the other, insofar as it can operate without the exchange of information, even if that would often reduce the uset%lness of the system dramatically. In most peer-peer architectures, the flow of information between the systems is (or could be) asynchronous – the sending system need not wait for the receiving system to process and respond to the message. Comparison A web browser is clearly near the master-slave end of the spectrum, providing a common and very generic client that does little more than provide a means of accessing data and functionality that is offered by a server. The World Wide Web was conceived as a means of providing easy access to a body of published information. Its style and communications protocols still reflect that original concept, although it has become much more interactive in the last few years. The vast majority of web applications have little or no processing and manipulation of information at the client end. Even with browser plug-ins and Java, the client functionality is usually limited to controlling presentation of packets of data received from the server or doing very basic pre-processing of information prior to sending it back. This is generally true of even the more sophisticated Web GIS clients; relatively small amounts of data are downloaded to the client, which may provide local pan, zoom and basic presentation manipulation. However, user activities that require any real processing, or even simply panning around will typically cause a request to be sent back to the server, and (probably) another download of data in response. Most solutions sold as field systems today are clearly at the opposite end of the spectrum, having a peer-peer relationship with the host GIS system. The field system will get a cut of data from the main database, and will happily provide usefid functionality without any fiu-ther reference to the “server”. Some time later, an exchange of information will occur, and then the two systems will again proceed independently. Being self-sufficient in this manner places requirements on the system designers that simply do not exist for the implementers of slave systems. Communications A related subject is that of the nature of the communications link between the two systems. However, the two can be viewed independently, because the functional relationship between the two systems is not determined by the means of communicating between them, although poor communications clearly have a much more substantial effect on less intelligent clients. There are several key measures of a communications link, each of which affects the efficacy of a particular system architecture in its own way.
Reliability is a little hard to judge because most communications systems have error correction built in. If a message is damaged in transit, this is usually detected and a resend automatically requested at a low level in the system. However, anyone who has tried downloading large tiles from the Internet over modems will know that the underlying reliability is reflected in an inability to receive the message at all within a reasonable period of time. Demands on Communications While any system will work well with a communications environment of high bandwidth, low latency and high reliability (typical of a LAN environment), it is interesting to consider how these three factors affect Master-Slave, Client-Server and Peer-Peer architectures. Master-Slave Master-slave systems need relatively high bandwidth, particularly for complex graphics such as maps. The server will be constantly downloading new presentations to the client, and the user is usually painfully aware of the length of time it takes to make that transfer. Often the client system cannot reasonably allow the user to do anything until the transfer is complete. Latency also needs to be very low, because the turnaround time is included in the time the system takes to respond to practically everything the user does. Reliability needs to be reasonably high, because everything depends on client-server communications, and the user is simply locked out if it fails for a period. Client-Server Bandwidth for client-server systems can usually be lower than master-slaves for the same user experience, because a more intelligent client can request data and cache it in anticipation of user needs, can manage locally-held data more intelligently so that less is actually requested of the server, and it can respond to user manipulation without communicating with the server at all for a variety of requests. Latency is also less important, because it is not always included in the time taken to respond to a user, and the more intelligent clients can eliminate a lot latency from the user’s experience by use of background processing and anticipation of user needs. Reliability of service is less critical for the same reasons, although the user does depend on an apparently continuous link. Peer-Peer Bandwidth is generally important from time to time in order to transfer large quantities of data in anticipation of user needs. However, a peer-peer system’s use of bandwidth will tend to be rather erratic, with spikes for bulk data transfer and a low background requirement for maintenance of data and other messages. Latency is usually of no real importance, because the user is only rarely concerned by when the update messages arrive at either end. Similarly reliability is only an issue during bulk transfer episodes, and indeed the link can often be broken completely for long periods without affecting the utility of the system. A peer-peer system may make effective use of more than one communications medium because of these significant swings in requirements through the life of the system. Requirements and Provision Note that a requirement for low bandwidth, reliability or high latency means the system may improve with a better link, but it is not required.
Looking at the availability of communications services that might be used for implementing an application, one could derive the following table. Note that the low-level technology is a more important consideration than the protocols used on top of it – Internet/Web protocols over a LAN have much the same characteristics as any other LAN protocols, while the same protocols used over a cellular radio link have entirely different characteristics.
Note that the characteristics of a service type maybe significantly modified by how it is used – an occasional LAN connection (such as plugging into a docking station on return to the office) will effectively have very high latency although that is not a property of the technology itself. Hardware The basic rule is that the hardware capability needs to follow the system intelligence. A master-slave system requires more processing power at the server end, and less on the client machines when compared to a client-server or peer-peer architecture. The attraction of web applications is that they are expected to run on a wide variety of platforms and hardware. There are two significant points to note, however. Firstly, if plug-ins are used, this may effectively restrict the supported platforms significantly. Secondly, most web applications effectively shift the burden of processing into a more central service provision. This may or may not be cost-effective; if users have other requirements that lead them to have the processing power available anyway, then having to provide it centrally in addition will actually raise hardware costs. Planning sut%cient capacity for reasonable peaks in demand on servers can be difficult and may result in the system being very underutilized most of the time. Equally, going to the opposite extreme of a peer-peer system can result in many copies of the same data, requiring more to be spent on data storage capacity. Functionality Any of the three architectures can be used to provide any desired level of fi.mctionality. The costs of implementing the desired fimctionality will depend on:
There are two main aspects to the security issue. One is simply the ability of unauthorized people to tap into the communications medium, either as eavesdroppers (monitoring or interfering with a legitimate connection) or as impostors (setting up a connection illegitimately). The other is the ability to make sense of what is being transferred, or to be able to interact effectively with the server once the communications security has been breached. Clearly any “public” communications medium such as the Internet or radio is timdamentally more vulnerable than direct lines or physical restrictions such as being required to plug into a LAN. There are a variety of techniques available for making communication through public media such as the network more secure, which are too various to go into any detail here. In addition,’the more generic the client software can be and the data format is, the easier it is to interpret the data that is transferred. For example, a web application that transfers standard-format images of GIS data makes the data sent orders of magnitude easier to interpret than a proprietary data format. In peer-peer solutions, where the data is carried along with the application, then security is primarily a matter of guarding against the stored data, and program, or maybe the whole computer from falling into the wrong hands. Beyond that, encryption, proprietary formats and passwords again provide the last lines of defense against unauthorized access. In applications where data needs to be returned to the host system, the need for security may be even higher, to eliminate the possibility of malicious manipulation of valuable data assets. This is liable to especially concern master-slave solutions that require little or no specialist client software – it reduces the barrier to unauthorized ability to change data. Where access and return of requires physical presence in the office or theft of field machines, it is highly unlikely that outside persons could tamper with the data. Tagging changes with user names and similar techniques will deter or allow audit in the case of problems with an organization’s own personnel. Examples Here are some discussions of how to apply the above discussion to particular applications. Providing Data to the Public There is a clear case for a master-slave, Web application here. Most users will make use of the service only very rarely. This makes the requirement to install any specialist software on the user’s system a significant barrier to use – therefore all the functionality, or as much as possible, needs to be provided by the server with only generic items like a web browser being required on the user machine. Similarly, the complexity of the application must be low enough for anyone to be able to use it without training; typically the timctional requirements for this kind of application will be relatively simple anyway. These considerations override any other issues in most cases. Providinq Data to Other Or~anizations This is a different scenario from providing data to the general public, even if the data and application requirements are likely to be the same. The web solution is still a strong contender, but the likelihood is that a specific set of people in the other organization will be making use of the information on a regular basis. In itself, this reduces the objection to users having to install any specific software. By the same token, a slightly more complex application that requires a little learning may well be acceptable or desirable. Security aspects may come in for consideration here if the data transferred should specifically not be visible to competitors or the general public. Providing partner organizations with limited numbers of CDs that require special software and/or passwords to access seems inherently secure. On the other hand, providing the information only through a web server with a firewall and a list of trusted clients with passwords etc, where only small quantities of data may be accessed at any one time may be preferable, depending on the circumstances. Finally, the donor organization may need or wish to take into account the circumstances of use of the data in its partner, raising issues similar to those listed below. Customer Service For customer service applications, making use of the most up-to-date data is important. Communications is not an issue if the representatives are office-based, and can therefore access a server over a LAN. The application may be relatively simple, or more complex, depending on the work and data flows involved. This sort of application is therefore usually best provided either with a (traditional) client-server solution or a web solution. Emergency Response Crews For emergency response, timely availability of the information is usually the overriding concern. Furthermore, the system is most likely to be critical when there is significant disruption to the normal infrastructure, for example in storm damage situations. Primary reliance on real-time communications is unlikely to be acceptable, which indicates a peer-peer or typical field solution. Augmentation of data carried with the system by updates over radio may be worth considering. Planned Maintenance With planned work, there is no real requirement for low message latency or high bandwidth, because all the necessary data can be determined ahead of time and transferred at leisure. If it is beneficial for field personnel to return to the oflice more infrequently than the planning cycle, data can be exchanged over land-line modems out of working hours, again easing the restrictions and reducing the costs of communications. Conclusion This paper has shown that at a technical level, today’s field and web applications are almost opposite ends of a spectrum in which traditional GIS is more central. That spectrum considers the relative intelligence and autonomy of the soflware residing on the user’s computer. The requirements and implications for communications, security and hardware were explained. Some arguments to propose the better solution in a number of example situations have been presented. The paper aimed to provide greater understanding the underlying issues, which will allow readers to better analyze which architecture is appropriate to which applications, leading to more implementation success. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|