::: 한량모드 발동!! :::

출처 : http://blog.naver.com/wonie777/120005952872

웹 어플리케이션에서는 기존의 MVC Model를 MVCD(Model-View-Controller-Dispatch) 또는 MVC Model 2+1 라고 불러야 한다는 소리가 있다. 그 이유는 웹 어플리케이션에서는 View 화면이 Controller에 의해서 Dispatch되기 때문이다.

MVC에는 다음과 같은 특징이 있다.

• 역할 : 프리젠테이션 계층은 말 그대로 사용자 인터페이스에 불과하다. 식당을 예로 들면 손님이 접하게 되는 메뉴판과 전달될 음식을 차려놓는 식탁에 해당한다.
  
• 기능 : 사용자가 선택할 수 있는 기능이 표시되어 있어야 하고, 요청에 필요한 부가적인 정보 전달을 위한 입력 양식이 있어야 한다. 또한 전달된 자료를 효과적으로 보여주기 위한 프리젠테이션 로직이 포함된다. 하지만 비즈니스 로직이나 퍼시스턴스 계층에서 처리하는 일을 직접 수행하거나(스크립트 릿 사용), 각 계층의 컴포넌트와 직접적인 통신이 있어선 안된다.
  모든 요청은 제어 계층을 통해 처리되어야 한다는 뜻이다. 고급 레스토랑(엔터프라이즈 시스템)에서는 웨이터(지배인)를 통해서만 요구를 전달하고, 그 결과를 전해들어야 한다. 직접 주방장에게 주문을 하거나 자기가 직접 요리를 하는 것은 자기 집(프로토타입)이나 동네 자장면 가게(소규모 웹 애플리케이션)에서나 가능한 일이다.
  
• 대안 기술 : 현재 가장 주류를 이루는 기술은 JSP 1.2와 JSTL과 같은 태그 라이브러리를 결합하는 방식이다. 과도기적인 형태로 벨로시티와 타일즈 태그 라이브러리가 결합된 형태도 현재 주목을 받고 있다. 하지만 점차적으로 JSF에 기반한 JSP 2.0에 주류 기술로 옮겨갈 가능성이 크고, 프리젠테이션 계층 개발에 있어서도 JSF를 지원하는 IDE를 채택하는 경우가 늘어날 것이다.
  
• 주요 패턴 : Composite View 패턴
  

제어 계층

• 역할 : 제어 계층은 프리젠테이션 계층과 비즈니스 로직 계층을 분리하기 위한 컨트롤러를 제공한다. 식당으로 치자면 지배인의 역할과 종업원의 역할을 병행하는 것이라고 볼 수 있다.
  
• 기능 : 전체 시스템의 설정 상태를 유지해야 하며, 그를 통해 어떤 요청이 들어왔을 때 어떤 로직이 처리해야 하는지를 결정한다. 사용자 요청을 검증하고 로직에 요청을 전달하는 일과 로직에서 전달된 응답을 적절한 뷰에 연결짓는 것 역시 제어 계층의 몫이다.
  손님이 바다가재 요리를 요청했을 때 종업원은 그 요리가 서비스 가능한 것인지 또한 누구에게 시키면 되는지를 알고 있어야 한다는 뜻이다. 요청을 전달받은 요리사가 바다가재 요리를 주면 그것을 식탁까지 운반해 주는 것 역시 종업원의 몫이다. UI 검증, 요청 및 응답 전달, 로직에서 던져진 예외 처리, 도메인 모델을 뷰와 연결하기 등의 고유 기능 외에는 어떤 기능도 포함하지 않는다.
  
• 대안 기술 : 현재 WAF들은 대부분 제어 계층의 핵심 기능을 포함한다. 터빈이나 에스프레소 등이 선전하고 있지만, 스트럿츠와 웹워크가 대세라고 생각된다. 당분간 별다른 대안 기술이 등장할 가능성은 적다. 오히려 스트럿츠를 확장시켜 자사 고유의 프레임워크로 최적화 시키는 작업이 활발히 진행될 것이다.
  
  ◆ 주요 패턴 : Front Controller 패턴, Service to Worker 패턴(또는 Command 패턴), Intercepting Filter 패턴, Application Controller & Context Object 패턴
  

비즈니스 로직 계층

• 역할 : 비즈니스 로직은 말 그대로 핵심 업무를 어떻게 처리하는지에 대한 방법을 기술하는 곳이다. 식당에서 종업원이 고객의 요구를 전달해 주면, 재료를 이용해 요리를 만드는 요리사라고나 할까? 비즈니스 로직 계층은 애플리케이션에서 가장 재사용될 확률이 높은 요소이기 때문에 신경 써서 설계해야 한다.
  
