'Architecture'에 해당되는 글 2건

  1. 2010.05.12 JSP Model 1 VS. JSP Model 2
  2. 2010.04.20 아키텍처 / 프레임워크 / 플랫폼
2010.05.12 09:59

JSP Model 1 VS. JSP Model 2

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

여기서는 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의 경우 이와 같은 구조로 구성되어 있음을 볼 수 있다

Trackback 0 Comment 0
2010.04.20 16:38

아키텍처 / 프레임워크 / 플랫폼

- 아키텍처 : 소프트웨어의 주요 설계 구조
 
소프트웨어의 주요 특징들을 결정짓는 주요 설계 구조이다.즉, 소프트웨어의 주요 구성 요소 및 구성, 이들간의
주요 인터페이스, 중요 동작 방식 등 소프트웨어의 주요 특징들을 결정짓는 모든 설계 구조를 포함한다.
소프트웨어의 주요 특징을 결정짓고 소프트웨어 개발에 미치는 영향도 매우 커서 소프트웨어 개발에 있어서 가장 중요한 부분이라고 할 수 있다.지원 프로그램, 라이브러리, 언어, 다른 소프트웨어 구성 요소 등과 같이 구체적인 구현을 포함하지 않는다는 점에서 프레임워크나 플랫폼과는 명확히 구분된다.
 
- 프레임워크 : 소프트웨어 뼈대 구조
 
프레임워크는 다른 소프트웨어 프로젝트가 개발될 수 있는 뼈대 구조이다.지원 프로그램, 라이브러리, 언어,
다른 소프트웨어 구성 요소들을 엮어 주는 소프트웨어 등을 포함하고 있다.따라서, 플랫폼도 프레임워크의 일종이라고 볼 수 있으며, MS사에서 닷넷 플랫폼을 닷넷 프레임워크라고 지칭하는 것도 틀린 것이 아니다.또한, UI 프로그램 개발을 위한 부분 만을 떼어내서 프레임워크라고 할 수도 있다.UI 프로그램 개발을 위한 부분 만으로는 완전한 소프트웨어 실행 환경이 되지 않으므로 플랫폼은 아니지만 프레임워크이다.이러한 점에서 프레임워크와 플랫폼은 다른 경우가 많다.
 
- 플랫폼 : 소프트웨어 실행 환경
 
가장 일반적이면서도 명료한 의미는 "소프트웨어가 실행되는 환경"이다.개발 언어나 개발 환경을 플랫폼에
포함시키기도 하지만 이는 부수적 개념 혹은  확장된 개념에 불과하고, 핵심은 "소프트웨어가 실행되는 환경"이다.
각 프로그램은 아무 플랫폼에서나 실행되는 것이 아니고 특정 플랫폼에서만 실행된다.
일반적으로, O/S는 모두 플랫폼이다. Windows는 윈도우즈 프로그램만을 실행시킬 수 있는 플랫폼이고, 리눅스는 리눅스 프로그램만을 실행시킬 수 있는 플랫폼이다.자바 런타임 환경도 플랫폼이다.자바 프로그램은 O/S에 대한 종속성은 거의 없고 자바 런타임 환경없이는 실행되지 않으므로 자바 런타임 환경을 주요 플랫폼으로서 필요로 한다.마찬가지로 닷넷 프로그램도 닷넷 런타임 환경없이는 실행되지 않으므로 닷넷 런타임 환경이 플랫폼이 된다.AJAX 기술을 사용하여 개발된 웹 컨텐츠 + 웹 클라이언트 스크립트는 웹(좀 더 정확히는 웹 브라우저 및 웹 서버) 없이는 실행되지 않으므로 웹을 플랫폼으로 한다.VBA(Visual Basic for Application) 프로그램과 MS 오피스 COM API를 사용하는 프로그램은 MS 오피스가 없으면 실행되지 않으므로 MS 오피스를 플랫폼으로 한다.
플랫폼은 플랫폼위에 다른 플랫폼을 구축할 수 있는 계층적 구조를 가질 수 있다.가령, 자바 프로그램은 자바
런타임 환경이라는 플랫폼에서 실행되지만 그 플랫폼 자체는 O/S 플랫폼 계층 위에서 실행되는 프로그램에 불과하다.웹 플랫폼에 해당하는 웹 브라우저 또한 O/S 플랫폼 계층 위에서 실행되는 프로그램에 불과하다.VBA 프로그램의 플랫폼인 MS 오피스 프로그램 또한 O/S 플랫폼 계층 위에서 실행되는 프로그램에 불과하다.이들 각 계층의 각 플랫폼은 자신만의 실행 엔진과 API 및 개발 환경을 제공하며, 다른 플랫폼에 대한 부분적 접근을 허용하기도 한다. 또한, 각 플랫폼 내부는 또 다시 여러 계층으로 이루어진 구조를 갖는다.
이는 소프트웨어 구조가 그만큼 계층화되고 복잡해지고 있음을 의미한다.
역설적이지만, 소프트웨어 구조가 이렇게 다양해지고 복잡해지는 이유는 다양하고 복잡해지는 요구를 보다 적절히 만족시키기 위한 효과적인 방법이기 때문이라고 볼 수 있다.
따라서, 각 플랫폼은 나름대로의 가치와 적정 용도가 있으므로 프로그램이 성공적(경쟁 제품, 서비보다 저렴하게 개발하거나 보다 고품질을 제공하는 등)이기 위해서는 프로그램 개발 전에는 개발 목적에 가장 적합한 플랫폼을 선정하고 프로그램 개발중에는 플랫폼의 잇점을 최대한 살리는 것이 중요해진다.
그렇지 않은 제품 혹은 서비스는 경쟁력이 떨어질 수 밖에 없다.
물론, 단순하지 않은 제품/서비스에 적합한 플랫폼의 선정은 다루어야 하는 이슈가  많기 때문에 매우 어려운
문제이다.

 [출처] Devil BBong's Story

Trackback 0 Comment 0