#059 Java Development Framework

Java Development Framework

1. Development Framework의 필요성

예를 들어 각종 자동차 부품과 냉장고 부품이 전부 분해되어 바닥에 즐비하게 서로 섞여 있는 모습을 상상해 보겠습니다. 수많은 볼트와 넛트, 게스킷, 파이프, 심지어 팬치와 드라이버까지 마구 섞여 있습니다.
이러한 부품과 연장을 이용하여 우리가 만들려는 것은 청색의 카렌스입니다. 물론 완전히 분해된 부품들을 하나하나 조립해서 청색의 카렌스를 만들어 낼 수는 있습니다. 상당한 시간이 걸리겠죠. 카렌스를 만드는 데는 전혀 쓸모없는 냉장고 부품은 걷어내고, 엔진조립부터 시작하여 패인트칠까지 하다 보면, 갖가지 일이 발생합니다. 엔진의 성능을 높이위해 이렇게도 해보고 저렇게도 해보고, 그러다 보면 납기는 가까이 오고 결국 카렌스를 만들지 못하고 ‘티코’를 만들고 있는 자신의 모습을 보게 됩니다.

그러나, 엔진과 기어변속장치, 동력전달장치 등 각종 단위 부품을 미리 조립해 둔 반제품을 이용한다면 최종적으로 카렌스를 만드는 기간은 엄청나게 빨리 끝낼 수 있겠지요. 완제품을 만드는 사람은 엔진구조공학은 모르지만 단지 최종적인 조립을 위한 최소한의 ‘조립공정’과 기술만 보유하고 있으면 됩니다.

카렌스가 SI 프로젝트를 통해 완성시켜야 할 최종적인 시스템에 비유한다면, 각종 부품들은 API(Application Programming Interface)에 해당될 수 있습니다.

물론 지금의 SI프로젝트가 직면한 문제가 위에서 예를 든 것과 비슷한 상황인가란 질문에는 의견이 분분할 수도 있습니다. 사실 엄밀히 말하면 시스템을 구성하기 위해 기계어나 어셈블리어를 사용하지 않고, C/C++언어나 Java언어를 사용하는 것도 이미 기 조립된 단위 부품을 사용한다고 볼 수도 있습니다. PowerBuilder나 Delpi 같은 4GL Tool, TUXEDO, CICS, Entera, Topend 같은 미들웨어제품 군이 그러했고, CORBA/EJB와 같은 더 상위의 어플리케이션 Framework을 사용하려는 시도는 보다 확장성있고, 강력하며, 안정적인 시스템을 보다 빨리 개발할 수 있는 반제품이자 ‘조립공정’이라고 볼 수 있습니다.

지금의 각종 4GL Tool과 더불어 Java IDE Tool, JSP, Servlet, Applet, RMI, CORBA, EJB, Application Server 등은 다양한 시스템을 만들 수 있는 충분한 ‘부품’을 제공하고 있는 것은 사실입니다.

“그러나 ‘카렌스’를 만들기에는 아직도 부품이 너무 잘게 쪼개어져 있습니다”

아시다시피 최근의 상황은 IT시장에서 또 하나의 큰 패러다임 전환기를 맞고 있습니다.
과거에 Main Frame에서 Client/Server로의 큰 변화가 있었고, 지금은 Java와 EJB, 어플리케이션 서버라는 용어가 인터넷을 등에 업고 새로운 변화의 시작단계를 막 지났습니다. 이러한 패러다임은 기능상의 추가나 변경이 있을 수는 있지만, 최소한 이러한 기본 마인드와 골격은 향후 5년 동안은 변하지 않을 것으로 내다봅니다.

국방시설, 국가안전, LG화재, 노동부 등의 프로젝트를 시작으로 해서 한미은행, 한국투자신탁, 주택은행, 동양카드, 한전 프로젝트와 같이 웹을 근간으로 혹은 일부 도입하는 프로젝트의 출현은 금년은 이렇게 막을 내리지만 새 천년을 맞이하는 내년부터는 우후죽순 격으로 생길 것이라는 예상은 그리 빗나가지 않을 것입니다.

그런데, 지금의 시점에서 보면 과거에 겪었던 과정을 또다시 반복하고 있는 현상이 일어나고 있습니다. TUXEDO와 PowerBuilder라는 Client/Server의 대표적인 아키텍춰로 프로젝트를 진행하면서, 한 프로젝트에서 사용된 개발기술 혹은 소스 프로그램 Template을 다른 프로젝트를 진행하면서 발전시켜 나가고, 그러다 누군가는 공통모듈이라는 이름으로 정리하고 모아두었다가 또다시 차기프로젝트에 사용했을 것입니다. 아마 지금 TUXEDO와 PowerBuilder로 프로젝트를 한다면 순수하게 그 제품과 API만으로 시작하지는 않을 것입니다. 유사한 프로젝트에서 사용된 방법과 기술, 공통모듈 혹은 샘플 프로그램을 찾아보는 것이 우선이겠지요…

