Andy Kramek

Introduction to Client Server Applications

Following my post about Client Server architecture, it seems logical to take a look at how we go about building an application using that architecture. So here goes…

The Challenge

Perhaps the biggest conceptual change that most VFP Developers have to make when contemplating the Client/Server architecture is the requirement for maintaining the complete separation of the various tiers. This is something that, in the Visual FoxPro environment, we do not really pay much attention to – mainly because of the tight integration that VFP provides between the database, the programming language and the GUI. The result is that many, if not most, VFP applications have historically been built as "single tier" (or "monolithic") applications in which everything is compressed into the GUI. In other words, the FORM is responsible for everything including opening and closing data files, navigation, inserting and updating data.

This type of design (or lack of it!) is simply not possible when we have to use a remote database as the primary data store. The reality is that this single decision means that we have to completely re-think the way in which our applications are designed and built.

Defining Responsibilities

As with all design tasks, the first thing to do is to actually define the problem. In this case it is really quite simple – we need to know what responsibilities our application has and then identify where, in a three-tier architecture, they need to be located. The following list is by no means exhaustive but indicates the key responsibilities which can be applied to any application.

• Connect to the Database             Without a connection to the database the application can do nothing at all. This is closely related to, and bound up with the next responsibility
• Manage Security                        Security management can exist at many levels. But we need to differentiate between "Access" control (can the user get into the application, or the database) and "Functional" control (can the user see this menu item, or certain data fields or reports)
• Interact with Users                     Unless this is a pure data processing application we will need some form of interaction with our users. The amount of functionality that is built into the user interface will often be determined by the type of interface that is required. For example, a stateless browser based application generally has a less User Interface capabilities than a form based one (irrespective of the language used to create the forms)
• Access and Manipulate  Data       Quite apart from the requirements of security we need to consider how data is going to be accessed and manipulated. We cannot simply assume that the 'form' will do it and we certainly do not want to duplicate code for handling basic processes like saving changes, or adding new records.
• Handle Errors                            By introducing separated tiers we now have the problem that errors can occur in places where we cannot simply pop up a message box! Some form of structured error handling is needed to ensure that errors are 'bubbled' up to the user interface, and possibly also transmitted back to the database for logging/storage
• Validate Data                             The simplest form of validation is that data saves without error. However, when dealing with a remote data store it is vitally important that data is properly validated before it goes to the back. This needs to be handled either in the UI ("assistive validation") or in the middle tier ("rules validation").

Allocating Responsibilities

The conventional design for a Client/Server application, as we have already seen, involves three tiers. These are typically referred to as the UI (or 'Presentation') Tier,  the Middle ( or 'Rules') Tier and the Data (or 'Database') Tier. Given these tiers it is obvious where certain responsibilities must lie. Managing Application security and handling User Interaction and are obviously UI responsibilities, while the responsibility for connecting to, and manipulating, data obviously belongs in the Middle Tier. The task of actually storing and retrieving  data, together with the management of database security and referential integrity obviously belong to the Data Tier.

However that leaves us with Error Handling and Data Validation, neither of which can be definitively assigned to a single tier because both responsibilities impact multiple tiers. An error can occur in any tier but all user interaction must be handled by the UI Tier – so error information, irrespective of the source, must be displayed by the UI. Conversely, it is usual and customary to log errors when they occur in some form of persistent storage. That will require the involvement of both middle and data tiers and so the error handling system really does have to be spread across all three tiers.

Validation is another example of a responsibility that needs to be handled at different levels within the application. The UI (even the simplest) should handle the primary 'assistive' validation tasks. These include ensuring that all required data is present before allowing a save to be initiated, and enforcing  specific formatting to data elements (like Account Numbers). In other words, doing whatever is necessary to ensure that only valid data elements are sent from the UI to the middle tier.

The application of Business Rules must be handled in the middle tier. The reason is twofold. First, business rules should never be implemented in the database because a database may have to serve multiple applications and a single element of data could require different rules in different applications. Second, because the set of Business Rules applicable to any application is independent of the User Interface used to implement them. The only logical place, therefore, is to implement such rules in the middle tier – hence its alternate name as the "rules" tier.

The database is, of course, going to be responsible for enforcing data integrity rules. Typically these will be done by defining constraints and relationships and applying unique indexes on columns.

It should be clear, by now, that the design of a Client/Server application is radically different from that typically used for file-server applications. It is also considerably more complex and requires more code, which begs the question, is it really worth it?

Why Bother with Client/Server

The main advantages offered by the Client/Server architecture can be summarized into a number of key topics. However, as with anything, there are also disadvantages.

Advantages

Data Security

This is perhaps the main reason why existing applications are converted from file server based to Client/Server. The problem is that file server systems in general, and visual foxpro based applications in particular, are vulnerable at a number of levels. Quite apart from the possibility of unauthorized access (i.e. hacking) DBFs suffer from a number of limitations that, in a controlled and protected environment are manageable but which in a more open environment become serious drawbacks. These include

