Software architectures can have a big effect on facility design, especially for broadcasters. Anytime applications work with video, it is important to pay attention to how and when this demanding data is moved within the facility and how much processing power is required.
Types of architectures
Software designers have developed many architectures over the years. Different applications in a broadcast facility fall into four categories:
- Stand-alone applications run entirely on the system in front of the operator.
- Thick-client applications run on the system in front of the operator, but require access to a server or other outside connection, typically for access to data.
- Thin-client applications run primarily on a server, but have a small piece of software running on the system in front of the operator.
- Web client applications run on a server, either internal to your company or over the Internet, and are accessed via a Web browser.
Figure 1 shows each of these types of applications. Table 1 lists these four categories with a rough classification of the amount of network bandwidth consumed by the application, the relative security risk, the amount of CPU load, the amount of data access load, the amount of server CPU load and the server data access load. These architectures result in different requirements for your networks, the type of desktop computers you deploy and the types of servers required.
Stand-alone systems
In a stand-alone system, everything you need to run the application is contained on the system in front of the operator. Think about a desktop video editing application, for example. Assuming that the project you are editing is stored on the local hard disk, you can edit without a connection to any other resources. Given the lack of a network connection, no network bandwidth is required, and there is no network security risk.
However, because all of the application processing is done on the desktop, the CPU load is high. Also, all of the data is stored locally, so the local data access is high as well. An external server is not involved; therefore, the server CPU and data access loads are zero.
Thick-client systems
In a thick-client system, the client does all of the processing but it is connected to some other resource, typically a database, to access shared data. The amount of network bandwidth required by a thick client depends on the application. Most of the traffic is transactional, so the bandwidth requirements are usually low to moderate. Because the thick client requires a network connection, security is more of a concern. However, most thick-client applications connect to resources inside a corporation, so most of the security risk is mitigated by a corporate security structure.
All of the application's processing is performed by the client; therefore, the desktop CPU load is high, but the amount of data moving on the network is low to moderate. All of the data processing is done on the desktop client. As a result, the server CPU load is low, primarily consisting of user authentication and simple file transfer tasks. The server acts as the central repository for data, and most of these applications are multiuser, so the server data access load can be moderate to high depending on the number of users involved.
The thick-client application can run on a conventional desktop, and the server may not require a lot of processing horsepower. However, if the application is used simultaneously by a large number of users, the server data I/O demands may be high.
Thin-client systems
In thin-client systems, the software designer offloads processing from the desktop to the server. The goal is to allow the deployment of less expensive desktop systems, while concentrating processing power in a central server. Typical thin-client systems run a lightweight application on the desktop and do the heavy lifting at the corporate application servers. An example of a thin-client application is an airline reservation system.
Usually, the only data flowing on the network in these systems is display and keyboard data, so the required network bandwidth is low. In most cases, these applications run within a corporate environment, and sometimes the clients are dedicated to the application, making security less of a concern. However, in other applications, this data is sent across the Internet to remote thin clients.
Data sent from terminal application software is usually unencrypted, so anyone with a bridging network connection and a packet sniffer can see everything that is typed and displayed. Desktop CPU and data access are low, but server CPU load and data access load can be high, perhaps high enough to require the use of multiple servers and load-sharing schemes.
Web client systems
The Web client is an evolution of the thin client. As Web technology has become ubiquitous, many system designers have transitioned their thin-client applications to be Web-based. This means that the only client you need to access an application is a Web browser. The typical moderate- to large-size Web server application can be quite complex. You may find a Web server pulling output from several application servers, which in turn access data from various database servers.
The original idea of the Web browser was to shift the complexity and cost from the desktop to the server environment while using a readily available standardized thin client. For many years, this shift was successful. Recently, however, there has been an increasing trend to load up executable code on the Web client through ActiveX, Flash and other technologies. As a result, some of the load is shifting back to the desktop client. For example, if you browse video on your desktop, a minimalist system will not provide satisfactory results because it takes a fair amount of horsepower to decode and display video on a desktop. So, while in the past Web clients were similar to thin clients, that distinction is going away as the desktop is asked to do more.
Network bandwidth requirements for Web clients used to be relatively low, but with the increase in desktop video viewing and client side processing in Web applications, bandwidth requirements have increased. It is now common for Web clients to execute code that is delivered over the Web, so security is important. Furthermore, unless you use a VPN or a secure Web connection, the data you type into the Web browser is sent in the clear where bad guys can easily read it. The desktop CPU load used to be fairly low with Web clients, but demand has been growing, especially with desktop video applications. The desktop data access load is still relatively low.
On the server side, even moderately successful Web sites can place high demands on server systems, especially if streaming video is involved. Interestingly, video streaming applications are not CPU-intensive, even on fairly large Web sites. However, the data access load is extreme. On the other hand, search engines, online reservation systems and other processor-intensive applications can require a large amount of CPU resources in the Web environment.
Brad Gilmer is president of Gilmer & Associates, executive director of the Video Services Forum and executive director of the Advanced Media Workflow Association.
Send questions and comments to:brad.gilmer@penton.com
Stand-alone Thick client Thin client Web client Network bandwidth None Low/moderate Low Moderate Network security risk None Low Moderate/high Moderate/high Desktop CPU load High High Low Low/moderate Desktop data access load High Moderate Low Low Server CPU load None Low High High/extreme Server data access load None Moderate/high High High/extreme
Table 1. The differences between various software architectures and their effect on critical network and hardware design factors