지금도 똑 같습니다. 유일한 차이가 있다면 그 방법과 기술, 공통모듈이 지금은 없다는 것이 차이입니다. 좀더 비유해서 말하면 신차인 ‘카렌스’를 만들 모든 부품은 마련이 되어 있는데, 그것을 조립할 때, 볼트와 너트부터 조립하고 있는 것이 현실입니다.
혹자는 EJB라는 막강한 Framework이 있는데 무슨 소리냐 라고 반문할 수도 있습니다.
하지만 절대로 JSP, Servlet 혹은 EJB나 CORBA 혹은 Application Server와 같은 기술은 SI 프로젝트를 위한 충분한 만큼의 ‘단위부품’을 미리 조립해 주진 않습니다. 또한, 무게중심이 실려있는 미들웨어적인 요소기능을 부각시키는데 급급하다 보니 정작 SI를 진행하면서 필요한 몇몇 가지 사소하지만 꼭 필요한 기능을 제공하지 않기도 합니다.

이러다 보니 웹을 근간으로 하는 지금의 프로젝트는 각기 고유한 방식으로 초보적인 수준에서 시스템 틀과 공통모듈을 만들고, 제품에서 제공되지 않는 기능을 똑똑한 누군가의 개발자에 의해 만들어져 각기 적용되고 있죠. 국방시설, 행자보, LG화재의 소스를 들여다보면 결국 같은 것을 고민하고 있었습니다. 인식하고 있든 그렇지 않든, 그들은 ‘어떻게 하면 개발자가 업무로직에만 전념케 하며 동일한 소스를 반복해서 생성하지 않고 공통되고 일관된 모습으로 개발을 더 빨리 할 수 있을까’ 라는 문제를 풀고 있었다는 사실입니다. 때론 그것이 아주 초보적인 모습으로 나타나기도 하고, 때론 깊이 고민한 흔적이 역력히 나타나기도 합니다.

프로젝트를 주관하시는 분들이 겪고 있는 흔한 오류 중의 하나는 어떤 기술 Set, 어떤 Application Server를 사용하느냐 보다는 그러한 기술Set을 이용해 프로젝트를 이끌어 나갈 만큼의 충분한 기술력과 표준적인 Framework이 준비되어 있느냐가 더 프로젝트의 성공여부를 결정짓는 요소임을 간과한다는 것입니다. ‘개발할 사람이 없어서..’ 란 생각을 가질 수도 있지만, 정작 필요한 것은 개발자가 아니라 일관된 모습으로 개발할 수 있는 ‘준비된 틀’이 필요합니다. C/S환경의 Framework은 이미 정형화되어 모두들에게 인식되어 있습니다. 그러나 웹을 근간으로 하는 충분한 수준의 개발 Framework은 아직 어느 곳에도 없다는 것을 인정하셔야 합니다.

ITG가 사업부와 차별성을 갖으려면 핵심 코아 기술을 보유하고 있어야 합니다. ITG가 사업부 프로젝트에 개발인원을 공급해 주는 용역업체로 전락하느냐 혹은 핵심기술지원을 통한 ITG 본연의 모습을 찾느냐는 결국 지원해 주는 기술의 질에 달려 있다고 볼 수 있습니다.
이러한 차원에서 Development Framework를 프로젝트 초기에 제공하고, 비록 능숙한 개발자가 아니더라도 개발에 동참시킬 수 있으며, 초기 아키텍춰 선정과 이에 따른 적절한 Framework, 그리고 적절한 산출물의 정형화를 제시함으로써 프로젝트에서 필요로 하는 기술적인 리딩을 해 주는 것이 사업부의 입장에서 가장 필요로 하는 것임은 두말 할 필요 없습니다.

지금까지의 기술지원 형태를 보면, 통합팀과 같은 팀에서 ‘개발가이드’, ‘구현가이드’, ‘개발코딩표준화’ 등과 같은 문서를 만들고, 실제적인 ‘공통모듈’과 ‘핵심모듈’을 개발해 주는 형태가 지금까지의 기술지원의 형태였습니다. 이러한 구조를 변경하자는 것이 아닙니다. 체계적으로 준비된 기술과 내용을 갖고 시작하자는 것입니다.

지금까지 각 프로젝트에서 제시된 구현가이드가 기술지원 나간 사람의 특성에 따라 서로 상이하였고, 그 구현의 방법이 정말로 진실로 바람직한 방법이었냐라는 의문에서 이 모든 것은 시작됩니다. 또한 기술적인 리딩을 하는 몇몇 사람에게만 모든 요청이 몰리는 현상도 준비된 개발틀이 없음으로 인해 발생되는 문제입니다.

이러한 모든 문제의 해결점이 바로 Development Framework 라고 생각이 됩니다.

2. Java Development Framework

