ZHTECH are experienced in developing fast, stable, and flexible Client/Server applications. The Client/Server systems include custom multi-threaded server applications that connect to dedicated databases, as well as client software packages that communicate with the server using a variety of protocols. We employ Microsoft's suite of development tools to deliver these powerful systems.

There are three key components to every Client/Server system. The foundation of any application is the database, and it's 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 location - 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 today employ 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. These elements will typically be created as an Activex DLL or Activex EXE and deployed on the users machine or another machine that the client application has access to. These components can then be used by client applications as needed. It's worth mentioning that if you do use Activex DLL/EXE's as additional user services, then displaying any type of message should be avoided. If the Activex DLL/EXE's are deployed on the same machine as the client application, then the user will see the message box correctly. If the component is created as an EXE and deployed on another machine, then any message displayed intended for the user will display on the remote machine and will NOT appear on the client applications screen.

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 can not directly interact with the database and so needs a mediator - hence, the business service layer. The business layer provide 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 and was implemented via stored procedures or triggers. 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 rule change. The old method generally required a re-compile of the client application and modification of code on the DBMS. 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 code 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 allow the application to scale horizontally with minimal effort. This means that you can add more machines running your business services objects and 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.

Data services can be implemented as objects in a particular database management system (DBMS) in the form of triggers or stored procedures. Alternatively, the data services could provide access to heterogeneous data sources on multiple platforms on any number of servers or mainframes. A properly implemented data services tier should allow changes to take place in the data services tier and related data sources without affecting the services being provided to business services components.

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.