효과적인 디자인은 차후 애플리케이션에 대한 유지보수 및 확장의 측면에 있어서 비용을 
결정하는 큰 요소로서 작용할 수 있는 부분이다. 
여기서는 JSP Model 1 Architecture와 JSP Model 2 Architecture에 대하여 살펴보도록 하자.



▶ JSP Model 1 Architecure
  
가장 전형적으로 구성할 수 있는 웹환경은 request에 의한 처리를 JSP페이지로서 이용하며,
request의 데이터를 추출하여 JavaBeans를 이용한 기존 datasource의 이용 및 EIS환경에 접속하여
일을 수행할 수 있는 형태를 취하고 있는 경우가 대부분이었는데 그림으로 도식화하여 보면 
아래와 같다.



위의 형태를 가르켜 JSP Model 1 Architecture라고 하는데 이 경우 client에서 들어오는
request부분에 대한 처리와 beans에서 처리된 결과 response가 JSP페이지에 의하여 모두
처리되는 것을 볼 수 있다. 또한 모든 데이터 액세스 또는 처리가 beans에서 처리되고
있으므로 contents와 로직의 분리라는 장점을 잘 살리고 있다. 하지만 위의 구조는 간단한 
애플리케이션에 적합한 구조지 점점 복잡, 대형화되고 있는 추세에는 적합하지 못한 
구조를 가지고 있다. 프로젝트 구축에 필요한 JSP페이지 및 scriptlet이 많아지면 많아질수록 
어떤 정형화된 틀에 있지 않은 이상 Beans와 JSP페이지는 아주 복잡하게 뒤섞이는 결과를
초래하게 될 것이 분명하다. 또한 MVC 패턴에 또한 부합되지 않는 형태를 취하고 있다. 

이 문제는 오로지 request에 의한 처리를 JSP 페이지에 의하여 처리하기 때문에 나타나는 
문제일 수 있는데 이를 해결하기 위한 Servlet과 JSP양쪽을 사용하는 Model 2 Architecture의 
사용이 나타나게 된다.

▶ JSP Model 2 Architecture

Model 2의 구조도는 아래와 같다.



위의 구조가 Model1과 어떤 차이점을 보이는 것일까? Model1에서의 JSP페이지는 MVC의
형태로 놓고 보았을 때, view의 측면과 controller의 측면 모두를 담당하고 있는 형태를
취하고 있다. 

이를 servlet을 client의 request를 처리할 수 있는 영역으로 두고 JSP와 Servlet 양쪽 모두를
사용하여 동적인 웹을 제공함에 있어 각각의 기술이 취할 수 있는 장점을 합성해 놓은 
형태로 보아도 될 것이다. 즉 JSP는 presentation을 생성해내는 부분으로 사용하고, 
Servlet은 프로세스만을 집중적으로 수행할 수 있는 형태를 제공하게 된다.

여기서 servlet은 controller로서 행동을 하게 되며 사용자의 action에 따라 JSP에서 사용되는 
어떠한 객체나  business logic에 대한 class 및 beans를 instantiate하는 역할을 담당하고
forward시키게 된다. 이는 프로젝트 개발에 있어서 디자이너와 개발자의 책임과 권한을 
좀 더 명확하게 할 수 있는 구조이며, 더 나아가 아주 복잡한 애플리케이션을 작성했을 
경우 controller부분을 정형화된 framework으로 구성하게 된다면 빠른 시간안에 목적을 
달성할 수 있는 효과적인 구조로 변화시킬 수 있는 장점을 가지게 된다. 
현재 진행중인 자바 프로젝트의 경우나 기존에 Sun Microsystems에서 내놓았던 J2EE Blueprint의 
web-tier architecture의 경우 이와 같은 구조로 구성되어 있음을 볼 수 있다.