2.1 Framework 의 정의
Structure, Architecture, Framework 이란 용어는 기술과 시대가 변하면서 조금씩 그 의미를 달리해 가는 것 같습니다. Structure 라는 용어가 Tree와 같은 Hierarchical한 탄탄한 기반 구조를 말하는 반면, Framework은 다소 수평적인 의미를 가지는 하부구조를
나타냅니다. 또한 Architecture라는 것은 이 두 부분을 모두 포함하는 더 포괄적인 개념의 체계적인 기반구조를 나타냅니다.
그러나 Framework이란 용어는 Structure나 Architecture 보다 더 낮은 레벨의 의미를 지닙니다. 즉, Framework의 실체는 때론 API의 집합으로 나타나기도 한다는 것이지요.
Sun Microsoft사의 Java Activation Framework이 그러하고, Java Media Framework이 그러합니다.
그러나 최근에 와서 IBM의 San Francisco Framework 이라는 용어가 등장하면서 ‘반제품’의 의미를 강하게 띄는 것 같습니다. 아시다시피 San Francisco Framework은 정형화된 업무를 위한 Business Component를 미리 만들어 두고, 이를 조립함으로써 생산성을 극대화 시키자는 것이 요지입니다.
어쨌거나 현재의 Framework이란 것은 ‘기반 틀 구조’ 라는 모호한 추상적인 개념이기 보다는 물리적인 실체이면서 반제품 성격의 구체적이고 체계화된 API를 제공하는 개념이라고 보아야 할 것입니다.

2.1. Java Development Framework의 위치
일반적으로 프로젝트를 통해 시스템을 개발할 때, 다음과 같이 네 단계의 개발 API 층(Layer)이 있습니다.

가장 상위층의 Layer는 프로젝트에서 business를 어플리케이션으로 변환하여 말 그대로 프로그램을 코딩하는 일반 개발자들이 사용하는 API Layer입니다.

그 다음 하부 Layer에서는 통상 ‘통합팀’ 혹은 ‘TFT팀’에서 주관되어 공통모듈 혹은 프로그램 템플릿을 만들고, 개발자들이 쉽게 프로그램을 구현할 수 있도록 도와주는 모듈성 프로그램 API Layer가 있습니다. DB Resource를 Access 하는 모듈, Log를 남기는 모듈, 모든 어플리케이션에서 공통적으로 사용하는 모듈을 개발하는 Layer입니다. 여기서 사실상의 전체 어플리케이션의 틀이 만들어 지는 부분입니다. 이 Layer가 없거나 흔들리기 시작하면 그 프로젝트는 상당히 위험하게 됩니다.

세번째 Layer를 나눈다면, 저희들같이 ITG 기술지원팀에서 해당 프로젝트를 위해 기술지원을 나가 ‘통합팀’에서 일하면서 아키텍춰와 performance를 고려하여 전체적인 틀을 만들기 위한 가장 바탕이 되는 API를 제공해 주는 Layer입니다. 다양한 Legacy System Access API, Application Server의 API를 이용하여 Background Core Class 를 만들어 줌으로써 보다 효과적으로 전체 시스템의 틀을 만들어 낼 수 있도록 도와 주는 것입니다.

마지막 Layer는 제품의 API Layer입니다. BEA WebLogic, IBM WebSphere, Servlet, JSP, RMI, EJB API 등등 산업계에서 제공되어지는 API Layer가 그것입니다.

근래 들어 일어나는 현상가운데 가장 심각한 현상이 가장 상위층의 일반개발자가 가장 하부층의 제품 API Layer를 바로 이용하고 있는 상황입니다. Source Code 내에 DB Access 정보 같은 Static한 변수를 명시적으로 사용한다거나, 동일한 소스를 모든 개발자가 Cut & Paste하여 전부 자신의 프로그램에 넣어놓고 사용한다는 것이지요.
그러나 보니 제품이 버전업 되어 API가 변경되면 모든 프로그램의 소스를 변경해야 하거나, 각 모듈이 수행한 시간을 로그로 남겨야 되는 추가적인 요구가 있을 경우 모든 소스를 전부 새롭게 변경을 가해야 되는 현상이 일어나게 되죠.

그나마 나은 경우는 통합팀에서 주관하여 시스템의 전체 틀을 잡고, 필요한 API를 제공하여 개발자들은 그러한 API의 바탕 위에서 프로그램을 하는 경우입니다. 이러한 경우는 사실 매우 바람직합니다. 그러나 ITG의 입장에서 보면, 매 프로젝트 마다 제 각각의 방식으로 동일한 작업을 하고 있는 거지요. 국방시설에서 고민했던 것을 행자보에 가서 다시 처음부터 고민하고 있고, LG화재에 가서 또다시 처음부터 다시 하고 있습니다.
문제는 그러한 틀이 정말 제대로 된 방법으로 구현되어 있었느냐라는 것입니다.

따라서 가장 이상적인 모습은 세번째 Layer인 Development Framework이 존재할 때입니다. 하고자 하는 Java Development Framework은 세번째 Layer에서 해 주었어야 할 일들을 기술적인 입장에서 재정의하고 구체화하여 프로젝트에 도입시키자는 것입니다.

