이번 글에서는 Mini-javapattern Framework(가칭)이름으로 프레임웍에 대한 개념 및 설계사상,
실제 적용방안 작성기법등에 대하여 논하여 보도록 한다.

시작이 반이라고 지금 이렇게 시작하지 않으면 계속 진행할 수 없기 때문에 실제 구현하기로했던
Struts Tiles Framework보다 앞서 아티클 연재를 시작하도록 한다. 이해해 주기 바란다.

자, 이제 드디어 시작이다.

▶ Framework

프레임웍이란 서로 관련이 있는 많은 수의 문제를 풀기 위한 추상적 설계를 구체화한 클래스 집합을 
말한다. 클래스를 기본 단위로 하여 제어에 관련된 사항과 알고리즘을 캡슐화 하여 다양한 구조와 
행위를 가질 수 있도록 하며 유지보수, 확장이 가능하도록 설계하여 빠른 애플리케이션을 개발할 수
있도록 도와주는 유기적인 클래스들의 모임이라고 보면 무방하겠다.

▶ Framework의 이해

실제 여러분들이 작성해왔던 Servlet/JSP 프로그램들도 알고보면 실제 프레임웍의 기반아래서 
작동되는 것인데, 우리들은 그것을 가르켜 컨테이너라 알고 있다.
컨테이너도 하나의 프레임웍이다? 대충 맞을 것 같다. 
당신들은 서블릿 프로그램을 작성을 할 때 service, doGet, doPost 메소드등을 이용하여 작성하였다. 
어떤 메소드가 어떤 상황하에 동작을 하며, 어떠한 라이프사이클을 갖는지 알고 있다.

자, 당신들이 웹프로그램을 일일이 프로토콜까지 분석해가며 짤 필요성이 있다고 생각하는가? 

그건 아니다. 즉 컨테이너는 위에서 이야기한 것 처럼 추상적 설계를 통한 클래스의 구체화의 구조를
취하고 있기 때문에 당신들은 웹프로그래밍을 아주 빠르고 정확하게 짤 수 있었던 것이다.
비단 위의 경우에서만 프레임웍이 쓰이는 것이 아니라 아주 많은 분야에서 프레임웍이 사용되고 
있음을 알아야 한다.

자 이제 조금 이해가 되는가? 
우리가 개발할 애플리케이션의 프레임웍은 스스로가 개발하기 편리하도록 만들어진 
user-define성격의 클래스 모임이라 생각하면 된다. 어떤 동작을 어떤 순서로 행할 것인지를 먼저 
분석한 후 설계, 구현을 하여 다른 개발자들도 이용할 수 있도록 최적화시키면 된다

▶ Framework의 개발의 주변상황

자. 놀새가 요소기술에 대한 한가닥이므로 어떠한 내용들을 통하여 무엇을 만들어낼 지 보도록 하자.

일반적으로 여러분들이 보아온 프레임웍들은 무엇을 가지고 있는가? Struts, Avalon기타 등등의 
프레임웍들을 생각해보라~
답이 나오는가? 

바로 라이프사이클이란 것이 나타나게 된다. 당신들은 무심결에 라이프사이클을 지나치고 있는
경우가 허다하다. 가장 단순한 예를 보여주겠다. 애플릿도 라이프사이클을 가지고 있지만
(애플릿 라이프사이클은 init(), paint(), repaint(), destory() 등의 라이프사이클을 가진다), 요즘 누구나 
한번쯤은 서블릿, jsp파일을 작성해보았기 때문에 웹을 예로 들겠다.

서블릿을 짜봤다해서 서블릿의 라이프사이클을 아는 이는 도대체 전체의 몇퍼센트가 될지 
놀새~ 심히 궁금하다.
서블릿이 호출되면 최초로 불려지는 메소드는 무엇인가? init()메소드이다. 엔진시작 후 최초
한번의 클래스파일이 로딩될때 불려지며, 이후 요청들에 대하여서는 service()메소드가
엔진이 정상적인 shutdown이 이루어졌을 경우는 destory()메소드가 호출된다. 
알고 있었는가? 아주 다행이다.

이렇게 당신들이 이러한 라이프사이클을 앎으로서 실제 request, response객체의 처리가 컨테이너에
의하여 어떻게 처리된다는 것인지를 몰라도 웹프로그래밍을 할 수 있는 것이다.

