전반적인 WEB Application에 대해서 정리해 보았다.
정리 순서는 다음과 같다.
1. WEB Application의 정의
2. WEB Application 아키텍처
3. 프레젠테이션 계층
4. 비즈니스로직 계층
5. 데이터액세스 계층
6. WEB Application이 가지는 문제
하나씩 자세히 살펴보자.
1. WEB Application의 정의
웹 애플리케이션이란
"복수의 사용자가 인터넷을 통해 데이터베이스에 접근하고 안전하게 정보를 읽고 쓸 수 있게 만들어진,
웹 브라우저와 RDB(관계형 데이터베이스)를 이용한 애플리케이션"을 말한다.
정적인 컨텐츠는 클라이언트 머신의 웹 브라우저가 네트워크에 있는 웹 서버로부터 요청한 HTML을 읽어와 표시한다.
동적인 컨텐츠는 웹 서버에서 애플리케이션 서버에 처리를 요청하고 대부분은 RDB에서 데이터를 읽어 오거나 가공하면
그 처리 결과를 웹 서버에서 받아 웹 브라우저에 표시한다.
WAS라고도 불리는 웹 애플리케이션 서버는 웹 서버의 요구에 따라 컨텐츠를 동적으로 생성하는 서버이다.
한 가지 기억해둘 점은
보통 애플리케이션 개발을 할 때 웹 서버와 웹 애플리케이션 서버를 둘 다 사용한다.WAS가 동적 자원 처리에 최적화 되어 있으며, 정적 자원을 처리하는 동안 동적 자원 처리에 지연이 발생할 수 있기 때문에
즉, WAS의 작업을 방해하기 때문에 정적인 자원에 대해서 빠른 응답을 위해 앞단 웹 서버에서 처리를 하고
동적 자원의 경우 WAS가 처리를 하는 흐름을 가진다.
**정적 컨텐츠란 HTML 파일 내부에 컨텐츠가 있는 것이며, 동적 컨텐츠는 HTML파일이 데이터베이스에 컨텐츠를 저장해 둔 것을 의미한다. 정적인 웹사이트는 컨텐츠의 변동이 없는 경우에 사용하고, 동적인 웹사이트는 컨텐츠의 변동이 많은 경우에 사용한다는 차이점이 있다.
2. WEB Application 아키텍처
Application 아키택처가 시스템 개발을 성공하는데 가장 중요한 요소 중 하나이다.
이것을 이해해야 프로젝트에서 한 사람 몫을 할 수 있고,
UML을 읽고 코딩할 수 있는 정도하면 반사람 몫을 할 수 있다고 했다.
그만큼 아키택처에 대한 이해가 얼마나 중요한지 알 수 있었다.
그리고 웹 애플리케이션 개발에서 스프링을 많이 사용하는데,
이것에 대한 이해를 바탕으로 어떠한 불편한 점이 있었고 스프링에서 그 부분을
어떤 방법으로 해결하는지 이해한다면 단순히 따라만 하는 것 보다 더 효과적이지 않을까.
애플리케이션 아키텍처는 애프리케이션 전체의 구조, 공통된 방식으로 정의된다.
다시 말해서 시스템의 애플리케이션이 공통으로 이용할 수 있는 사용자 인터페이스 구조나
데이터베이스 접근 방식 등 시스템의 기반이 되는 부분을 말한다.
이 애플리케이션 아키텍처는 크게 두 가지 목표를 가지고있다.
1. 사용자의 요구를 만족시키느냐.
2. 개발자의 입장에서 보다 편의를 추구하느냐.
물론 두 가지 모두 적절하게 만족시키는 방향이 이상적일 것이다.
웹 애플리케이션 아키텍처는 물리층인 티어와 논리층인 레이어로 구분할 수 있다.
1. 물리층을 나타내는 티어는 또 다시 '클라이언트', '중간', 'EIS' 세 부분으로 구분할 수 있다.
EIS란 Enterprise Information System으로 레거시 라기보다 기존 정보 시스템을 뜻한다고 하는게 부드러울 것 같다.
이 EIS의 대표적인 것으로 데이터베이스와 ERP를 꼽아볼 수 있다.
ERP란 Enterprise Resource Planning, 전사적 자원 계획으로기업의 목적 (이익의 극대화, 고객의 만족 등)을 달성하기 위한 일련의 활동을 한정된 자원을 사용하여
효율적으로 수행할 수 있도록 도와주는 애플리케이션 집합으로 정의할 수 있다.
2. 논리층은 나타내는 레이어는 기본적으로 중간층에 있는 웹 애프리케이션을 논리적으로 분류한 것이다.
이 레이어에서 주의할 점은, 레이어는 인접한 레이어간 단방향 액세스만 가능하야 한다는 것이다.
혹시 양방향 액세스를 하고 있다면 이것을 레이어와 혼동을 하고 있는 것이라고 ..
일바적인 레이어는 세 가지로 분류하며 각 각 다른 역할을 한다.
2-1 프레젠테이션 레이어
: 사용자 인터페이스(UI)와 컨트롤러를 제공하고 클래스 이름으로 Controller나 Action이 붙는 특징이 있다.
2-2 비즈니스로직 레이어
: 비즈니스 로직을 제공하고, 이름으로 Service가 붙은 UCD를 제어하는 클래스나 회사나 종업원, 주문 등 업무 대상의 이름이 붙은 클래스가 놓이는 특징이 있다.
: 비즈니스 로직이란 업무에 필요한 데이터처리를 수행하는 응용프로그램의 일부이다.
2-3 데이터 액세스 레이어
: 데이터베이스 액세스를 추상화한다.
: 클래스의 이름에 DAO가 붙는 특징이 있다.
3. 프레젠테이션 계층
프레젠테이션 계층은 주로 사용자 인터페이스(UI)와 컨트롤러를 제공하는 역할을 한다.
UI는 사용자가 직접 조작하는 화면을 얘기한다.
컨트롤러는 UI를 통해 사용자로부터 입력을 받아 적절한 비즈니스로직을 호출하고 그 결과를 UI로 반환하는 작업을 한다.
컨트롤러는 일반적으로 MVC2라고 불리는 JSP모델의 컨트롤러로 알려져 있다.
MVC2 모델의 경우 스몰토크에서 확립된 MVC패턴을 참고한 것으로Model 부분에 Javabeans, View부분에 JSP, Controller부분에 Servlet를 사용한다.
일반적으로 컨트롤러는 스프링이 제공하는 스프링 MVC나 스트럿츠 등의 오픈소스 MVC프레임워크에서 제공되는 것을 많이 사용한다.
** 스몰토크는 1970년대 발표된 객체지향 프로그래밍 언어로 최초로 GUI를 제공한 언어이다.
** Servlet은 java를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램이다.
** Servlet은 웹 서버의 성능을 향상시키기 위해 사용되는 자바 클래스의 일종으로 Servlet은 JSP와 비슷한 점이 있지만 JSP는 HTML문서 안에 JAVA코드가 삽입되는 반면 Servlet은 JAVA코드 안에 HTML코드가 삽입되는 차이점을 가지고 있다.
4. 비즈니스로직 계층
비즈니스로직 계층은 그 프로젝트의 성패가 달릴 만큼 중요한 계층이다.
비즈니스로직 층은 UCD로 표현되는 특정 업무나 특정 부서 처리의 통합인 서비스 및 도메인으로 구성된다.
이 비즈니스로직은 크게 두 가지 패턴을 가진다.
트랜잭션 스트립트와 도메인 모델이 그것이다.
(이 두가지에 대해서는 좀 더 자세히 공부를 하고 정리를 해둬야 겠다)
트랜잭션 스크립트는 일반적인 지침에 따르면 데이터베이스의 내용을 표시, 변경하기만 하는 업무처리.
즉, 비즈니스로직이 적은 단순 입출력 애플리케이션일 때는 로직은 전부 클래스에 포함시키고,
이 경우 도메인 이라기보다 단순히 값을 저장하는 VO나 DTO라고 불리는 오브젝트를 사용한다.
그런데 비즈니스로직이 복잡해지면 마치 구조화 언어로 만든 것처험 크고 복잡하나 비즈니스로직이 만들어 지는데
이런 일을 방지하기 위해 도메인 패키지 클래스에 도메인 로직을 두는 도메인 모델로 비즈니스로직 계층을 만들기도 한다.
다음으로 트랜잭션이란 간단히 말하자면 처리 단위를 뜻한다. 이 트랜잭션은 굉장히 다양한 종류가 있지만,
보통 데이터베이스에서의 트랜잭션을 다루는데 이 트랜잭션에는 지켜야 할 네 가지 ACID라는 특성이 있다.
(설명은 위에 적혀 있으므로 생략..)
트랜잭션의 대상이 되는 메서드가 모든 계층에 흩어져 있다면 당연히 관리가 어렵기 때문에,
보다 쉽게 관리하기 위해서 태랜잭션의 시작과 종료를 논리적인 레이어상의 경계선으로 표현한다.
이 트랜잭션의 경계를 만들기 위해 트랜잭션 구현을 어떻게 설계할 것인지가 문제이다.
그래서 이 트랜잭션은 크게 두 가지 방법으로 관리할 수 있다.
첫 번째로 트랜잭션의 시작과 커밋, 롤백과 같은 RDB에 대한 트랜잭션 관리를 소스코드에 명시하는 명시적인 트랜잭션.
두 번째로 소스코드에 직접 기술하지 않고 미리 정의된 설정 파일에 선언해서 프레임워크 등에서 제공하는 트랜잭션 처리에 의해 관리하는 선언적 트랜잭션 방법이 있다.
5. 데이터액세스 계층
데이터 액세스 계층은 기본적으로 비즈니스로직 계층으로부터 RDB 액세스를 숨기고,
비즈니스로직에 필요한 데이터를 RDB에서 가져와 오브젝트에 매핑하는 역할을 한다.
이렇게 오브젝트와 RDB를 매핑하는 것을 O/R매핑 이라고 하고 일반적으로 오픈소스 DB 액세스 프레임워크를 사용한다.
O/R 매핑은 시스템 개발 방법에 따라 O -> R, R -> O 두 가지 방법이 있다.
1. 일반적으로 O -> R 매핑은 개체지향 분석으로 엔티티를 추출해서 그 엔티티를 바탕으로 설계 단계에서 테이블을 작성한다.
2. R -> O 매핑은 DOA (Data Oriented Access)등으로
시스템의 데이터를 분석해 테이블을 작성했을 때와 시스템 개발 이전에 테이블이 이미 있을 때 사용한다.
(DOA : 데이터 중심 접근으로, 데이터 처리 시스템의 개발에서 프로그램에 의한 처리기능 보다 데이터 구조의 설계와 관리를 우선으로 하는 시스템 개발법이다.)
일반적으로 데이터베이스 액세스 프레임워크로 알려진 것은 ORM이다.
ORM은 XMl등으로 기술된 매핑파일에 의해 오브젝트와 테이블을 매핑한다.
매핑 파일 작성은 손이 많이 가지만 개발자가 SQL문을 의식하지 않아도 된다는 특징이 있다.
이 ORM의 대표적인 프레임워크가 Hibernate이며 SQL문 사용을 전제로 한 DB 액세스 프레임워크로 스프링 JDBC, MyBatis가 있다.
데이터 액세스 계층을 설계함에 있어서 지켜야 할 것에 대해 알아본다
만일 커넥션을 사용할 때마다 생성하고 해제하는 것은 효율적이지 못하다. 그래서 사용하는 것이 커넥션 풀링이다. 커넥션 풀링은 데이터베이스와 연결된 커넥션을 미리 만들어서 pool속에 저장해 두고 있다가 필요할 때 가져다 쓰고 다시 풀에 반환하는 기법이다. 이러한 커넥션 풀링 방식은 커넥션이 미리 생성 되어 있기 때문에 생성하는데 드는 연결 시간이 절약되고 계속 재사용하기 때문에 생성되는 커넥션의 수가 많지 않은 특징이 있다.
다음으로 일반적인 DB 액세스 프레임워크에서는 이용할 DB를 설정파일에서 지정하기 때문에 사용할 RDB가 바뀌어도 구현에는 영향을 주지 않는다.
마지막으로 직접 SQL문을 기술하는 방식의 DB 액세스 프레임워크에서는 특정 RDB에 의존하는 SQL문을 사용하지 않도록 주의해야 한다. 특히 주의할 것은 자동으로 증가하는 프라이머리키 생성 방법과 현재 날짜 등을 구하는 함수 등이 RDB에 의존적이다.
- 자동 증가 프라이머리키 생성 방법1. MS-SQL : IDENTITY
2. MySQL : auto_increment
3. Oracle : Sequence
- 현재 날짜1. MS-SQL : GETDATE
2. MySQL : SYSDATE(), NOW()
3. Oracle : SYSDATE
** 데이터 액세스 계층의 설계는 DB 액세스 프레임워크가 포함되어 따로 설계할 곳이 거의 없고 인터페이스 즉, 테이블과 도메인의 관계인 O/R 매핑 부분만 설계하면 된다.
마지막으로 부품화는 개발의 효율성과 유연성 향상을 위해 티어와 레이어로 구분한 것처럼 이것을 극대화 하기 위해서는 결국 애플리케이션을 부품화 해야 한다는 것을 뜻한다.
부품화에서는 인터페이스가 굉장히 중요한데, 전자제품을 예로 든다면 부품들이 콘센트와 같은 인터페이스로 연결되어 있다. 만약 이러한 인터페이스가 없다면 '네가 사용할 부품이 있다면 재주껏 납땜을 해서 사용하든지 해라'라는 말과 다를게 없다.
6. WEB Application이 가지는 문제
1. 중량 컨테이너의 사용
이번까지는 스프링이 안티 EJB의 느낌을 가지고 있었지만 EJB자체도 EJB3로 넘어가면서 DI Container, AOP Framework가 되면서 초반의 EJB라는 헤비 컨테이너에 반하는 경량급 컨테이너를 자처하고 나타난 스프링이 요즘에는 다양한 스프링 제품들이 생기면서 라이트 헤비급 정도가 되어버렸다고 한다. 그래서 EJB3와 스프링의 비교가 더 이상 큰 의미는 없다라고 한다.
2. 오브젝트 생명주기
프레젠테이션 계층에 대해 언급하면서 Servlet을 컨트롤러로 채택한 MVC2 모델을 사용하는게 일반적이라고 했는데 컨트롤러를 구현하는 Servlet은 View에 액세스 하는 사용자가 증가 할 때마다 인스턴스화에 의한 GC의 성능 저하나 메모리의 압박을 받게 되는데 이것을 방지하기 위해서 오브젝트를 싱글톤으로 구현해야 하지만, 싱글톤으로 사용하기 위해 드는 비용문제와 오랫동안 살아남으면 곤란한 오브젝트에 대한 생명주기 관리 문제가 여전히 과제로 남게 된다.
3. 부품화 문제
소프트웨어공학에 이런 말이 있다. 'loose coupling high cohesion' 낮은 결합도와 강한 응집도를 유지하도록 설계해야 한다는 것이다. 앞서 인터페이스를 사용하여 오브젝트의 호가장이나 변경을 유연하게 대처할 수 있고 이렇게 해서 시스템의 품질을 높일 수 있다고 했는데 레임워크를 사요하지 않고서는 테크닉이 필요할 뿐만 아니라 인터페이스 만을 가지고서는 한계가 있다. 그래서 팩토리 메서드 패턴을 적용해서 해결하기도 하지만, 이러한 장치를 아예 모르거나 비용 문제로 높은 품질을 기대하기는 어려운 문제를 여전히 가지고 있다.
** 팩토리 메서드 패턴 : 자바의 리플랙션 기능을 사용해서 new연산자를 사용하지 않고 인스턴스화 하는 기술
** 자바 리플랙션 : 객체를 통해 클래스의 정보를 분석하여 컴파일 시기가 아닌 런타임 시기에 동적으로 특정 클래스의 정보를 추출하는 기술
4. 기술 은폐
개발자의 수준을 고려하지 않은채 고급기술을 초보 개발자가 사용할 수 있게 되어 문제가 발생하거나 (예를 들면, 트랜잭션 제어에 접근하여 예외처리 순서가 꼬여버린다거나..) 트랜잭션 제어와 같은 기술을 은폐하기 위해서 프레임워크를 만들었지만 사용정차가 복잡하여 사용하지 않게 되는 경우가 있다.
요약한다면
1. 오브젝트 생명주기 관리는 어떻게 해야 하는지.
2. 부품화는 어떻게 할 것인지.
3. 기술 은폐는 어떻게 하는게 좋을지.
그래서 이 문제는 해결하기 위해 등장(?)한 프레임워크, 바로 스프링을 사용하면 된다는게 결론(?)이다.
오브젝트 생명주기는 스프링 컨테이너에게, 부품화는 의존성 주입(DI) 에게, 기술 은폐는 관점 지향 프로그래밍(AOP)에게.
음..
마치 약은 약사에게 진료는 의사에게 .. ?