2.3 Java Development Framework 의 범위
이 글을 작성한 이유는 Java 혹은 Web을 근간으로 하는 프로젝트를 위해 Development Framework을 만들고 확산시키는 목적을 갖고 있습니다. 따라서 이 문서에서 얘기하는 Java Development Framework은 아래와 같은 범위를 다루는 개념으로 사용할 예정입니다.

1. Java Development Framework의 최종 사용자는 해당 프로젝트에서의 S/W시스템 설계자와 일반 개발자이다.
2. Java Development Framework가 사용될 기술Set은 JavaScript, Java, JSP, Servlet, EJB, Application Server, CICS/TUXEDO 와 같은 Legacy Access Wrapper, DB Wrapper를 이용한 RDBMS Accessing 기술, 그리고 기타 Java Mail API와 같은 유틸리티 성격의 기술들을 대상으로 한다.
3. 매우 구체적인 특정 형식의 프로젝트와 특정 Architecture Set에 따른 고유한 반제품 성격의 Java Class를 제공한다.
4. 특정 Application Server에 종속적인 Java Source 가 생성되겠지만, 개발자가 사용해야 할 최종적인 API의 모습은 통일되고 투명하게 생성되어야 하며, Application Server 제품이 변경되더라도 개발된 비즈니스 소스는 변경이 일어나지 않도록 제공되어야 한다.
5. Java Development Framework는 물리적인 API 뿐만 아니라, 이 Framework을 사용하는 모습을 담은 Sample Source Template도 제공되어야 한다.
6. Java Development Framework는 이러한 특정 Framework을 이용하여 프로젝트를 진행할 때에 가장 적절한 산출물 형식도 제공이 되어야 한다. 이러한 작업은 방법론전문가와 OOAD를 전문적으로 하는 분과의 긴밀한 협조가 필요한 부분이다.
7. Java Development Framework는 또한 Entity/DBWrapper Class Generator 등과 같은 개발지원을 위한 유용한 Tool 제공도 고려사항이 된다.
8. Java Development Framework의 모든 API 및 상세한 설명가이드는 Web Site를 통해 각 사업부 및 모든 SE들에게 투명하게 제공되어야 한다.
9. Java Development Framework는 모든 SE 들의 토론과 경험을 바탕으로 만들어 지며, Feedback이 가장 중요하다. 그러나 통일된 모습으로 가져가기 위하여 배포는 항상 특정 Web Site를 통해야 한다.
10. Java Development Framework는 완성된 모습이 있을 수 없다. 현재는 당장 필요한 기능으로부터 시작되며 필요한 요소기술이 계속적으로 Add-on 되어 갈 것이다.
11. 이러한 Java Development Framework에 가장 관심을 갖는 주 대상은 프로젝트의 Technical Leader 이거나 ‘통합팀/TFT팀/기술전담팀’ 이 될 것이다.

2.4 Java Development Framework의 구체적인 대상

Java Development Framework은 구체적으로 다음과 같은 기능성을 제공해 주는 API의 모음이며, 프로젝트 지원 Tool이자 개발 Framework입니다.

1) Development API Framework
– Configuration Processing Framework
– ErrorLog Tracking Framework
– DB Connection Resource Handling Framework
– Hand-by Transaction Processing Framework

– DBWrapper/Entity Programming Framework
– Exception Handling Framework
– Message Handling Framework

– JSP/HTML/XML Support Framework
– JavaScript Common Function Framework
– Servlet Support Framework
– Applet Support Framework
– EJB Support Framework

– CICS Accessing Framework
– TUXEDO Accessing Framework

기타
– Java Mail Support Framework
– PCS Message Send Utility

2) Development Support Tool Framework
Development Framework은 물리적인 API 뿐만 아니라 프로젝트를 진행하면서 꼭 필요한 프로젝트 지원 TOOL도 함께 고려의 대상이 됩니다.

– 프로젝트를 위한 통합 인트라넷 시스템 게시판
– package/class 상세 설명 On-Line 웹으로 제공
– DB Wrapper/ Entity Class 자동 생성 Tool 제공
– 정형화 된 산출물 Define

2.4.1 Configuration Processing Framework

단일의 머신이나 분산환경에서의 각종 정보를 효과적으로 관리하면서 이러한 정보가 Application Program에서 손쉬운 방법으로 Handling되도록 제공되어야 합니다. 이 기능은 아래의 모든 Framework의 기본 바탕이 됩니다. 예를 들어 DB Connection Info., ID, Password, Legacy Access IP Address, port, 등과 같은 정보를 어딘가 기록해 두고, Application 프로그램내에서 자연스럽게 사용할 수 있는 메커니즘이 제공되어야 한다는 것이지요.
NOTE: bootstrap.properties/weblogic.properties, TUXEDO 구성파일, ….

“oracle.jdbc.driver.OracleDriver”,
“jdbc:oracle:thin:@power:1521:ORA8i”,
“scott”,
“tiger”
import com.lgeds.jdf.*;

