MULTI-TIERED ARCHITECTURE

A multi-tiered client/server application is partitioned into logical units which run in conjunction on separate machines. Multi-tiered applications share data and communicate with one another over a local-area network or even over the wide-area network. They provide many benefits, such as centralized business logic and thin client applications.

In its simplest form, sometimes called the "four-tiered model," a multi-tiered application is partitioned as follows:

Client application : Provides a user interface on the user's machine.
WEB Server : Resides in a central networking location accessible to all clients and provides server pages for clients web browser.
Application Server : Resides in a central networking location accessible to all web servers and provides common data services.
Database Server : Provides the relational database management system (RDBMS) accessible to all Application servers.

The multi-tiered database model breaks a database application into logical pieces. The client application can focus on data display and user interactions. Ideally, it knows nothing about how the data is stored or maintained. The application server (middle tier) coordinates and processes requests and updates from multiple clients. It handles all the details of defining datasets and interacting with the remote database server.

The advantages of this multi-tiered model include the following:

Work can be distributed from the desktop to more powerful application servers, which helps in addressing performance and network bandwidth requirements.

Business logic deployed on centralized servers rather than scattered user desktops makes keeping up with change easier, and reduces solution turnaround time.

Encapsulation of business rules in a shared middle tier. Different client applications all access the same middle tier. This allows you to avoid the redundancy (and maintenance cost) of duplicating your business rules for each separate client application.

Thin client applications. Your client applications can be written to make a small footprint by delegating more of the processing to middle-tiers. Not only are client applications smaller, but they are easier to deploy because they don't need to worry about installing, configuring, and maintaining the database connectivity software.

Distributed data processing. Distributing the work of an application over several machines can improve performance because of load balancing, and allow redundant systems to take over when a server goes down.

Increased opportunity for security. You can isolate sensitive functionality into tiers that have different access restrictions. This provides flexible and configurable levels of security. Middle tiers can limit the entry points to sensitive material, allowing you to control access more easily.

In the growing literature of distributed computing, confusion sometimes arises between the three-tiered architectural model and various "layered" models, which tend to identify each kind of service with a single physical layer, as well as logical layer.
This physically layered model implies a strict structure of interaction (layer to layer) that may not always be desirable. Also, the layered model tends to imply a particular deployment architecture in which each layer corresponds to a computing platform: data services on a database server, business services on one or more business servers, and user services on desktop workstations.

There are two popular layered models:

A two-layer model encourages partitioning, but is influenced by a technology platform that consists solely of a client desktop and a back-end server.
A four-layer model correctly identifies the three fundamental categories of services. However, it implies that their relationships are very structured, from a user layer to a web layer, to a business layer, to a data layer and back up the chain.

None of these implications is present in a true services model, which emphasizes a logical (conceptual) rather than a physical (deployment) architecture. In contrast to a layered approach, the services model suggests that any service may physically reside anywhere. Any service may, subject to specific functional requirements, invoke any other service. This provides a higher degree of flexibility and reusability than the physically layered approach advocated by other models.

The Services Model is Logical, not Physical

The services model describes the conceptual architecture of an application. The emphasis is logical, not physical. It shows how the application is designed, not deployed.
In the implementation phase of development, it is more likely that design tradeoffs will blur the distinction between the categories of services. For example, some business services may be implemented in the underlying database management system as triggers and stored procedures.

The term service is used to describe the functionality delivered. The term component is used to describe the packaging of one or more services in implementation.

The DynaTech consultant will guide you into the design and implementation using this state of the art technology.

With work distributed from the workstation to more powerful network servers, multi-tiered client/server architecture helps in addressing bandwidth problems.

TRANSACTION SERVER

Using transaction servers allows the task of developing application components by performing work with transactions. This protects applications from anomalies caused by concurrent updates or system failures.

Transactions maintain the ACID properties:

"A"tomicity : Esures that all the updates completed under a specific transaction are committed and made durable, or that they get aborted and rolled back to their previous state.
"C"onsistency : Means that a transaction is a correct transformation of the system state, preserving the state invariants.
"I"solation : Protects concurrent transactions from seeing each other's partial and uncommitted results, which might create inconsistencies in the application state. Resource managers use transaction-based synchronization protocols to isolate the uncommitted work of active transactions.
"D"urability : Means that committed updates to managed resources, such as a database record, survive failures, including communication failures, process failures, and server system failures comparable to the robustness of mainframe developed applications.

The intermediate states of a transaction are not visible outside the transaction, and either all the work happens or none of it does. This allows us to develop application components as if each transaction executes sequentially and without regard to concurrency.

We can declare a component as transactional, in which case Transaction Server associates transactions with the component's objects. When an object's method is executed, the services that resource managers and resource dispensers perform on its behalf execute under a transaction. This can also include work that it performs for other Transaction Server objects. Work from multiple objects can be composed into a single atomic transaction.

With this skill on-hand we at DynaTech created and tested our own Middle-Tier Server software for popular database managers available in the industry, enabling the systems we develop and deploy benefit from the use of Multi-Tier technology.