델파이 /C++ 빌더 3tier 프레임워크 기반 업무 개발

델파이/C++빌더3tier 프레임워크 기반 업무 개발 Case Study: 3tier framework based business projectwith Delphi/C++Builder 볼랜드포럼 / 박지훈 imp@borlandforum.com

이 세션의 목적 • 업무 프로젝트에서의 표준화->프레임워크 • 왜 프레임워크화를 해야 하는가 • Delphi/C++Builder vs. Java/.NET 경쟁 • 웹 개발 방식들과 경쟁하여 살아남으려면 어떻게 할까 • Multi-tier 방식의 유용성과 구현 사례 • 어떤 경우에 Multi-tier가 유리하며 어떻게 구현할 것인가

업무 개발

업무 개발의 특성 - 1 • 일반적인 업무 프로젝트의 2대 이슈 • 실무자의 요구 파악 • 업무 배분 / 일정 준수 • 화면 단위 개발 • 화면들간의 연계성 적음 • 기술적 요구 스펙이 높지 않음 - 요구된 업무 로직 구현이 중요 • 계약직, 초급 위주로 개발하는 경우도 잦음 • PM/PL의 역할 • 일정 관리, 작업 배분에 치중 • 기술적 이슈, 표준, 통일성의 문제에는 소홀하기 쉬움

업무 개발의 특성 - 2 • 업무 개발 프로젝트의 진행 경향 • 단위 화면들 사이에 중복 코드가 많아짐 • 담당 개발자들 각각의 구현 방법이 다양할 수 있음 • 로직, 컴포넌트 선택, UI 디자인 • 백엔드 데이터베이스 구조와의 연계 방법 => 예상치 못한 버그/오동작의 가능성이 높아짐 => 크로스 테스트/디버깅의 어려움 • 실제 난이도에 비해 인수/인계 부하 증가 • 요구가 변경되었을 때의 유연성이 낮음 • 더 나은 방법은 없을까?

표준화 이슈 • 표준 수립의 효과 • 공통 코드 제거/최소화 ⇒ 코딩 및 코드 관리 시간이 줄어듦 • 공통 기술적 이슈 통합 관리 ⇒ 개발자들이 각각 시간을 소모하지 않도록 • 크로스 테스트, 인수인계 용이 • 표준화의 주요 대상 • 공통 루틴 라이브러리, 허용 라이브러리/컴포넌트 • Naming Convention • Hungarian? Prefix? Underscore? Camel Case? Pascal Case? • 공통 Data Access 방법 • 메인 App <-> 화면 사이의 interface • 코딩 기법의 제어 - 델파이/C++의 과도한 자유도는 생산성 저하 요인 • 테크니컬 아키텍트의 필요성 • 트러블슈팅 + 표준화 마스터 –개발 표준 수립/유지보수 + Framework 개발, 유지보수

개발 표준의 프레임워크화 • 공통 루틴 라이브러리의 한계 • 개별 개발자들에게 사용을 강제하기 어렵다 • 무분별한 공통 루틴 양산 - 관리의 어려움 • 프레임워크화 • 공통 화면 클래스(들) • 화면 객체의 표준 모듈화 • exe(X) dll? bpl? • 공통 Data Access 방법 • 공통 Main App 인터페이스 방법 • 화면 프로젝트와 기본 멤버들의 자동 생성

경쟁

업무 개발 - 경쟁 1 • 업무 개발 분야에서 언어/개발툴 동향 • Java(J2EE) - 압도적 다수 • .NET - 중/소규모 ASP.NET, 소수 (확산이 느림) • Delphi/C++Builder - 특화 분야 프로젝트 • 실시간성이 필요한 프로젝트 - HTS 등 • 하드웨어 인터페이스가 중요한 프로젝트 - ITS 등 • 역동적인 UI가 필요한 프로젝트 • 업무 개발과 Web • Java와 Web은 동반 성장해옴 • Java가 환영 받는 이유? • Java는 방법론/프레임워크 표준화와 함께 발전해옴 • 통상적 업무 개발에 적합 - 시스템 접근성을 거세 => 일정 예측성 => Java/.NET에서도 웹의 부족한 UI에 문제의식 대두

