| sitelink1 | |
|---|---|
| sitelink2 | |
| sitelink3 | |
| sitelink4 | |
| sitelink5 | |
| extra_vars6 |
2005년말에 모 텔레콤 프로젝트에 Struts, Spring, Quartz와 iBatis(캐시에 OSCache+JGroup)를 이용해서 프로젝트를 마쳤습니다.
DB관련해서 얘기를 드리면 Spring설정으로 전체 트랜젝션을 관리하고 iBatis를 통해서 cache, ormapping 설정을 하였습니다.
DB 캐쉬는 OSCache+JGroup을 이용하여 Clustered Cache를 적용하였습니다.
Clustered 스케쥴러로 Quartz를 적용하였습니다.
- 개발기간 : 3개월( 1개월 분석/상위설계, 1.5개월 상세설계/개발, 0.5개월 테스트)
ㅇ 너무 짧았음 ;;;;
- 총투입인원 : 12명
- 맡은 롤 : 시스템일반화팀(총5명) 개발 PL
ㅇ 개발 일정 관리
ㅇ 프레임워크 선정/테스트/교육/상세설정
ㅇ 개발자에게 업무 전달
ㅇ 시스템 컴포넌트 일부 개발
- 총 소스 수
ㅇ 클래스 : 565개
ㅇ JSP : 252개
ㅇ 시스템 컴포넌트 : 5개
ㅇ 비즈니스 컴포넌트 : 23개
- Spring 이용 결과
ㅇ Singleton Application Contenxt 관리 XML 파일 : 1개
ㅇ Application Context 설정 XML 파일 : 3개
ㅇ 총 매핑한 Bean 수 : 52개
- iBatis 이용 결과
ㅇ iBatis init XML 파일 : 1개
ㅇ SQLMapping XML 파일(DAO개수와 동일) : 22개
ㅇ 총 매핑한 SQL 수 : 469개
- 시스템 성격 :
ㅇ 개인화 된 CRM서비스 제공
ㅇ 관리툴(통계포함) UI + 서비스 컴포넌트(모 텔레콤 일부서비스 코어업무수행) + 배치 프로그램 개발
ㅇ 관리툴과 서비스컴포넌트 설계/개발에 두번째 달부터 3명 투입 (+개발PL1명)
ㅇ 배치 프로그램 설계/개발에 두번째 달부터 3명 투입(+개발PL1명)
ㅇ 운영 서비스 : 웹서버 2대 + 4CPU WAS 서버 2대 + DB 서버 2대 [웹서버, WAS서버, DB 서버는 다른 애플리케이션과 자원 공유]
- 적용한 오픈소스 프레임워크/라이브러리
ㅇ spring
ㅇ ibatis
ㅇ struts
ㅇ quartz
ㅇ log4j
ㅇ jdom
ㅇ junit
ㅇ junitperf
ㅇ oscache
ㅇ jgroups
ㅇ jakarta-oro
ㅇ concurrent
ㅇ commons-logging
ㅇ commons-httpclient
ㅇ commons-lang
ㅇ commons-dbcp
ㅇ commons-pool
ㅇ commons-collections
ㅇ commons-threadpool
ㅇ commons-configuration
ㅇ commons-beanutils
ㅇ commons-digester
ㅇ commons-fileupload
ㅇ commons-validator
- iBatis Learning Curve :
ㅇ 기존에 SQL을 이용한 JDBC 코딩을 해보신분들(3명)을 대상으로 제가 샘플코드 만들고(제가 iBatis 이해하는데 1일) 샘플을 이용한 사용법 설명(30분)으로 모두 쉽게 이해를 하였음.
ㅇ 나중에 복잡한 기능은 오픈프레임워크 사이트에 있는 40Page 짜리 iBatis 한글 사용자 메뉴얼을 참조하라고 하였음.
(한글문서라 팀원 모두 쉽게 이해함. 이동국님 감사합니다 ^^)
- iBatis 개발 방법 :
ㅇ 개발자 분들은 트랜젝션과 캐쉬에 관계없이 개발하였음.(개발 시간 단축)
ㅇ 1차 기능 테스트 후 2일(2 Man Day) 정도 시간을 들여 Spring 설정 및 iBatis 설정을 통하여 DB 트랜젝션 및 캐쉬 일괄 설정
- 일반 JDBC과 비교한 iBatis 생산성 향상 :
ㅇ 일반 JDBC 프로그래밍보다 DTO와 PrepareStatement의 파라메터 매핑, 결과 DTO와 RS를 매핑하는데 드는 시간 및 노력 70%이상 절감.
ㅇ 품질비용(초기 개발이 잘못되어 기존 프로그램을 수정하는 비용) 대거 절감.
Connection 관리오류 사전 제거, 기본적인 에러를 Compile Time에 잡아줌.
일반 JDBC 개발방법에서도 SQL은 외부 Property 같은 것으로 추출한다고 했을때 가정임. 만약 SQL이 소스코드 내에 있다면 iBatis를 이용한 품질비용 감소폭은 더욱 커짐
ㅇ 프로그래밍으로 데이터 캐쉬를 적용하여 속도 향상하는 비용 대거 절감(애플리케이션 전체 캐쉬 설정하는데 1일이 채 안걸렸음(클러스터드 캐쉬(OSCache+JGroup) 배우는 시간 포함))
ㅇ 트랜젝션을 개발자마다 매번 설정하는 비용 절감
- Spring 및 iBatis 성능
ㅇ 전혀 문제 없었음. (부하테스트시 Active User 30명에 38TPS / 4CPU개발서버)
- 하이버네이트 대신 iBatis선택한 이유
ㅇ 매퍼를 선택하고 공부하는데 시간이 거의 없어서 iBatis를 선택. (하이버네이트는 Learning Curve가 크다는 소문이 있어서 엄두가 안났음, 실제로 iBatis는 오픈프레임워크 사이트의 40Page 한글 문서만 봐도 대부분의 기능을 사용할 수 있을 정도로 심플한 프레임워크임.)
ㅇ 또한 일반 SI에서는 하이버네이트보다 iBatis가 좋다는 인터넷 게시물을 참조하여 iBatis 선택
- 기타
ㅇ DDL2iBatis를 프로젝트 종반에 발견해서 생산성 향상을 더욱 못한게 아쉬움.
ㅇ Spring 및 Struts의 경우 기본적인 기능만 사용
. Spring : ⓐ Bean 호출, ⓑ 트랜젝션 처리, ⓒ iBatis, Quartz 초기 셋팅
. Struts : ⓐ URL 매핑
. Quartz : 스케쥴, 배치
. iBatis : OR 매핑
. OSCache : iBatis 결과 캐쉬
. JGroup : 멀티캐스트를 이용한 OSCache Clustered Cache 지원
--------------------------------------------------------------------------------------
ㅇ Spring, Quartz, iBatis, OSCache, JGroup을 팀원 모두 처음 사용하였으나 큰 Learning Curve 없이 개발완료하여 뿌듯.
ㅇ 나름대로 성공적인 프로젝트 였다고 판단.
ㅇ 다른팀이 개발한 컴포넌트를 개발해야 하는데 컴포넌트의 인터페이스를 자주 변경하여서 어려움이 있었음. 그리고, 명세도 잘되어 있지 않아서 향후 프로젝트에는 프로젝트 초기에 컴포넌트 인터페이스 명세를 확실히 하라고 해야 함..
- 여러가지 프레임워크와 오픈소스 기법을 적절히 찾아서 배치하는 것도 중요하지만(Technical한 관점) 컴포넌트 모델링은 더욱 중요하다고 생각된다. 특히 컴포넌트 설계시 인터페이스 설계에 대한 부분은 초기에 잘못 설계해 놓으면 품질비용이 크게 늘어난다. 자신이 만든 컴포넌트가 향후 Core 서비스가 될 수도 있다는 관점에서 인터페이스를 설계를 해야 한다. 마찬가지로 컴포넌트 추출도 역시 비즈니스(요구사항)를 충분히 이해한 상태에서 추출해야 한다.
ㅇ 초기 명세의 부족으로 개발자가 나중에 힘들어 하였음. 알고 있는 사항이지만 잘 실천되기 어려운 항목임.
ㅇ 관리의 이슈 발생!!(관리의 문제는 역시 쉬운 문제는 아님)