• 기능 : 비즈니스 로직에는 핵심 업무 로직의 구현과 그에 관련된 데이터의 적합성 검증 외에도 다양한 부가적인 구현이 추가된다. 트랜잭션 처리라든가, 다른 계층들과 통신하기 위한 인터페이스를 제공한다거나, 해당 계층의 객체들간의 관계를 관리하는 것 등이 그것이다.
  비즈니스 로직 계층에 있어야 할 코드들이 프리젠테이션 계층이나 퍼시스턴스 계층에 여기저기 흩어져 있는 애플리케이션을 찾아보기란 그리 어려운 일이 아니다. 이런 구조는 각각의 계층을 모호하게 만들어 유지보수시 많은 시간을 필요로 하게 만든다.
  가장 신경 써서 개발해야 할 비즈니스 로직에 그동안 신경을 쓰지 못했다는 것. 프리젠테이션 계층과 퍼시스턴스 계층 사이의 다리 역할을 충실히 하도록 함으로써 애플리케이션에 유연성을 더하는 것. 그것이 스프링이 탄생하게 된 배경이라고 할 수 있다.
  
• 대안 기술 : 지금까지 비즈니스 로직의 구현은 크게 EJB를 사용하는 것과 일반 자바 객체(POJO)를 사용하는 것으로 나눌 수 있었다. EJB를 사용하는 경우 개발자들의 많은 불만이 EJB 3.0을 사용함으로써 해결되리라 예상된다. 하지만 해외를 중심으로 해서 EJB를 사용하건, 사용하지 않건 비즈니스 로직들을 체계적으로 관리하는 IoC 컨테이너에 대한 관심이 증가하고 있는 추세이다. IoC 컨테이너에 대해서는 뒤에서 다시 자세히 살펴보도록 하겠다.
  
• 주요 패턴 : Business Delegate 패턴, Session Facade 패턴, Service Locator 패턴, Application Service 패턴, EJB Home Factory 패턴
  

퍼시스턴스 계층

• 역할 : 퍼시스턴스 계층은 데이터 처리를 담당하는 계층이다. 주로 데이터의 생성/수정/삭제/선택(검색)과 같은 CRUD 연산을 수행하게 된다. 식당으로 보자면 주방장이 사용할 재료를 담당하는 재료 담당자라고나 할까? 이 데이터는 주로 데이터베이스에서 처리되는 경우가 많아, 영속성을 의미하는 퍼시스턴스 계층이란 용어를 사용했다. 하지만 데이터가 처리되는 다른 업무 시스템이나, 웹 서비스, XML, 파일 시스템 등을 모두 고려한다면 레거시 개념을 갖는 EIS 계층이란 표현이 더 적합할 것이다.
  
• 기능 : 이 계층에서 수행하는 일은 관계형 정보를 저장하고, 수정/삭제하는 것과, 그러한 일을 수행하는 데 필요한 질의문을 관리하는 것, 그리고 가져온 관계형 정보를 객체화시키는 일이다.
  
• 대안 기술 : EJB 사용에 있어서 개발자들이 가장 불만스러워 하는 것은 CMP 방식의 엔티티 빈일 것이다. 그러한 불만은 객체 관계 맵핑(ORM)을 이용한 JDO라는 대안기술을 탄생시켰고, 또한 하이버네이트라는 또 하나의 오픈소스 기술을 실무로 끌여들였다. JDBC를 이용한 DAO 객체를 구성하는 방법도 소규모 애플리케이션에서는 여전히 인기를 끌고 있다. EJB 3.0과 JDO/하이버네이트, 그리고 JDBC를 이용한 POJO 방식 중 어떤 것이 개발자들에게 낙점될 지는 아직 미지수다.
  
• 주요 패턴 : Data Access Object 패턴, Domain Store 패턴, Sequence Blocks
  

도메인 모델 계층

• 역할 : 도메인 모델은 각 계층 사이에 전달되는 실질적인 비즈니스 객체라고 할 수 있다. 식당을 예로 든다면, 음식이 담긴 그릇이라고 비유할 수 있겠다.
  
• 기능 : 도메인 모델 계층은 흔히 데이터 전송 객체(DTO) 형태로 개발자가 직접 제작해서, 리퀘스트나 세션과 같은 컨텍스트에 담아 넘기게 된다. 하지만 데이터베이스의 모든 정보를 일일이 객체로 만드는 것은 귀찮을 뿐 아니라, 계층간의 통신 과정에서 데이터가 유실될 위험도 있기 때문에 최근에는 도메인 모델을 서비스로 제공하여 자동화하는 경우가 많다.
  
