We are a Microsoft certified solution provider and authorized partner. We provide integration services for Microsoft
Cloud products such as Office 365, Azure, and Dynamic CRM. Microsoft Office 365 is
the secure Cloud service for anywhere, anytime access to professional email, shared calendars,
instant messaging, video conferencing, document collaboration, and much more.

Connect with us
at

Client/Server Application

ZHTECH is experienced in developing fast, stable, and flexible Client/Server
applications. The Client/Server systems include customed 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. 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 ServicesUser 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 ServicesThe 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 ServicesData 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.