Configuration cfg =new Configuration();
String driver = cfg.get(“com.lgeds.jdf.db.driver”);
String url = cfg.get(“com.lgeds.jdf.db.url”);
String user = cfg.get(“com.lgeds.jdf.db.user”);
String passwd = cfg.get(“com.lgeds.jdf.db.password”);

2.4.2 ErrorLog Tracking Framework

WebLogic이나 WebSphere같은 Application Server는 운영시에 Error Tracking을 조절할 수 있는 방법이 제공됩니다. 그러나 Applicatoin Server를 이용하여 개발된 우리들의 시스템은 통상 설계 시에 Error Tracking을 조절하는 방법을 고려하지 않았습니다. 기껏해야 Debug.TRACE=true/false 등과 같은 방법으로 System.err.println(), System.out.println()을 이용한 것이 고작입니다.
여기서 어떻게 하면 개발자가 손쉬운 방법으로 ErrorLog Tracking을 할 수 있도록 제공할 것인가가 관건이 됩니다.

예) : Logger.err, Logging.warn, Logger.info, Logger.debug,
E=Error, W=Warnning, I=Info, D=Debugging

Logger.err.println(“alksjdfalsf”);
Logger.warn.println(this, e.getMessage());
Logger.debug.println(this, ex);

2.4.3 DB Connection Resource Handling Framework

시스템을 개발하다보면 각기 다양한 Database를 이용하게 됩니다. JDBC Driver도 다양하고, 어떨 땐 Connection Pooling 기능이 제공되지 않기도 합니다. 만약 Connection Pool 기능이 제공되지 않는다면 제공할 수 있는 방법과 API를 제공하고, 앞으로 우리들이 개발할 모든 시스템에서 DB Resource를 Access하는 표준적인 방법이 제공하여야 합니다.

2.4.4 Hand-by Transaction Processing Framework

아직 JTA(Java Transaction API)에 대한 활용 사례가 그리 많지는 않았습니다. 향후는 JTA를 통한 방법을 사용하겠지만, 그 때까진 java.sql.Connection을 직접 Handling하여 Transaction을 처리하여야 합니다. 설령 JTA를 범용적으로 사용하는 시기가 오더라도, 중소규모의 많은 어플리케이션은 여전히 java.sql.Connection을 이용하여 Transaction을 직접 처리하려 할 것입니다. 어떻게 하면 가장 쉽고 일관된 방법으로 처리할 수 있을지에 대한 고민을 통해 필요한 지원Class를 도출하고 제공되어 져야 합니다. Low-Level인 java.sql.Connection을 직접 handling하라고 개발자에게 모든 것을 위임하는 것은 전체 시스템의 stability를 떨어뜨리는 결과를 초래할 것입니다.

2.4.5 DBWrapper/Entity Programming Framework

Web/OO내재화 프로젝트를 진행하면서 DBWrapper/Entity 처리에 대한 know-how가 많이 쌓인 것으로 믿습니다. 그러나 여전히 좀더 고민해야 할 부분이 남아 있는 것 같습니다. 국방시설에서 사용했던 방식과, 행자보에서 사용했던 방식, 또, LG화재에서 사용했던 방식이 서로 상이합니다. 어느 것이 맞습니까? static or non-static, DBWrapper에서의 Log Tracking, Business Exception 처리기법 등등….
사실 이 부분은 Framework이라기 보다는 Template을 제공해야 할 성격의 것이 됩니다.
이 부분에서 DBWrapper Testing Tool도 생각해 볼 수 있습니다.

2.4.6 Exception Handling Framework

Java에서 Exception처리는 아주 막강합니다. 이 부분은 Framework이기 이전에 Java Programming의 기본적인 테크닉에 속합니다. DBWrapper/Entity 처리시 뿐만 아니라, 분산환경의 전 부분에 걸쳐 Exception은 다양하게 만들고 사용되도록 해야 한다.
비즈니스적인 예외상황을 응용프로그램의 Exception으로 발생시키고, 프로그램 Flow를 Control할 수 있는 표준적인 패턴이 몇몇가지 있습니다. 이를 발전시키고 확산시키면 응용 프로그램을 구사할 때나, 설계 레벨의 모델링을 할 때 매우 유용할 것으로 판단됩니다.

2.4.7 Message Handling Framework

Exception 은 Message와는 다릅니다. 때론 같은 개념으로 접근하기도 하기만 엄격히 구분되어야 합니다. Message는 사용자에게 보여줄 Message와 Log로 남아야 될 Message로 크게 구분됩니다. Message가 발생되도록 하는것은 Exception을 통한 flow에서 처리되지만, 그 Message 자체를 정의하는 것은 완전히 별개인 것입니다.
프로젝트마다 Message 처리의 depth는 천차만별이지만, “어디까지”, “어떻게” 하는 것이 가장 효과적인 것인가에 대한 논의가 있어야 합니다.

2.4.8 JSP/HTML Support Framework

