a tiered architecture

Primary tabs

three tier architecture
client tier
business data tier
business logic tier

introduction

The architecture of the LIC is based on the three tier server-side architecture model. This is a way of seperating all the components that make up an application into three manageable areas.

what it is

The traditional way of simplifying problems in computerland is to define levels of abstraction, breaking down an unweildy monolith into manageable chunks. These chunks are commonly called tiers or layers. A useful approach for a distributed computer architecture is to think of it as seperated into a number of tiers.

n-tier architecture

First came two tier models.

  • client tier
  • server tier

These did not have much to do with businesses but it was better than nothing. After this came the three tier model.

  • client tier
  • business logic tier
  • business data tier

Finally there were n-tier models. The idea behind this type of model is that you can break down your particular architecture into a number of chunks that suit it, rather than being forced to use three. A typical n-tier architecture is like this.

  • presentation GUI
  • presentation logic
  • business logic
  • data access
  • data

If you have small computer systems then one application can do all this work. The programming is done in chunks using this model. The program code can then be easily reused and changed.

If you have huge computer systems, too big for one application to handle, then each tier contains one or more applications. Each application is kept simple. It does one job and presents its work in an easy-to-digest form such as an XML file, ready for another application to pick up and work on. This means that one part can be changed without messing up another. For instance, if you have a set of rules for making decisions, they are kept seperate from the programs that take the rules and make decisions. The rules can be kept up to date by an administrative team and the programs by a technical team.

The problem with this model is that business logic cannot all be kept in one place. Bits of it are spread about everywhere. This muddy compromise is easy for a human to handle but does not fit very easily into computer architectures. For a web application, some business logic is found in all these tiers. It creeps into areas like databases, web clients and web pages. Because of the technical complexity of these areas, technical staff must often implement business logic rather than the people who make the business run. The idea of an SOA (Service Oriented Architecture) has been invented to avoid this problem.

SOA (Service Oriented Architecture)

(from http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci945946,00.html)

The business logic oxymoron is not going away any time soon, but there is hope on the horizon, in the form of Service-oriented (SO) computing, which leverages Service-oriented architectures (SOAs). Fundamental to the SO approach is a separation between the business requirements and logic, defined in the form of business processes and rules -- and the technology, consisting of the infrastructure that underlies the Services layer of abstraction. In a properly architected SOA, business Services represent the data available to the business and the core functionality of the underlying systems. Business people then compose those Services into SO processes, configure the processes based upon the applicable business rules, and then expose those processes as Services that can be composed into other processes.

The important point to understand is that in a fully developed SOA, the SO processes contain all of the business logic in the enterprise. While certain programming logic will remain in the software infrastructure that supports the business Services available to the enterprise, none of the business logic remains in that infrastructure. Business users will create, configure, and compose SO processes without traditional programming languages, but instead will use tools appropriate for those users.

two tier model

two tier architecture

web browser

Java application

WAP phone

web server

application server

database server

client tier

server tier

Once upon a time, interaction of the WWW could be represented using a two tier model. There is a client tier which contains user interfaces. There is also a server tier which provides processing management and database management. Applications in the server tier provide the business logic and the storage. A simple example in the WWW of two tier architecture in action is a web browser in the client tier asking for a page and a web server in the server tier delivering that page.

Business logic is a term that relates to the components and events in a company. It describes

  • How we model real world business objects in our application - such as accounts, loans, travel itineraries etc
  • How these objects are stored
  • How these objects interact with each other - e.g. a bank account must have an owner and a bank holders portfolio is the sum of his accounts
  • Who can access and update these objects

Interfaces in the client tier provide the presentation logic. Presentation logic describes how we display these objects to a user. Do we use a drop down list or a popup screen? Do we display accounts in a list format and have the user pick which one to edit?

three tier model

three tier architecture

web browser

Java application

WAP phone

web server

application server

database server

e-mail server

client tier

business data tier

business logic tier

legacy application

ERP

The two tier model allowed people to create applications such as shopping, financial account management, and management information services on the Internet. Two tier architectures work well where management and operations of the system are not complex and processing rules do not change very often. The more complex the database server, the greater the problems with scalability and interoperability. These limitations led to the addition of an extra tier to seperate business logic from data and to link applications to other enterprise systems

The three tier model contains a client tier, a middle tier (which is similar to the server tier in the two tier model), and a back-end tier. The client tier supports a variety of client types, both outside and inside of corporate firewalls. The middle tier consists of one or more subtiers such as a web tier and an application tier. On the back end are the enterprise information systems.

One benefit of removing data from the middle tier is that the middle tier components can be replicated and load balanced, to allow greater resilience and scalability. The greater complexity is a drawback of this type of architecture: it is more expensive to maintain. For developers, the separation between client, logic and data is not always clear.

three tier model versus distributed components

distributed components

web applications

legacy applications

intranet applications

servers

business processes

mainframes

integration

front-end applications

back-end applications

middleware

databases

legacy systems

Enterprise systems can be illustrated in a similar diagram. The distributed components making up an enterprise platform can be grouped into front-end applications, middleware and back-end applications. These three sections look similar to the three sections in the three tier architecture diagram because they are different ways of looking at the same thing. These are maps showing the landmarks in an e-commerce system. One is a fun tourist map with colourful pictures of things to see and the other is an Ordinance Survey map accurate to within a nanometer. They overlap: the front end applications and the middleware applications of the distributed diagram make up the logic tier of the three tier diagram and the back-end applications make up the data tier.

what it isn't

where it is

history