• Associated files (CDX, FPT) prone to corruption
• Data files easily accessed read by external programs/third party tools
• No persistent transaction logging/recovery
• No native backup/restore functionality
• Hard to maintain because many 'admin' operations require exclusive use of tables

Performance/Scalability

While VFP is undoubtedly very quick and has excellent data access capabilities, it is workstation based and that means that all data must be transferred to the workstation. This can become a serious issue not just as data volumes increase, but also as the number of users increases, or on high traffic networks and where connectivity bandwidth is limited. By transmitting only requests and result sets over the network, instead of the raw data a Client/Server system can significantly reduce the amount of traffic.

Moreover, by running a dedicated application to handle the data queries, computing power can be optimized at the server rather than at the client level. This not only reduces financial cost (by reducing the hardware requirements for client machines) but also improves the scalability of the application. Since the server now the primary working machine (rather than the client) capacity can be increased by upgrading the server hardware without the necessity to alter the application code in any way.

Portability

Along with improvements in scalability the Client/Server architecture dramatically improves the portability of an application. The separation into three tiers can effectively remove implementation dependencies from the application. A well built Client/Server system is both database independent (in other words it is possible to change the back end without altering the application code) and user interface independent (the same middle tier can be accessed from a browser, or a VFP Form). This is a major consideration when designing a vertical market application where it is may not be possible to prescribe either hardware or software.

Resource Utilization and System Maintenance

The breaking of an application into separate tiers offers significant benefits in terms of system resource utilization and maintenance. In day-to-day terms, perhaps the most significant benefit is that individual users need not have their own accounts in the database. While this is rarely an issue when there are only a few users in the system, applications that have to be accessed by hundreds, or even thousands, of users pose a real problem from the system administration perspective.

Not only do all these users need to have their own accounts (with user IDs and passwords) but they have to be maintained as the user population changes with time. Plus, of course, if each user were to connect directly to the database the server workload increases because of the need to keep multiple connections alive and to keep polling for requests even when an individual connection is idle.

By routing all user interaction through a middle tier not only is the actual number of connections minimized, but the necessity for maintaining individual user accounts on the database is removed because the only 'user' who actually needs to connect is the middle tier

Disadvantages

The two main disadvantages of Client/Server systems are complexity and cost.

Complexity

Complexity exists at two levels.

• First there is the inherent complexity in dealing with an application that spans multiple tiers. As indicated above in the discussion of responsibilities, issues like error handling are much more complex because of the requirement to maintain the integrity of each tier's function. The separation into discrete tiers also means that functionality that in conventional VFP applications would be handled as a single task may actually have to be split into multiple operations. For example it is not unusual to see, in a VFP application, a form method that processes all records in a table and reports progress to the user as each record is processed. This would be much more complex to code in a Client/Server environment because of the increased messaging required to communicate between the tiers.
• The second level of complexity also arises out of the separation of the application into tiers. Building and testing a Client/Server application is more complex than a simple file-server application because of the need to establish and maintain the connections between the tiers (even if they are on the same physical machine, the tiers are logically separated and will always involve at least two software packages, and often more).

Cost

Client/Server systems are likely to be more expensive to build and implement for several reasons.

• First, there are direct costs for application software, database software and the associated user licenses. Although the increasing capabilities of the "open source" databases like MySQL have done much to mitigate this factor in recent years.
• Second, there are the hardware costs, typically a Client/Server application will require at least one, and often two servers (the data server and the application server) together with all the associated items (backup devices, disk arrays/mass storage devices, uninterruptible power supplies and network infrastructure).  In mission critical, or high availability, environments backup hardware with mirroring or fail-over capability may also be needed.
• Third, not only is there more hardware required to support a Client/Server application, because the majority of the processing is handled by the server, but that hardware also has to be much more capable (i.e. more expensive) than a simple file server. You can get away (almost!) with using a realtively low end PC with lots of disk space as a file server, but you certainly can't use that type of machine for a database server.
• Fourth, the initial development costs will also be greater than for a simple file server based application. This is partly due to the need to build the functionality into separate components, but also due to the greater complexity of those components. The effort required at all stages of the development life cycle, Design, Coding and Testing is significantly greater for a Client/Server application than for an equivalent file server application.
• Finally, there are personnel costs. Maintaining a DBF based application does not require any great level of specialized knowledge but running a major SQL Server, or other back end, database is a highly specialized task. Database Administrators are skilled specialists and, like all speicialists, are (relatively) expensive

Is it really worth it

The only possible answer is, of course, that it depends on the application. However it is generally true that in any environment that will involve more than a few users, the advantages of the Client/Server architecture far outweigh the  disadvantages – which is precisely why it has been so widely adopted and why there have been no significant changes to the architecture for many years.