Presentation Layer로의 JSP/HTML은 효과적인 수단임에는 틀림없습니다. BEA WebLogic이나, Oracle OAS에서는 Servlet이 HTML을 생성하기 위한 별도의 Java 클래스를 제공해 주고 있습니다. 때론 그것이 산업표준이 아니라는 이유로 사용하지 않는 경향이 있는 것도 사실입니다.
그러나 막상 프로젝트를 하다 보면, 그와 유사한 Utility 성 클래스를 JSP에서 사용하면 편리할 때가 많습니다. 꼭 필요한 것이 무엇인지 규정하고, 필요하다면 제공되어야 합니다.
JSP를 위한 Utility성 모듈은 수도 없이 만들어서 재 사용되어져야 합니다.
예)
<TEXTAREA rows=25 cols=”<%= Size.netscape(request,40) %>” name=”content”
wrap=”hard”></TEXTAREA>

2.4.9 Servlet Support Framework

HttpServlet을 그대로 개발자에게 노출시킬 것인가 혹은 한번 더 Wrapping시킬 것인가에 대한 고민의 산물입니다. Servlet의 기본적인 API인 Form Data처리, COOKIE처리, Servlet Chaining, Call JSP 등의 API는 막강한 것이 사실이지만, 지저분하고, Error Tracking의 부재, Form Data 처리의 미진한 부분, File Upload 기능의 부재 등, 아직 정작 SI 를 위한 꼭 필요한 몇 가지 부분이 빠져 있거나, 어설픈 것이 사실입니다. 부족한 부분을 채워 줄 API가 필요합니다.

2.4.10 Javascript Common Function Framework

JavaScript는 깊이 있는 부분은 아니지만, 모르면 아무것도 할 수 없는 부분이기도 합니다.
IE와 Netscape의 차이성에서 오는 기술적 해결과제, Cascade Style Sheet 뿐만 아니라 최근 XML을 이용해 그 동안 하지 못했던 다양한 HTML Base GUI를 생성할 수 있는 틀 혹은 공통모듈, 혹은 Program Source를 통합 관리할 필요가 있습니다.

2.4.11 Applet Support Framework

이 부분은 사실 어디까지 진행되어야 하는지 명확하지 않습니다. 그러나 Applet을 이용해 MIS성 프로그램을 짜다 보면, 그 어떤 형태의 기술셋 보다도 Framework이 절실히 필요로 하는 부분임에 틀림없습니다. Applet의 Configuration 처리, EJB나 RMI형태의 서버를 binding하는 기법과, Caching 기법, GUI를 생성하고, Data를 보관하는 방법 등, Applet이기 때문에 겪는 많은 문제들이 있으며, 이러한 개발틀이 없다 보니 개발자의 프로그램 실력에 의존하는 경향이 그 무엇보다도 짙은 영역이기도 합니다.

2.4.12 EJB Support Framework

Web/OO과정을 거치면서 기술적인 검토는 일정부분 끝났다고 판단되며, 만약 EJB를 이용하여 실 프로젝트에 적용할 때, 통합팀에서 만들어줘야 할 클래스가 정말 무엇인지, 어떠한 클래스를 제공할 때, 가장 효과적으로 개발자가 개발할 수 있는 지를 검토하고, 그러한 클래스를 만드는 것이 주 관건입니다. 또, 개발절차/Deploy를 위한 자동화 스크립트와 같은 tool이 필요하다면 제공되어야 합니다.

2.4.13 CICS Accessing Framework

LG화재에서 개발했던 Java에서 Host CICS 프로그램을 Access 하는 표준적인 Wrapper API를 발전시켜 제공하고자 합니다. IBM 제품은 CTG(CICS Transaction Gateway for Java)를 이용하여 CICS와 연동을 하는데 그 API가 매우 낮은 레벨의 API를 제공하고 있기 때문에 일반개발자가 그대로 이용하기는 매우 불편한 수준입니다.

2.4.14 TUXEDO Accessing Framework

Jolt를 이용하든 혹은 우노시스템의 J*Link 등을 이용하든 Java에서 Tuxedo를 Access하는 방법을 파이롯 수준에서만 다루어 봤지만, 실제 프로젝트에서는 어떻게 사용하고 있는지 알아보고, 어떻게 사용하여야 가장 효과적인지, 필요한 추가 Class혹은 API 가 필요하면 제공되어야 합니다.

2.4.15 Java Mail Support Framework

이건 사실 Utility성 패키지 입니다. Java에서 Mail을 보내는 효과적인 수단을 제공할 수 있습니다. 앞으로의 프로젝트가 인터넷을 이용한 서비스가 대부분 있는 만큼, 1-to-1 마케팅, 메일링 기능 등은 꼭 필요한 요소기술이 될 것이 보이며, 이러한 기술을 미리미리 준비해 두는 것인 손해 볼 일은 아니라고 봅니다. 이미 개발되어 있는 만큼, Framework에 추가하고자 합니다.
Sample Code:
try {
TemplateMail mailer = new TemplateMail();
Mailer.setTextAndHtmlTemplate(“template.text”, “template.html”);

Mailer.setFrom(“leewy7@kornet.net“,”홍길동”);
Mailer.setSubject(“안녕하세요”);

Mailer.setRecipient(“javaservice@hanmail.net“, “이원영”);
Mailet.setArg(“name”, “이원영”);
Mailet.setArg(“birthday”, “1999-06-28”);
Mailer.send();
}
catch(Exception e){
…
}