업무 개발 –경쟁 2 • X Internet, RIA • 웹 기반 업무 개발의 부족한 UI를 보충하는 역할 • Backend는 기존의 웹 방법론을 그대로 유지 • 사용자들의 불만/요구로 최근 급속하게 도입 확산 • MiPlatform, Curl, Flex, MS SmartClient, Silverlight • X Internet vs. Native • 풍부한 UI와 실시간성은 Native 개발의 절대 강점 • UI vs. UI의 대결 - Native의 장점 부각 가능 • 사용자도 더 이상 “웹!”을 외치지 않는다 => Native 개발에 부족한 알파 • Framework - 표준화 및 개발 생산성 • Multi-tier - 서비스의 안정성, 확장성, 신뢰성

X Internet 사례 – 1. 로그인

X Internet 사례 – 2. 실행화면

X Internet 사례 – 3. 개발툴

X Internet 사례 – 4. 스크립트

프레임워크 구현

프레임워크 구현 - 1 • 커스텀 폼 class (vs. TForm / TFrame) • 업무 프로젝트에 맞게 property, event 추가 및 제거 • 기술적 이슈 • 디자인타임 Object Inspector에 property가 나타나지 않음 • 커스텀 폼을 IDE에 등록하여 해결 • RegisterCustomModule()

(계속) • 커스텀 폼 클래스 구현 TBizForm = class(TCustomForm) protected (기존 동작 override) public (메소드 추가) published (property 추가) (event 추가) end; • IDE에 커스텀 폼 클래스 등록 RegisterCustomModule(TBizForm, TCustomModule); • 메인 App에서 클래스 등록 RegisterClass (TCF5211);

프레임워크 구현 - 2 • 화면 프로젝트 - 패키지(bpl) (dynamic loading) • 메인 App과의 인터페이스 자유로움 • IDE 자체와도 자유롭게 연동 (디자인타임에도 동작) • 디자인타임 컴포넌트화도 가능 • bpl 로드 - LoadPackage(Path); • 커스텀 폼을 로드할 경우 클래스 타입을 인식하지 못한다 • (무슨 폼 클래스).Create ? • 화면 bpl 쪽 - RegisterClass() 호출로 클래스 등록 • 메인 App 쪽 - FindClass()로 클래스를 얻은 후 폼 생성

(계속) 화면 bpl 쪽 initialization RegisterClass(TCF5211); finalization UnregisterClass(TCF5211); 메인 App 쪽 type TBizFrameClass = class of TBizFrame; var AIndex: integer; AForm: TBizForm; FrameClass: TBizFormClass; begin ... LoadPackage(PackagePath); FrameClass := TBizFormClass(FindClass('TCF5211')); AForm := TBizForm(FrameClass.Create(AOwner)); Aform.Show;

프레임워크 구현 - 3 • 폼/프로젝트 Wizard • IDE에서 자동으로 업무용 커스텀 폼/프로젝트를 생성 • 개발자가 중요하지 않은 문제에 집중하지 않도록 한다 공통 함수, 공통 추가 컴포넌트, 공통 property 값 등 • Uses ToolsAPI • Wizard/Creator 인터페이스 구현 클래스 작성 • Wizard • IOTAFormWizard, IOTAProjectWizard, IOTARepositoryWizard • Creator • IOTAProjectCreator, IOTAModuleCreator • 화면 프로젝트 기본 설정들 미리 적용 • lib dir, output dir, run param, version info ...

프레임워크 구현 - 4 • Core 인터페이싱 데이터모듈 bpl (static loading) • 메인 App (exe) -> 화면 bpl 인터페이스는 용이 • 화면 bpl -> 메인 App (exe) 인터페이스는 곤란 • 메인 App의 기능들 중 화면 bpl과 인터페이스가 필요한 기능은 중앙 bpl로 분리 • DB connection, Access control ... • bpl 폼 로딩 및 관리 루틴

Multi-tier