• 주요 패턴 : Data Transfer Object 패턴, Value List Handler 패턴

원문은 다음과 같습니다.
http://www.adaptivepath.com/publications/essays/archives/000385.php

----------------------------------------------------------------

Ajax : 웹 어플리케이션의 새로운 접근

현재 인터랙션 디자인 중 가장 매력적인 것은 웹 어플리케이션을 만드는 것이다. 어쨌든, 웹 말고 다른 곳에서 상호 작용하는 디자인을 본 적이 언제적 인지 모를 정도가 아닌가? (좋다 iPod는 제외해 주자) 무엇보다 놀라운, 혁신적인 새 프로젝트들이 진행 중이며 이를 소개한다.

이처럼 매력적임에도 웹 인터랙션 디자이너들은 데스크톱 소프트웨어를 만드는 우리의 동료들을 좀 부러워 할 수밖에 없다. 데스크톱 어플리케이션은 웹이 도저히 할 수 없을 것만 같은 풍부함과 응답성을 지니고 있기 때문이다. 웹의 빠른 확산을 가능하게 했던 예의 단순함은, 사용자들이 데스크톱 어플리케이션들로부터 얻었던 경험들을 웹으로 충족시켜 줄 수가 없었다.

그런 차이는 줄어들고 있다. Google Suggest를 보자.

<Google Suggest >

글자를 칠 때, 제안되는 단어들이 변경되는 순간을 유심히 살펴보자. 거의 즉시 이루어진다. Google Maps의 경우에도 줌 인을 하거나 지도를 여기저기로 이동시켜 보아도 거의 즉시 모든 것이 이루어진다. 기다리라는 페이지를 보여주거나 페이지 전체가 리로드되는 일은 없다.

< Google Maps - 진주만^^ >

Google Suggest와 Google Maps는 Ajax라고 불리는 것이 적용된, 웹 어플리케이션의 새로운 접근방식의 실 예다. Ajax는 Asynchronous Javascript + XML의 줄임 말이며 웹이 할 수 있는 가능성의 근본적인 변화를 말해주고 있다.

Ajax 정의하기
Ajax는 특정한 하나의 기술이 아니다. 몇 가지 각 영역에서 활약하던 기술들로 이루어져있으며, 강력한 새로운 방법들로 뭉쳤다. Ajax는 다음의 것들을 통합한다.

* XML과 CSS를 이용한 표준에 기반 프레젠테이션
* DOM(Document Object Model)을 이용한 동적인 디스플레이와 상호작용
* XML과 XSLT를 이용한 데이터 교체와 조작
* XMLHttpRequest를 이용한 비동기식 데이터 검색
* 모든것을 함께 묶어주는 Javascript

전통적인 웹 어플리케이션 모델은 이렇게 작동한다.: 대부분의 사용자의 인터페이스에서의 액션은 웹 서버로의 HTTP Request를 유발한다. 서버는 데이터 검색, 수 처리, 여러 레거시 시스템들과의 소통 같은 몇 가지 프로세스를 하게 되고, 클라이언트에게 HTML페이지를 돌려준다. 이는 하이퍼텍스트를 매개체로 한 웹의 기본적인 사용법을 채용한 모델이다. 그러나 하이퍼텍스트는 소프트웨어 어플리케이션을 충분히 만족시키기엔 부족했다.

< 전통적인 웹 어플리케이션 모델과 Ajax 모델과의 비교 >

이런 접근법은 많은 기술적인 감각을 만들어냈지만 사용자에게 만족할만한 결과를 주지는 못했다. 서버가 할 일을 하는 동안 유저는 무엇을 하는가? 그렇다. 기다려야만 한다. 그리고 작업의 모든 스텝마다 사용자는 기다린다.

당연하게도, 어플리케이션들을 모두 긁어 모으는 식으로 웹을 디자인한다면 유저들을 기다리게 만들지 않을 수 있었을 것이다. 인터페이스가 한번 로드 되고 나면, 왜 사용자는 어플리케이션이 서버에게 무언가를 필요로 하는 모든 시간마다 기다려야 하는가? 진짜, 도대체 사용자들은 왜 어플리케이션이 서버로 가는 것을 보아야 하는가?

Ajax는 어떻게 다른가
Ajax 어플리케이션은 사용자와 서버 사이의 중개자- Ajax 엔진 –를 소개함으로써 웹에서의 소통의 본성인 가다 서는 반복행위를 제거한다. 응답을 더 낮춰주는 어플리케이션을 한층 더 두는 것 같으나 그 반대가 맞다.