위의 라이프사이클은 어떠한 기준에 의하여 쉽게 웹프로그램을 짜기 위하여 
JSR(Java Specification Requests)로 공표해놓은 것이고, 거기에 덤으로 얹어서 좀 더 범용적이고 
효과적인 개발방법이 되도록 우리의 라이프 사이클을 씌워야 할것이다. 

범용적이란것.. 한글을 쓰니 간단하게 한글처리를 해야되겠고, 환경설정을 훨씬 보기 쉽게 
만들어야 할 것이고, 데이터베이스에 대한 처리를 보다 쉽게 해야겠고, 로깅에 대한 정보도
그렇게 해야겠고 .... 아~ 정말 많지 않은가. 이런것들을 실제 개발선상에 들어간 개발자들에게
각자 구현하게 할 것인가? PL 이나 PM은 그걸 어떻게 통합하여 테스트, 인수 단계까지
이르게 하며, 추후 2차개발이 이루어졌을 때 투입된 개발자들에게는 어떻게 업무전이를 
시켜야 할 것인가?

보통 일이 아니다. XP 형상관리를 이용하여 나중에 처리를 시도하겠지만 우선은 이 글을 보는
당신들의 발상이 더 중요하다.

왜 이러한 프레임웍이 필요하냐의 문제제시이다. 
고전의 소프트웨어 공학적인 측면을 보게 되면 전체 소프트웨어 비용의 상당부분을 유지보수가
차지하는 경향이 분석/설계가 제대로 이루어지지 않을 경우 심각하게 증대되는 현상을 가져온다.
또한 개발이 중구난방으로 이루어져 시스템 통합 및 테스트의 시기가 늦어지고, 그에 수반한
여러가지 문제점들이 나타나게 된다.

현재 시대는 대체 어떤 시대인가? Time to market!!!!
시간이 곧 돈과 직결되는 것이고, 급격한 환경의 변화에 적응할 수 있어야 하며, 아침에 발생한
고객의 요구에 저녁시간에 결과를 보여줄 수 있어야 한다.

어디서 들어본 말 같지 않은가? 바로 XP인데 지금과는 다른 방향의 문제이므로 다루지 않는다.
궁금하면 아래의 아티클을 읽어보라.

http://www.javapattern.info/viewArticle.do?articleId=1046681327265

이야기가 삼천포로 빠지는 경향이 엿보이고 있는데 헛소리는 여기까지 하고 본론으로 돌아와서
설계 주변상황을 반영해보도록 하자.


아래와 같이 가정을 하도록 한다.
1. 기본적으로 BL(Business Logic)와 PL(Presentation Logic)의 분리방안인 Model 2 Architecture를 
쓰도록 한다.
JSP Model 2 Architecture를 먼저 읽어보기 바란다.

http://www.javapattern.info/viewArticle.do?articleId=1046824361862

2. 모든 환경설정에 관련한 부분은 property클래스 또는 XML Configuration을 사용하도록 한다.
3. Tag Lib를 통하여 JSP Page의 모든 부분의 scriptlet(<% %>)을 제거하도록 한다
4. 어떠한 container에서도 구동되어질 수 있도록 빌드 또는 인스톨환경을 설정한다.
5. 화면레이아웃은 페이지의 설정을 통하여 Struts tiles처럼 자유자재의 배치가 가능토록 한다.
6. 개발자들이 최대한 간단한 방법으로 코딩이 가능하도록 아키텍쳐를 구성한다.
7. getter, setter등 기타 개발환경작업의 불필요한 클래스 작성시간을 최소화하는 유틸리티등을
개발한다.
8. Testcase와 stress test를 언제든 실행할 수 있도록 적재적소에 해당 모듈을 배치하도록 한다.
9. 전체 아키텍쳐는 아래의 그램을 따르도록 한다.



위의 구조 및  시나리오를 이용하여 프레임웍을 만들어보겠는데
다음 편에서는 라이프사이클에 대한 정의 핵심 컨트롤러 클래스를 통하여 어떻게 환경을
설정한 후 흐름을 탈 수 있도록 하는것인가에 대하여 정의하고자 한다.

참고로 이번 WAF는 실제 예전에 쫀과 합작해 제작한 상용 Spider WAF의 20% 수준정도임을
밝혀둔다.

낮에 일하고 밤에 글쓰고.. 죽고 잡다...ㅎㅎㅎ