2.4.16 PCS Message Send Utility

019, 011 등과 같은 PCS로 문자메세지를 보낼 수 있습니다. 현재는 019 만 만들어져 있지만, 011,016,017,018 등 모두 만들어 제공하고자 합니다.
특히, 시스템 운영을 하다가, 특별한 이벤트가 발생했을 때, PCS로 문자 메시지를 보내주는 기능은 때론 꼭 필요한 기능이기도 합니다.

Try {
lgins.ec.pcsmsg.MessageService msg = new lgins.ec.pcsmsg.PCS019Service();
msg.setRecipientNumber(“019”, “357”, “3541”);
msg.setSenderName(“이원영”);
msg.setResponseNumber(“019”, “310”, “7324”);
msg.setMessage(“안녕하세요? 반가워요.”);
msg.open();
//msg.setProxy(“proxy.lg.co.kr”,”80″,null,null);
msg.send();
//System.out.println(msg.getResponse());
msg.close();
}
catch(Exception e){}

2.4.17 프로젝트를 위한 통합 인트라넷 시스템 게시판

모듈간의 연관관계를 자동으로 추출하는 도구, DBWrapper/Entity를 자동으로 생성 하는 도구, 프로젝트를 위한 게시판, Oracle DB Helper Site 등 생각해 보면, 프로젝트 초기에 구성해 주면 좋을 법한 내용들이 몇몇 있습니다. LG화재의 게시판 운영은 매우 효과적이었습니다. 이러한 부분에 대한 절차를 마련해 두어야 한다고 봅니다.
이러한 방법은 고객과 수주자간의 시스템적 분할을 하나로 합쳐 줌으로써 CSR처리 등 모든 프로젝트 전반의 내용을 공유함으로써 신뢰감 조성과 상하간의 투명한 업무처리효과를 기대할 수 있습니다.

2.4.18 산출물 Define Framework

이 부분은 사실 어려운 부분이기도 하며, OOAD 전문가와 상의를 통해, 프로젝트에서 꼭 필요한 산출물이 무엇이어야 하는가에 대한 Define작업이 있어야 합니다.
특히 Framework이란 부분이 첨가되면, Class Diagram, Sequence Diagram에서 빠져도 되는 부분이 생기게 됩니다. 예를 들어 JSP — Servlet — EJB — DBWrap 와 같은 구도에서 Framework이 사용되었을 때, 개발자들이 적어야 할 산출물의 샘플/Template을 미리 Define해 두면 차후 실 프로젝트에서 바로 적용하여 사용할 수 있을 것입니다.

3. Java Development Framework의 효용성

3.1 Web/OO 내재화의 최종산출물

현재 진행되고 있는 ITG 내부 프로젝트로 진행되고 있는 Web/OO 내재화의 산출물이 막바지 단계에 이르고 있습니다. 지금까지 나와 있던 그 어떤 문서보다도 많은 내용을 다루고 있으며 체계적인 정리를 해 내었다고 평가됩니다. 분명히 이 산출물은 문서를 만든 사람들의 스스로의 기술습득의 차원을 넘어서서 문서 자체로서의 가치가 있는 탁월한 산출물임은 분명합니다.
그러나 이 문서가 실 프로젝트에서 바로 적용할 수 있는 부분은 사실 거의 없습니다. 문서 내용의 구체적인 몇몇 부분에 대해서 잘못 설명되고 있는 부분은 차치하고서도 이 문서는 다분히 이론적인 부분에 상당히 치우쳐 있으며, 개념 설명에서 그치고 있습니다. 또한 문서에서 예시로 들고 있는 상당부분의 Sample Source 들은 개념설명을 위한 Source일 뿐 실 프로젝트에서 바로 사용할 수 있을 만큼 체계적으로 짜여져 있는 소스가 아닌 것도 사실입니다. 물론 그럴 수 밖에 없었음을 인정합니다.

다행스러운 것은 이 산출물의 마지막 Chapter로서 Java Development Framework의 내용이 기술되어 진다면 가장 이상적인 모습으로 승격될 수 있을 것이라는 것입니다. 모든 이론적인 설명에 끝남과 동시에 실 프로젝트에서 바로 적용할 수 있는 내용이 첨가됨으로써 독자로 하여금 실질적인 프로젝트의 착수단계로 인도할 수 있다는 것입니다.

3.2 교육대학원의 강의 도구로서의 역할

