In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client–server architecture in which presentation, application processing, and data management functions are logically separated. For example, an application that uses middleware to service data requests between a user and a database employs multi-tier architecture. The most widespread use of multi-tier architecture is the three-tier architecture.
N-tier application architecture provides a model by which developers can create flexible and reusable applications. By segregating an application into tiers, developers acquire the option of modifying or adding a specific layer, instead of reworking the entire application. Three-tier architectures typically comprise a presentation tier, a business or data accesstier, and a data tier.
While the concepts of layer and tier are often used interchangeably, one fairly common point of view is that there is indeed a difference. This view holds that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure.[1] [2]
There have been growing concerns in recent years that many organizations are facing an excessive number of layers in their multi-layered architecture. These concerns stem from sprawling application architectures that are not well designed or managed, in which development teams create an ever-growing number of "wrapper" layers that compromise maintainability. The resulting architecture resembles a Rube Goldberg Machine that scares organizations from solving the root cause of the sprawling layers, resulting in the creation of more layers.
[edit]Three-tier architecture
Visual overview of a Three-tiered application
Three-tier[3] is a client–server architecture in which the user interface, functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms. It was developed by John J. Donovan in Open Environment Corporation (OEC), a tools company he founded in Cambridge, Massachusetts.
The three-tier model is a software architecture and a software design pattern.
Apart from the usual advantages of modular software with well-defined interfaces, the three-tier architecture is intended to allow any of the three tiers to be upgraded or replaced independently in response to changes in requirements or technology. For example, a change of operating system in the presentation tier would only affect the user interface code.
Typically, the user interface runs on a desktop PC or workstation and uses a standard graphical user interface, functional process logic that may consist of one or more separate modules running on a workstation orapplication server, and an RDBMS on a database server or mainframe that contains the computer data storage logic. The middle tier may be multi-tiered itself (in which case the overall architecture is called an "n-tier architecture").
Three-tier architecture has the following three tiers:
- Presentation tier
- This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network.
- Application tier (business logic, logic tier, data access tier, or middle tier)
- The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.
- Data tier
- This tier consists of database servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.
[edit]Comparison with the MVC architecture
At first glance, the three tiers may seem similar to the model-view-controller (MVC) concept; however, topologically they are different. A fundamental rule in a three tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middle tier. Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the view sends updates to the controller, the controller updates the model, and the view gets updated directly from the model.
From a historical perspective the three-tier architecture concept emerged in the 1990s from observations of distributed systems (e.g., web applications) where the client, middle ware and data tiers ran on physically separate platforms. Whereas MVC comes from the previous decade (by work at Xerox PARC in the late 1970s and early 1980s) and is based on observations of applications that ran on a single graphical workstation; MVC was applied to distributed applications later in its history (see Model 2).
Today, MVC and similar model-view-presenter (MVP) are Separation of Concerns design patterns that apply exclusively to the presentation layer of a larger system. In simple scenarios MVC may represent the primary design of a system, reaching directly into the database; however, in most scenarios the Controller and Model in MVC have a loose dependency on either a Service or Data layer/tier.
[edit]Web development usage
In the web development field, three-tier is often used to refer to websites, commonly electronic commerce websites, which are built using three tiers:
- A front-end web server serving static content, and potentially some cached dynamic content. In web based application, Front End is the content rendered by the browser. The content may be static or generated dynamically.
- A middle dynamic content processing and generation level application server, for example Ruby on Rails, Java EE, ASP.NET, PHP, ColdFusion, Perl platform.
- A back-end database or data store, comprising both data sets and the database management system or RDBMS software that manages and provides access to the data.
[edit]Other considerations
Data transfer between tiers is part of the architecture. Protocols involved may include one or more of SNMP, CORBA, Java RMI, .NET Remoting, Windows Communication Foundation,sockets, UDP, web services or other standard or proprietary protocols. Often middleware is used to connect the separate tiers. Separate tiers often (but not necessarily) run on separate physical servers, and each tier may itself run on a cluster.
[edit]Traceability
The end-to-end traceability of data flows through n-tier systems is a challenging task which becomes more important when systems increase in complexity. The Application Response Measurement defines concepts and APIs for measuring performance and correlating transactions between tiers.
Generally, the term tiers is used to describe physical distribution of components of a system on separate servers, computers, or networks (processing nodes). A three-tier architecture then will have three processing nodes. Layers refer to a logical grouping of components which may or may not be physically located on one processing node.
[edit]See also
[edit]External links
[edit]References
- ^ Deployment Patterns (Microsoft Enterprise Architecture, Patterns, and Practices)
- ^ Fowler, Martin "Patterns of Enterprise Application Architecture" (2002). Addison Wesley.
- ^ Eckerson, Wayne W. "Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client Server Applications." Open Information Systems 10, 1 (January 1995): 3(20)
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.
다층 구조(Multi-tier Architecture 또는 n-tier Architecture)는 비즈니스 로직을 완전히 분리하여 데이터베이스 시스템과 클라이언트의 사이에 배치한 클라이언트 서버 시스템의 일종이다. 예를 들어 사용자와 데이터베이스간의 데이터 요구 서비스에 미들웨어를 이용하는 것을 들 수 있다. 일반적으로는 3층 구조가 널리 쓰인다.
[편집]3층 구조 (3-Tier)
세 층이란 사용자 인터페이스, 비즈니스 로직, 데이터베이스를 말하며, 이들을 각각 독립된 모듈로 개발하고 유지하는 구조로, 일반적으로 이들은 각각 다른 플랫폼 상에서 구동된다.
3층 구조는 2층 구조의 제한을 극복하기 위해서 탄생한 구조로, 사용자 인터페이스 환경과 데이터베이스 관리서버 환경 사이의 중간층이 추가된 구조이다. 중간층의 구현은 트랜잭션 처리 모니터, 메시지 서버, 응용 서버 등 여러 가지 방법으로 구축될 수 있다. 이러한 중간층은 데이터베이스의 다단계나 응용프로그램의 실행 또는 사용자 요구 분산을 위한 큐잉을 수행할 수 있다. 예를 들어, 중간층이 큐로써 역할을 한다면 클라이언트는 자신의 요청을 중간층에 전달만 하고 중간층이 서버에 접속해서 클라이언트가 남기고 간 요청에 대한 응답을 받아 클라이언트에 돌려줄 것이다. 이러한 중간층의 역할은 스케쥴링을 가능하게 할 뿐만 아니라, 다수 사용자 요구 처리에 대한 우선 순위를 정할 수 있게 해주어 서버의 부하를 줄여준다.
3층 구조는 아래의 세 층으로 나뉘어 있다.
[편집]프레젠테이션 계층
프레젠테이션 계층은 응용 프로그램의 최상위에 위치하고 있는데 이는 서로 다른 층에 있는 데이터 등과 커뮤니케이션을 한다.
[편집]애플리케이션 계층
이 계층은 비즈니스 로직 계층 또는 트랜잭션 계층이라고도 하는데, 비즈니스 로직은 워크스테이션으로부터의 클라이언트 요청에 대해 마치 서버처럼 행동한다. 그것은 차례로 어떤 데이터가 필요한지를 결정하고, 메인프레임 컴퓨터 상에 위치하고 있을 세 번째 계층의 프로그램에 대해서는 마치 클라이언트처럼 행동한다.
[편집]데이터 계층
데이터 계층은 데이터베이스와 그것에 액세스해서 읽거나 쓰는 것을 관리하는 프로그램을 포함한다. 애플리케이션의 조직은 이것보다 더욱 복잡해질 수 있지만, 3계층 관점은 대규모 프로그램에서 일부분에 관해 생각하기에 편리한 방법이다.
[편집]바깥 고리
다층 구조 (답니다 아키텍처, 영어 : Multitier architecture )는 응용 프로그램이 여러 소프트웨어 에이전트 에 의해 실행되는 클라이언트 서버 모델 의 한 형태이다. 예를 들어, 사용자와 데이터베이스 사이의 데이터 요구 서비스에 미들웨어 를 사용하는 응용 프로그램은 다층 구조이다. 가장 많이 사용되는 다층 구조는 삼층 구조이다.
삼층 구조 [ 편집 ]
클라이언트 서버 모델 의 "삼층"는 사용자 인터페이스 , 비즈니스 로직 , 데이터베이스 (데이터 액세스)이며, 그들이 독립적 인 모듈 로 개발 · 관리되고, 많은 경우 서로 다른 플랫폼 에서 작동한다. "삼층 (three-tier 또는 three-layer) '이라는 용어와'다층 구조"라는 용어는 합리적인 를 기원하는 [ 요청 출처 ] .
삼층 모델은 소프트웨어 아키텍처 이자 디자인 패턴 이기도하다.
인터페이스를 올바르게 정의 된 모듈화 된 소프트웨어 라는 의미에서의 장점뿐만 아니라 삼층 구조는 기술 의 진보와 요구에 맞게 계층을 개별적으로 교체 할 수있다. 예를 들어 클라이언트의 운영 체제 를 Microsoft Windows 에서 UNIX 로 변경하고, 그것은 사용자 인터페이스 계층에만 영향을주지.
사용자 인터페이스는 데스크톱 PC 나 워크 스테이션 에서 표준 GUI 를 사용하여 작동하는 것이 일반적이다. 비즈니스 로직은 하나 이상의 모듈로 구성된 워크 스테이션 및 응용 프로그램 서버 에서 실행한다. 데이터베이스는 서버 나 메인 프레임 의 RDBMS 가 사용된다. 중간 계층 자체가 다층화 될 수도있다.
삼층 구조에서 각층의 명칭은 다음과 같다.
- 프레젠테이션 계층
- 응용 프로그램 계층 / 논리 계층 / 비즈니스 로직 계층 / 트랜잭션 레이어
- 데이터 계층
MVC 아키텍처와 비교 [ 편집 ]
언뜻, 삼층 구조는 Model View Controller (MVC)에 비슷하다. 그러나 토폴로지으로 다르고, 적용 분야도 다르다. 삼층 구조의 기초로 프레젠테이션 계층은 결코 데이터 계층과 직접 통신한다. 즉, 모든 통신은 반드시 중간 계층을 통과한다. 따라서, 삼층은 하나의 직선으로 표시된다. 반면 MVC는 3 개가 각각 서로 통신하기 위해 삼각형을 형성하고있다. 삼층 구조는 데이터베이스와 사용자 간의 정보 경로를 나타내고있는 반면, MVC는 사용자 인터페이스의 화면 구성 요소의 관리 방법을 나타내고있다. MVC 기반 구성 요소는 삼층 구조의 응용 프로그램에서 자주 사용된다.
역사적으로 보면, 삼층 구조는 1990 년대에 태어났다. 이것은 Web 응용 프로그램 등의 분산 시스템에서 클라이언트, 미들웨어, 데이터베이스의 3자가 각각 물리적으로 다른 플랫폼에서 동작하게 된 것으로부터 생긴 것이다 (즉, 구현이 먼저 있고 나중에 개념으로 추상화 된). 한편, MVC는 1980 년대 ( 팔로 알토 연구소 에서 1970 년대 말부터 1980 년대 초까지의 수)에 하나의 그래픽 워크 스테이션에서 실행되는 응용 프로그램 제품군의 구조에서 태어났다. MVC가 분산 응용 프로그램에 적용되는 (컨텐츠 및 프레젠테이션 분리 된)은 더 후의 일이다.
Web 개발에서의 이용 [ 편집 ]
Web 개발 분야에서는 삼층 모델은 웹 사이트 , 특히 전자 상거래 웹 사이트의 구성에 대한 설명에 사용된다. 그 경우, 각 층은 다음과 같다.
- 프레젠테이션 계층 : 변하지 않는 콘텐츠를 공급하는 Web 서버
- 중간 계층 : 동적 콘텐츠를 생성하는 응용 프로그램 서버 . 예를 들어 Java EE 플랫폼 등.
- 데이터 계층 데이터베이스 및 관리 시스템. RDBMS 등.
참고 문헌 [ 편집 ]
관련 항목 [ 편집 ]
이 기술은 GNU Free Documentation License 근원에 공개되는 컴퓨터 용어 사전 " Free On-line Dictionary of Computing (FOLDOC) "에 근거하고 있습니다.