Why Multi-tier? • 소규모 환경에서의 성능은 이슈가 아님 • 적은 유저, 적은 부하 환경에서는 2티어가 성능상 유리 • 데이터는 티어 개수만큼의 경로를 거침 • 고려사항 - DB 서버 부하 vs. 각 티어 데이터 전달 단계 • 멀티티어의 장점 • 보안성 - DB 서버 직접 액세스 차단, 암호화/보안 기능 추가 가능 • 미들 서버의 존재 - DB 연결 풀링, 데이터 캐싱 • 확장성 - 다수의 DB 서버, 다수의 미들 서버 • 안정성/신뢰성 - Load Balancing, Fail Over • 멀티티어의 단점 • 아키텍처가 복잡, 코드량 증가 • 디버깅 난점

Delphi Multi-tier 방법의 선택 - 1 • DataSnap(MIDAS) • 기본 내장 컴포넌트, 추가 비용 없음 • Delphi7+ / C++Builder6+ • 간편하고 가벼우며 구조 간단 • 복잡한 업무 구현에는 기능 부족 • ECO • 기본 내장 프레임워크(Delphi8+), 추가 비용 없음 • 코드기어의 주력 • 모델링 기반 개발 방법론 (MDA) • 기존 델파이 개발 방식과 다른 방식 • .NET 필수! No Win32! • No C++Builder • 2007부터 VCL.NET 지원 • But, way to go. (다음 세미나엔…? ^^)

Delphi Multi-tier 방법의 선택 - 2 • TP Monitor 등 상용 미들웨어 제품 • 고비용 - per 서버! • 패키지 판매 제품이므로 지원 기능 스펙에 제한 • 다양한 서버쪽 추가 기능 구현 불가 • Delphi 구현은 클라이언트에 국한 • 금융기관, 대형병원 등에서 사용 • 상용 Delphi 미들웨어 컴포넌트 라이브러리 • 저비용 (수백 달러) • DataSnap보다 강력한 기능 / 높은 성능 • 광범위한 기능 추가 가능 • kbmMW, RemObjects, RealThinClient, MidWare, ASTA ...

Why kbmMW? • kbmMW의 장점 • 기존 델파이 방식과 유사 • 높은 성능 (kbmMemTable, 패킷 압축 등) • 무료 버전 존재, 소스 제공 (상용) • 다양한 외부 데이터 액세스 / 통신 / 암호화 컴포넌트 등을 지원 • Java, C#, PHP와도 연동 가능 • 다양한 부가 기능 • load balancing, file service, messaging 등 • kbmMW의 단점 • 기능이 너무 다양 -> 제대로 쓰려면 공부할 게 엄청 늘어난다 • 소소한 버그가 약간 있다 • 데이터 페이징이 안된다

kbmMW 서버 메인 • 서버 메인은 일반 모듈 형식 • TkbmMWServer 컴포넌트 • TkbmMWTCPIPIndyServerTransport 컴포넌트 • 클라이언트와의 패킷 전송 담당 • TkbmMWADOXConnectionPool 컴포넌트 • DB 커넥션 풀링

kbmMW 서비스 객체 • 서버측 단위 모듈 –서비스 (개별 화면과 대응) • TkbmMWCustomService • 일반 클래스 유닛(pas), 서버측 함수 호출 컨테이너 클래스 • TkbmMWQueryService • 커스텀 모듈(dfm+pas), Query/StoredProc 컨테이너 모듈

서비스측 컴포넌트 • Resolver • TkbmMWServerQuery • TkbmMWServerStoredProc

클라이언트 화면 컴포넌트 • TkbmMWClientQuery • TkbmMWClientStoredProc • TkbmMWClientTransactionResolver

Troubleshooting • bpl은 바이너리 의존성이 대단히 높다 • dll과 달리 클래스 인터페이스이기 때문 • 특히 Core 모듈 bpl • interface 섹션 (not implementation) • 주의! 전체 재컴파일을 해야 할 경우가 잦을 수 있음 => Core 모듈 클래스에 무분별한 추가/변경 금지

정리 • 프레임워크화 • 표준화의 연장선상에서 진행 가능 • 보다 효율적인 개발 진행 • 업계의 트렌드 (C/S 툴이라고???) • Multi-Tier • 보안성, 확장성, 안정성 • Java 등과 경쟁하려면 • 프레임워크화와 병행하면 추가 부하는 크지 않다

델파이 /C++ 빌더 3tier 프레임워크 기반 업무 개발