세션이 시작될 때 웹 페이지를 로딩하는 것 대신, 브라우저는 Ajax엔진(Javascript로 코딩되고 항상 숨겨진 프레임 안에 집어넣어진)을 로드 한다. 이 엔진은 사용자가 접하는 인터페이스를 구성하는것과 유저를 위해 서버와 통신하는 것 모두를 책임진다. Ajax엔진은, 사용자가 서버와의 통신에 의존하지 않는, 비동기식으로 이루어지는 어플리케이션과 의사소통 할 수 있도록 한다. 그래서 사용자는 결코 빈 페이지나 모래시계 아이콘 같은 것들을 볼 수 없게 되고 서버가 무언가를 하는 동안 초조하게 기다리지 않아도 된다.

< 전통적인 웹 어플리케이션의 동기식 인터랙션 패턴(위)과 Ajax 어플리케이션의 비동기식 패턴과의 비교 >

일반적으로 HTTP request를 만들어내곤 하는 모든 사용자의 액션은 대신 Ajax엔진을 호출하는 자바스크립트의 형태를 한다. 서버로 되돌아갈 것을 요구하지 않는 사용자의 액션에 대한 어떤 응답- 간단한 데이터 검증, 메모리에서의 데이터 수정, 네비게이션 같은 것들 까지도 -도 엔진은 직접 다룬다. 엔진이 응답을 위해 서버로부터 무언가를 필요로 한다면- 프로세싱과 추가적인 인터페이스를 로딩하기 위해 혹은 새로운 데이터를 검색해오기 위해 데이터를 송신한다면 - 엔진은 비동기적이면서 XML을 항상 사용하고, 사용자의 어플리케이션과의 인터랙션을 멈추지 않도록 해주는 그런 리퀘스트들을 만들어낸다.


누가 Ajax를 사용하는가

Google은 Ajax에 다가가기 위한 개발에 엄청난 투자를 하고 있다. Google이 작년 이전에 소개해 온 모든 주된 품목들- Orkut, Gmail, Google Groups의 최신 베타 버전, Google Suggest, Google Maps –은 Ajax 어플리케이션이다. (이 Ajax 구현에 관한 더 많은 기술적인 너트와 볼트들을 얻고 싶다면 다음의 대단히 잘된 분석들- Gmail(http://johnvey.com/features/gmailapi/), Google Suggest (http://serversideguy.blogspot.com/2004/12/google-suggest-dissected.html), Google Maps (http://jgwebber.blogspot.com/2005/02/mapping-google.html)) -을 보시라. 다른 것들도 선례를 따르고 있다. : Ajax에 의존하고 있는 Flickr(http://www.flickr.com/) 에 사람들이 푹 빠져버린 수많은 특징이라든지, 유사한 기술을 적용한 Amazon의 A9.com 검색 엔진 등.

이 프로젝트들은 Ajax가 기술적인 장점뿐만 아니라 실 세계의 어플리케이션들에도 유용하다는 것을 보여주고 있다. 이것은 연구실에서만 이루어지는 별개의 기술이 아니다. 그리고 Ajax 어플리케이션들은 정말 단순한 Google Suggest에서부터 그 복잡하고 정교한 Google Maps에 이르기 까지 어떤 크기로도 될 수 있다.

Adaptive Path에서, 지난 몇 달 동안 우리의 일을 Ajax로 해오면서 Ajax 어플리케이션이 제공할 수 있는 풍부한 인터랙션과 응답성의 겨우 표면만을 긁어봤다는 것을 깨닫고 있는 중이다. Ajax는 웹 어플리케이션을 위한 중요한 발전이고 그 중요성은 막 성장해가고 있다. 그리고 이 기술을 어떻게 사용하는 아는 개발자들이 이미 매우 많기 때문에, Google의 선도를 따르는 조직들이 더욱 많이 볼 수 있기를 기대한다.


앞으로 나아가기

Ajax 어플리케이션을 만드는데 있어서 가장 큰 도전은 기술적인 것이 아니다. 이미 코어 Ajax 기술들은 성숙되어있고 안정되었으며 이해하기 쉽다. 그보다, 도전은 이러한 어플리케이션들의 디자이너들을 위한 것이다. 웹의 제한성 대한 우리가 생각하고 아는 것을 잊어버리도록 해주고, 더 넓게 상상할 수 있도록 하고 가능성의 범위를 풍부하게 하는 것.