얼마 전까지만 하더라도 CGI에 관련한 강의가 교육대학원에 있었습니다. 아시다시피 CGI(Common Gateway Interface)는 HTTP를 이용한 아키텍춰의 하나입니다. CGI를 개발하기 위한 언어는 C를 이용하기도 하지만 Perl이나 ShellScript, C++ 심지어 Java로도 가능합니다. 그러나 교육대학원에서의 강의는 C 언어를 선택했고, ITG에서 어느 팀에선가 개발된 CgiLib 라는 C로 짜여진 Library를 이용했었습니다. 왜 CgiLib라는 Library가 필요했죠?
Framework 이 필요했기 때문입니다. CGI는 일종의 Specification 이라 볼 수 있으며, CgiLib는 그것을 C 언어로 구현할 수 있는 Framework 이기 때문입니다. 사실 CgiLib 는 그 개념과 범위를 볼 때 Framework이라기 보다는 API에 까가운 성격이었으나 어쨌든 그러한 Framework으로의 도출은 자연스럽게 언제 어디서나 발생됩니다.
마찬가지로, 최근 교육대학원에서는 웹과정을 속속 개설하면서 JSP, Servlet, EJB과정을 고려하고 있습니다. 물론 JSP, Servlet, EJB라는 개념은 CGI처럼 추상적인 개념 뿐만 아니라 물리적인 API도 포함하고 있는 Framework입니다. 그러나 이 Framework을 한번 더 구체화 시킨 Framework의 필요성이 있습니다.
바로 지금 하고자 하는 Java Development Framework이 적절한 선택이 될 것입니다.
교육대학원을 통한 전사적인 확산은 상당히 영향력을 갖고 있으며, 바람직한 방법이기도 합니다.

3.3 사업부에 대한 ITG기술지원의 극대화

앞서 잠깐 언급한 바와 같이 ITG의 사업부에 대한 기술지원의 방향성에서 개발자를 공급하는 용역업체로의 전락과 진정한 프로젝트 기술지원 사이에서 헤게모니를 장악할 수 있는 참신한 방안이 Java Development Framework의 개발과 확산입니다.
또한 기술적으로 앞서있는 몇몇 사람에게 프로젝트 파견의 짐이 쏠리는 현상을 타개할 수 있는 현명한 방안이기도 합니다.

3.4 고질적인 방법론과 개발기술의 불협화음 제거수단

물론 사람에 따라 정도의 차이는 있겠지만 일반적으로 개발기술과 구현을 고려하지 않는 방법론과, 방법론과 Design을 고려하지 않는 개발/구현 사이에서 불협화음은 끊이지 않았습니다. 그러나 OOAD의 탄생과 Java 언어의 출현은 많은 부분에서 두 진영의 자연스런 합일의 방향으로 인도하고 있는 바람직한 현상이 일어나고 있습니다. 그러나 여전히 구체적이고 물리적인 소스코드와 산출물이라는 부분에서는 아직 서로 뜬구름 잡는 얘기를 서로 다른 관점에서 하고 있는 것도 사실 입니다.
이 두 부분이 만나는 곳이 어딜까요?
바로 Development Framework입니다.
Java Development Framework는 방법론적인 관점에서 구체적인 산출물에 대한 정의를 해야 하며, OOAD의 디자인 관점에서 구현되어 져야 합니다. Java Development Framework에서 제공되는 Component는 이미 정형화된 산출물로 별도로 제공될 것이며, 이 Framework을 이용하여 프로젝트를 진행할 때는 그 Framework에 기초하여 개발자의 Business를 표현하는 산출물이 나와 주어야 합니다. 산출물에 기술할 내용의 범위도 아주 명확합니다. 많은 부분이 이미 Java Development Framework 내에서 기술되어 있으며, 개발자를 위한 산출물은 좀더 Business적인 부분만을 담고 있으면 됩니다.

4. Java Development Framework의 구현 방안

아무리 지금까지의 설명과 내용이 완벽하고 그 필요성을 인정한다고 하더라도 Framework 이라는 것은 물리적인 API로 제공되어져야 합니다. 실체가 있어야 한다는 것이지요.
국방시설, LG화재, 행자보 프로젝트를 통해 습득한 Know-how 만으로도 지금 일차적으로 구상하고 있는 전체 Java Development Frame의 약 20% 는 이미 만들어 졌다고 볼 수 있습니다. 그러나 결코 이 부분은 개발자 한 사람이 할 수 있는 성격도 아니며, 해서도 안됩니다.
몇몇 소수의 자바 개발자 뿐만 아니라 Java Development Framework을 사용할 최종 수요자가 될 국내 각 업체 종사자들, 그리고 각 업종에서 꼭꼭 숨어 있는 내노라 하는 모든 국내 자바 실력자들과 함께 작업은 이루어 져야 합니다.

구현과정과 결과물에 있어서 특정 집단의 잇권챙기기나 독점은 더더욱 있으면 안됩니다. 이러한 성격의 결과물은 한 집단의 이익이기 이전에 지금 국내 IT시장에서 SI가 살아남을 수 있는 총체적인 몸부림이라는 큰 개념의 산물임을 이 글을 읽는 독자는 인식해 주시기 바랍니다.