Client/Server Application

There are three key components to every Client/Server system. The foundation of any application is the database. It is crucial that the database design support both the transactional and reporting needs of your business. The next building block is the custom server. It must be robust and be able to support high numbers of clients as well as standard communication protocols such as TCP/IP. Finally, the client or user software must be designed with the end-user in mind. ZHTECH can help you deploy Client/Server applications that will meet your needs as well as your end-users'.

Two (2) tier Client/Server.
Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfills the request. The Client/Server paradigm has been used by programs executing on the same computer, but typically an application is written that executes on one computer and request information from an application running on a separate computer.

The network provides the mechanism used to interconnect programs that are distributed across different locations - whether in the same building or in different regions entirely. Most businesses have been using and developing C/S applications since the late 1980's. A typical example of a C/S application is a web browser. The client (web browser) sends a request to a server application running on another machine somewhere. The server receives the request, retrieves the necessary information - in this case a web page, and returns the information to the client application. The client application is responsible for displaying the data returned from the server in a format acceptable to the user. Most client/server applications in the past employed this architecture. One of the primary problems with this format arises because all business logic and validation must occur on the database, or the client computer. This can lead to bloated client applications that do most of the validation. If a validation rule changes, then the application must be re-compiled and deployed to your user base. If your user base is substantial, this can be a major problem.

The following diagram outlines a typical two-tier client/server application.

N-tier Client/Server.

N-tier Client/Server architecture involves three or more computers to get any real work done. There are three primary components to n-tier client/server development. Each is outlined below. A simple diagram is also provided that shows a minimal n-tier client/server architecture.

User Services
User services are normally contained in the user application (installed locally on user machine) and provide a common interface into the application. This can be a simple form, a group of standardized dialogs, a web interface, or something more esoteric. It should be noted that the user services can perform some standardized business logic. Not all business logic will reside in the business services layer. For example, displaying numbers based on local settings is one example. The user services provide the primary means of doing business within a company. The business logic may be encapsulated in components of the business services tier but the user services component enables the user to have access to the entire process. Components built in this layer are responsible for requesting data and information from other components in the user services layer or the business services layer. One method that many companies utilize is the ability to share common dialogs and/or error messages.

Business Services
The business service layer is responsible for implementing business rules that are specific to a company or procedure and they act as a bridge between the user services layer and the data services layer. The user services layer cannot directly interact with the database but needs a mediator - hence, the business service layer. The business layer provides services to verify data input. This verification can take on many forms. It could verify a credit limit, an address, zip code, routing information, payment history, etc. In a standard two-tier client/server application, all of the code was placed in the user services (client application) or placed on the database server. With n-tier architecture, the business services/business rules are deployed in a separate layer. This makes it much easier to modify the business rules as your business rules change. The old method generally required a re-compile of the client application and modification of code on the database. Now, the only code that changes is in the business services tier. Additionally, these components can be reused by other applications that may require them. This reduces the amount of redundant codes that exist between projects within your organization. Business services can themselves connect to other business services running on the same machine or to another machine on the network. Using business components also allows the application to scale horizontally with minimal effort. This means that you can add more machines running your business services objects, have groups of users connect to different servers, and avoid a potential bottleneck.

Data Services
Data services involve all the typical data chores, including the retrieval and modification of data as well as the full range of other database-related tasks. The key to data services is that the rules of business are not implemented here. Although a data service component is responsible for managing and satisfying the requests submitted by a business component, or even a fellow data services component, implementing the rules of business is not a responsibility.

The following diagram outlines a very simplistic n-tier layout. The network server is not shown. It's assumed that it is already in place.