Software applications are typically described as being made up of three major components:
- The presentation component - it’s what puts the data and graphics on the users screen
- The application logic - applies business-based decisions and processes
- The storage component - stores and retrieves the data, frequently in a relational database
Client-server applications
A client-server application requires that software be installed on every user’s desktop. This software includes the presentation logic and frequently the business logic as well. The client-server application communicates with the storage component to access the requested data, but all other processing is done on the user desktop.
This approach has advantages and disadvantages. The disadvantages included the following:
- Performance could be a major problem if the desktop computer wasn’t up to the task. Insufficient disk space, slow disk drives, inadequate memory, or limited processing power can cause the application to perform at a speed unacceptable to the user.
- Software exists on every user’s desktop. If a new version needs to be installed that has to be installed as well. Obviously this takes time and effort.
- If a particular user had multiple applications loaded onto their machine the application could interact with each other and cause significant problems. Frequently, this was caused when a newly installed application installed a new version of a DLL (dynamic link library). If this new version of the DLL changed an interface that an existing application required, then the existing application could stop working. This was commonly referred to as “DLL hell.” New desktop operating systems allow the installation of multiple versions of DLLs, but there are a lot of desktops out there running Windows XP that are susceptible to this problem.
The advantages of a client-server approach are:
- By only requesting data from the storage component, the amount of information requested from the data storage tier was minimized. If you think of the screen of a typical application, what percentage is data and what percentage is everything else, e.g., background images, labels, buttons, framework, etc.? Typically, the data represents a relatively small percentage of what’s being presented to the user. Since only the active data gets pulled down from the database, the amount of information being passed between the client computer and the storage server is minimized.
- Client-server software is relatively static. It only changes when the Application Administrator or the user chooses to update it. I have seen client-server-based applications that automatically check with the vendor’s “home office” each time they are booted. If updates are available, then they are automatically downloaded.
Web-based applications
A web-based application differs from a more traditional client-server application, primarily in the presentation and application logic pieces:
- The presentation component still runs on the user workstation, but a browser, for example, Mozilla Firefox, Microsoft Internet Explorer, or Google Chrome, instead of a specialized program provided by the vendor is used as the presentation tool.
- The application logic executes on the web server instead of on the user’s workstation.
- The storage component typically doesn’t change much. It continues to run on a server dedicated to providing the database functionality.
Supporting a web-based application can be much more challenging than supporting a client-server application. The primary reasons for this is that the combined environment is more complicated that a traditional environment:
- More pieces of software are involved; for example, plug-ins, HTML, and Java script run behind the scenes to allow the application to function. Unless you’re extremely familiar with the application you won’t be aware of all the pieces involved.
- Many of these pieces are outside your control. For example, you have little control over what browser or version of browser each user has on their desktop. You can tell users over and over that application XYZ is only certified for Internet Explorer 9, but I guarantee you that you’ll have complaints from users that the application isn’t working on their computers. After you investigate it you’ll determine that they’re using Internet Explorer 10 or Opera or another unsupported server.
- Network throughput is vital. If the network is disrupted or slowed down significantly, then the application will get very sluggish, very quickly. I will advise you that the chances of the problem being the network are fairly slim. It’s very easy to blame unknown performance issues on the network, but most of the time, it turns out to be something else. Be sure you have some proof before blaming the network.
- Users employ a wide variety of computers, operating systems, and Internet browsers. All of these combinations, along with the various options for configurations of settings of the O/S and browser, make it difficult to pin down exactly what the cause of a problem is.
- Firewall and port issues can be frustrating because something that worked yesterday might be failing today. Maintaining all of the rules in a firewall isn’t easy and periodically that team will make a mistake and your application might be impacted.
Overall is it harder or easier to support a web-based application than a client-server application? It’s difficult to answer that question broadly. A lot of it depends on the applications themselves. Some are difficult to support, while others are significantly easier to work with.
Some things are easier under a web-based application and some things are more difficult. Bringing up a new user is easier because you don’t have to load software onto his or her PC. Typically, you just have to add their account to the application and give them the URL to go to within their web browser.
On the other hand, troubleshooting access or performance problems can be more difficult due to the larger number of components and interconnections. Here are just a few possible causes that you’ll have to investigate. Some of these causes apply to both client-server and web-based applications:
- Is the user entering the correct URL into the web browser?
- Is he or she using a supported browser?
- Does the user have an account in the application?
- Is the user correctly entering their ID and password?
- Is the user’s application account enabled?
- Is the user’s network account in Active Directory enabled?
- Is the firewall port between the user and the web server open?
- Is the DNS name being resolved correctly?
- Is the web server having resource issues, i.e., disk space, memory, database connections?
- Are the application’s services running on the web server?
- Is the load balancer on the web server running correctly?
- Is the firewall port open between the web server and the database server?
- Is the database server up?
- Has the application’s account on the database server expired?
- Is the database software running on the database server?
- Has the database server run out of resources, e.g., disk space or memory?
