PMC · Web view차세대 정보시스템 구축을 위한 아키텍처 결정의 기본요소로는...

소프트웨어아키텍처정의서기술보증기금 차세대 정보시스템 구축

SW 아키텍처 Version 1.5

경기도 성남시 분당구정자동 25-1 번지

SK u-타워

소프트웨어 아키텍처 정의서 진행단계 설계단계

작성일자 2008/03/28

프로젝트 기술보증기금 차세대 정보시스템 구축 시스템구분 시스템 작 성 자 김강석

업무영역 SW 아키텍처 문서식별자 KIBO_AA_아키텍처정의서

Authorization

Client Approval:

승인자 : (인) 일자 :

검토자 : (인) 일자 :

SK C&C Approval:

승인자: 최준 (인) 일자 : 2008-3-28

검토자: 박연숙 (인) 일자 : 2008-3-28

작성자: 김강석 (인) 일자 : 2008-3-28

제.개정 이력

1.4 아키텍처 정제 3 차 2008-3-28

1.3 아키텍처 정제 2 차 2007-11-23

1.2 아키텍처 정제 1 차 2007-10-5

1.1 아키텍처 설계 2007-7-27

1.0 제 정 2007-6-22

개정번호 제.개정 페이지 및 내용 제.개정 일자

File 명: document.doc 2


작성일자 2008/03/28



목 차1. 개요 (OVERVIEW)..................................................................................................6

1.1 목적..................................................................................................................................6

1.2 시스템 개요.....................................................................................................................6

1.3 약어 설명.........................................................................................................................7

2. 아키텍처 결정요인 및 전략.....................................................................................82.1 아키텍처 결정의 기본요소............................................................................................8

2.2 요구 품질 속성................................................................................................................9

2.3 아키텍처 결정 전략......................................................................................................12

3. 종합 소프트웨어 아키텍처....................................................................................153.1 종합 동적 뷰..................................................................................................................15

3.2 종합 배포 뷰..................................................................................................................16

4. 기간계 아키텍처.....................................................................................................174.1 개요................................................................................................................................17

4.2 논리 뷰(LOGICAL VIEW)................................................................................................18

4.3 주요 영역 ARCHITECTURE 구성 뷰...............................................................................21

4.3.1 PRESENTATION 레이어...........................................................................................................21

4.3.2 PROCESS 레이어.....................................................................................................................28

4.3.3 BIZ LOGIC 레이어..................................................................................................................41

4.3.4 INTEGRATION 레이어.............................................................................................................44

4.3.5 BATCH 프로그램....................................................................................................................56

4.3.6 보안 부분...........................................................................................................................63

4.3.7 LOGGING.................................................................................................................................68

4.3.8 기타....................................................................................................................................71

4.4 구현 뷰(IMPLEMENTATION VIEW)..................................................................................84

4.4.1 APPLICATION 패키지 구성.....................................................................................................85

4.4.2 X-INTERNET/REPORTING UI 패키지 구성.............................................................................86

4.4.3 REPORTING 서버 패키지 구성...............................................................................................87

4.5 배포 뷰(DEPLOYMENT VIEW)........................................................................................88

4.5.1 APPLICATION PACKAGING......................................................................................................88

4.5.2 APPLICATION TOPOLOGY........................................................................................................97



작성일자 2008/03/28



5. 정보계 아키텍처.....................................................................................................995.1 개요................................................................................................................................99

5.2 논리 뷰(LOGICAL VIEW)..............................................................................................101

5.3 주요 영역 ARCHITECTURE 구성 뷰.............................................................................103

5.3.1 PRESENTATION 레이어.........................................................................................................103

5.3.2 PROCESS 레이어...................................................................................................................106

5.3.3 BIZ LOGIC 레이어................................................................................................................116

5.3.4 INTEGRATION 레이어...........................................................................................................118

5.3.5 보안 부분.........................................................................................................................119

5.3.6 기타..................................................................................................................................123

5.4 구현 뷰(IMPLEMENTATION VIEW)................................................................................128

5.5 배포 뷰(DEPLOYMENT VIEW)......................................................................................131

5.5.1 APPLICATION PACKAGING....................................................................................................131

5.5.2 APPLICATION TOPOLOGY......................................................................................................133

6. 사이버 영업점 아키텍처......................................................................................1356.1 개요..............................................................................................................................135

6.2 논리 뷰(LOGICAL VIEW)..............................................................................................136

6.3 주요 영역 ARCHITECTURE 구성 뷰.............................................................................137

6.3.1 PRESENTATION 레이어.........................................................................................................137

6.3.2 PROCESS 레이어...................................................................................................................139

6.3.3 BIZ LOGIC 레이어................................................................................................................145

6.3.4 INTEGRATION 레이어...........................................................................................................147

6.3.5 보안 부분.........................................................................................................................151

6.3.6 기타..................................................................................................................................153

6.4 구현 뷰(IMPLEMENTATION VIEW)................................................................................157

6.5 배포 뷰(DEPLOYMENT VIEW)......................................................................................160

6.5.1 APPLICATION PACKAGING....................................................................................................160

6.5.2 Application Topology...........................................................................................................162



작성일자 2008/03/28



1. 개요 (Overview)

1.1 목적

이 문서는 기술보증기금을 위한 차세대 정보시스템의 소프트웨어 아키텍처를 정의한 문서이다. 이 문서에서는 차세대정보시스템 다양한 아키텍처적인 결정사항과 구조를 표현하고 있으며, 기술보증기금 차세대 정보시스템의 소프트웨어 어플리케이션은 이를 기반으로 구축된다.

1.2 시스템 개요

본 시스템 구축 목적은 차세대 정보 시스템 구축으로 기술보증기금의 Vision 2010 을 달성하여 차세대 성장 동력을 창출하고 기술금융을 선도하는 기금이란 경영 비전을 성취하여 기술보증기금의 경영이념을 구현하는 것이다. 본 시스템은 최신 솔루션을 적용하여 보다 효율적이고 운영하기 편리한 차세대 정보 시스템을 구축 한다.

기술보증 차세대 정보시스템은 다음과 같은 영역으로 구분되어 있다. 기간계 영역



작성일자 2008/03/28



기술보증기금의 기간계 업무(영업, 본부지원)를 담당하는 영역이며, 비즈니스를 담당하는 비즈니스 컴포넌트와 공통 컴포넌트를 관리하고 그와 연관된 데이터를 총괄 관리한다.

정보계 영역기간계를 비롯한 레거시시스템으로부터 다양한 정보를 수집하여 분석하여 기술보증기금의 차세대 정보계 시스템은 경영지원을 위한 신속, 정확한 의사결정 체계를 제공한다.

1.3 약어 설명

약어 풀이 비고

BPM Business Process ManagementBRB Business Rule Builder Rule 작성 ToolBRE Business Rule Engine Rule 기동 엔진DM Data MartEAI Enterprise Application IntegrationEC Entity ComponentEDW Enterprise Data WarehouseEIS Executive Information SystemEP Enterprise PortalETL Extract, Transform and LoadIPPR Input Pre-Processor 프레임워크 통신영역MCI Multi Channel Integration 대외 채널 통함연계OLAP Online Analytical ProcessingOPPR Output Pre-Processor 프레임워크 통신영역PC Process ComponentPOJO Plain Old Java Object 순수자바클래스PFM ProFrame 프레임워크RBMS Rule Based Management SystemSSL Secure Sockets LayerSSO Single Sign OnVO Value Object



작성일자 2008/03/28



2. 아키텍처 결정요인 및 전략

2.1 아키텍처 결정의 기본요소

차세대 정보시스템 구축을 위한 아키텍처 결정의 기본요소로는 다음과 같은 요소들이 있다.

확장성 (Extensibility) Rule Engine 을 도입하여 다양한 상품의 로직을 유연하게 신속하게 반영한다. 프레임워크를 도입하여 업무 컴포넌트의 유지보수성, 재활용성, DB 처리의 유연성을 통해

확장성을 확보한다. 보안 (Security)

주요 데이터의 암호화/복호화를 통해 정보를 보호한다. SSO 의 사용으로 사용자 권한을 관리한다. 인사 ERP 에 대한 어플리케이션 접속 권한 관리 및 데이터 암호화

성능 (Performance)

소프트웨어 아키텍처의 최적화를 통해 사용자의 증가, 시스템의 증가에 대해서 기본적인 성능을 보장할 수 있도록 한다.

사용자의 편의성 (Usability)

사용자 통합을 위한 포털 서버를 도입하여 다양하고 계층적인 서비스를 통합하여 관리한다. Single Sign On 서비스를 도입하여 기술보증기금 시스템 사용의 편의성을 제공한다. X-Internet 을 이용한 UI 의 표준 도입으로 사용자 위주의 UI 설계 및 서비스 변화 환경에

유연하게 대처한다.

연계성, 상호운용성 (Interoperability) 대외 채널 및 대내 시스템과 유연한 연동을 위한 다양한 프로토콜의 제공과 연계 환경을

제공한다.

안정성 (Availability) 시스템의 영속적인 서비스를 위하여 Active-Active 환경을 구성한다. 24 * 365 지원을 위해 시스템을 이중적으로 구성한다.



작성일자 2008/03/28



2.2 요구 품질 속성

아키텍처 결정요인으로서 품질속성을 다음과 같이 정의한다. 이 품질속성은 차세대 정보시스템 소프트웨어 아키텍처를 정의하기 위한 품질속성이다. 또한 측정요소로서 정의한 부분은 아키텍처 구성시 기준으로 활용하게 되므로 시스템테스트 등에서는 별도의 세부기준을 수립하여 진행한다.

ID 요구사항 명 요구사항 설명 유형 측정요소 중요도RQ-STM-SA-1-01

응답속도동시사용자 처리수

사용자가 어플리케이션시스템을 사용 하려할 때, 조회/저장의 처리속도가 평균 3초 이내로 처리하여 결과를 제공하여야 한다. (단, 예외 특이건에 대해서는 해당 시점에 협의하여 성능목표를 정함)기간계 시스템은 100TPS(초당 처리 트랜 잭션)이상의 성능을 보장하여야 한다. ( ●동시 접속 사용자 수(330 명) = (전체 사용자 수(1100 명 ) * 30%) ●현 시스템 TPS (33.0) = 동시 접속 사용자수(330) * 10% ●향후 업무 및 사용자 증가율 반영 TPS(100) = 현재 시점 TPS (33.0) * 업무 증가량(2.0) * 사용자 증가량(1.4)

)

성능 평균 3 초 (예외 : 특이작업 제외)

●향후 업무 증가 : 현재 시점에서 차세대 시스템 오픈 후 3 년까지 매년 20%씩 증가한다고 가정●향후 사용자 증가 : 현재 시점기준 차세대 시스템 오픈 후 3 년까지 40% 증가한다고 가정

상

RQ-STM-SA-1-02

배치작업 처리량

시스템에서 특정시간에(예:자정) 마감작업과 같은 일괄작업을 처리할 경우, 처리기준은 기간계 일괄작업의 처리시간내에 모두 처리가능하여야 한다. (예: 파일 의 DB 업로드, DB 의 파일생성)

성능 중

RQ-STM-SA-1-03

서비스 중단 없는 기능변경 또는 추가

업무 모듈의 변경이 발생하였을 경우 전체시스템을 중단하지 않고 변경된 부분만 시스템에 반영될 수 있어야 한다.

가용성 업무 모듈 변경 시 전제 시스템 중단 여부

상

RQ-STM-SA-1-04

인증 허가되지 않은 사용자는 시스템에 접근할 수 없어야 한다. 또한 사용자의 작업이 일정시간 동안 없을 경우 시스템이 자동으로 로그아웃을 해야한다.

보안성 인증 동작 여부세션 타임아웃 동작 여부

중

RQ-STM-SA-1-05

권한 시스템 관리자가 조직변경에 따른 권한변경이 발생하고 이에 대한 결정이 확정된 경우, 이를 인사시스템에 반영한 익일에는 변경된 권한이 적용되어야 한다.

보안성 권한 적용 여부권한 변경 시 반영 여부

중

RQ-STM-SA-1-06

데이터 보안 주요 데이터에 대해서는 컬럼단위로 암복호화 가능해야 한다.

보안성 컬럼 별 DB 데이터 암복호화 여부

중



작성일자 2008/03/28



RQ-STM-SA-1-07

시스템 연계성 기간계 시스템과 타시스템(내부, 외부)의 연계는 표준화된 방식으로 구성하여, 향 후 단순 업무의 변경의 경우나 업무 요건이 추가되어도 쉽게 반영할 수 있어야 한다.

상호운용성

각 연계 시스템 별 표준 인터페이스 적용 여부

중

RQ-STM-SA-1-08

시스템 용량 확대시 재구성의 용이성

시스템 운용자가 현 시스템의 사용 부하 발생으로 시스템용량의 확장이 필요하다고 판단하였을 때 Application 의 내부로직의 변경없이 설정변경등으로 확장할 수 있어야 한다.

확장성 시스템 용량 확장 시 Application 추가 디플로이 가능 여부

중

RQ-STM-SA-1-09

로그인단일화 및 사용편리성

한번의 로그인으로 타시스템 연계가 가능해야 한다. 또한 사용상 편리성을 제공해야 한다.

사용자편의성

SSO 적용 여부강력한 UI 기능 제공 여부

중

RQ-STM-SA-1-10

네이게이션 용이성

웹화면에서 원하는 정보에 대한 손쉬운 검색을 위하여 적절하게 정보를 배치하여야하고, 위치에 따른 메뉴의 Depth 를 최소화 하여야한다.

사용자편의성

화면 구성에 대한 사용자 만족도 여부 메뉴 Depth 4 이하 여부

중

RQ-STM-SA-1-11

검색 편리성분산되어 있는 시스템의 정보를 한곳에서 통합 검색할 수 있어야 한다.

사용자편의성

검색엔진 적용여부 중

RQ-STM-SA-1-12

시스템 영속성

여하의 이유로 사용자의 요청에 대한 서비스 제공을 하지 못할 경우, 즉시 pair 시스템에서 해당서비스를 제공하여 24*365 를 실현한다.

안정성

주요 시스템 및 네트워크 이중화 여부

중

RQ-STM-SA-1-13

소프트웨어의 재사용성 확보(동일 기능 중복개발 배제)

동일한 기능에 대해 소프트웨어의 중복개발 없이 호출하여 사용할 수 있는 기반을 제공하여야 한다.

재사용성

프레임워크 및 공통컴포넌트 사용 여부

중

RQ-STM-SA-1-14

실시간 처리

정보계 시스템을 위한 자료 취합은 일일마감과 실시간정보로 나뉠수 있는데, 특정 정보에 대해서는 실시간으로 정보계 시스템에 반영되어야 한다.

성능

실시간 반영 여부 중

RQ-STM-SA-1-15

변경 최소화각종 ActiveX, 보안패치, 브라우저 버전 등으로부터 사용환경의 변경이 최소화 되는 방안으로 시스템을 구축하여야 한다.

독립성사용자 PC 환경에 설치되는 프로그램 최소화 여부

중

RQ-STM-SA-1-16

입력 편의성Text-Box 에 입력하는 기본언어는 한글로 설정한다.

사용자편의성

기본 한글 입력 지원 여부 중

RQ-STM-SA-1-17

사용 편의성

사용자가 특정업무 화면에 대하여 필요한 메모를 작성하여 저장하고 화면에 접근할때 마다 참조 및 수정이 가능한 기능을 구현한다.

사용자편의성

하

RQ- 보고서 조회/ 사용자가 특정 업무 화면에 대하여 보고서 사용자 Web Reporting 기능 제공 중



작성일자 2008/03/28



STM-SA-1-18

출력형태로 데이터를 조회 및 출력할 수 있는 기능을 구현한다.

편의성여부

RQ-STM-SA-1-19

비상 로그인

통합 로그인을 기본적으로 사용하되 관련 시스템의 장애 시에도 시스템별로 접근할 수 있도록 하는 비상 로그인 기능을 구현한다

보안성

SSO 장애시에도 각 Application 을 정상 사용할 수 있는지 여부

하

RQ-STM-SA-1-20

인증서 기반 로그인 및 데이터 통신 암호화

기금 외부 사용자가 시스템에 접근할 시 공용망 상에서의 사용자의 정확한 신원 파악과 주요 데이터에 대한 암복호화 기능을 구현한다.

보안성

인증서 기반 로그인 지원 여부웹 구간 주요 데이터 암복호화 기능 제공 여부

중

RQ-STM-SA-1-21

기간계 내부 시스템 간 연계

기간계 내부 시스템 간에 트랜젝션이 보장되는 상태에서 원격으로 서비스를 호출하는 기능을 구현한다.

상호운용성

원격 호출 지원 여부 중

RQ-STM-SA-1-22

동시성 관리주요 데이터를 동시에 접근하는 경우 한 사용자가 다른 사용자가 변경한 내역을 덮어쓰는 것을 방지해야 한다.

안정성동시성 기능 지원 여부 하

RQ-STM-SA-1-23

업로드 파일 공유

한번 업로드된 파일은 기간계 서버 간에 공유할 수 있도록 하여 서비스에 이상이 없도록 한다.

안정성클러스터링 환경에서 원활한 파일 업로드 다운로드 기능 지원 여부

하

RQ-STM-SA-1-24 배치 프로그램

구동 다양성 지원

배치 프로그램은 스케쥴러에 의해 구동되기도 하고, 사용자의 의해 직접 구동되기도 한다.배치 프로그램 간의 선후 처리가 가능하도록 해야 한다. 같은 프로그램이라도 트랜젝션을 분할하여 부분 커밋이 가능하도록 한다.

안정성

동일한 배치 프로그램의 온라인 실행 및 오프라인 실행 가능 여부

중



작성일자 2008/03/28



2.3 아키텍처 결정 전략

속성ID

요구사항 명 아키텍처 구성 전략요구품질

검증(측정)방법RQ-STM-SA-1-01

응답속도동시사용자 처리수

프레임워크 활용, 전문처리의 합리화(프레임워크 자체의 Value Object 구성을 활용한다.)웹서버의 활용으로 정적데이터 분리한다. 처리량을 위한 인스턴스 및 서버를 분리한다.복수의 데이터가 하나의 트랜젝션으로 묶이는 경우 JDBC 의 executeBatch 를 사용하도록 한다.

핵심 업무 모듈이 구현되는 시점에서 실제 운영환경에서 성능테스트 도구를 가지고 검증한다.(실운영환경과 동일한 환경에서 사용자 화면으로부터 DB 까지의 하나의 트랜젝션을 기준으로 조회, 추가, 수정, 삭제 작업을 테스트 함. )

RQ-STM-SA-1-02

배치작업 처리량

배치 전용 프레임워크를 별도로 구성한다..배치 전용 API 활용한다.

핵심 업무 모듈이 구현되는 시점에서 실제 운영환경에서 성능테스트 도구를 가지고 검증한다.

RQ-STM-SA-1-03

서비스 중단 없는 기능변경/ 추가

Hot Deploy 기능이 가능하도록 구성한다. 프레임워크 자체 테스트로 검증한다. (인스턴스의 중단없이 업무클래스 배포가능여부 확인)

RQ-STM-SA-1-04

인증 SSO 솔루션을 적용하고 이에 대한 연계 구조를 설계한다.

통합테스트시 확인한다. (단일 로그인을 통해 EP 를 포함한 각종 시스템에 접근 가능한지를 테스트)

RQ-STM-SA-1-05

권한 사용자정보 DB 와 SSO 와 연계 및 권한 부여를 위한 구조를 만든다.

통합테스트시 확인한다.(특정 Role 에 속한 사용자의 권한이 EAM 에서 정의한 바대로 적용되는지를 테스트; 또한 권한 변경 시 반영 여부를 테스트)

RQ-STM-SA-1-06

데이터 보안 DB 보안 툴을 적용하여 주요데이터에 대한 암호화를 실시한다.

보안툴 적용후 자체 테스트로 검증한다.(DB 컬럼에 대한 암/복호화 육안 확인)

RQ-STM-SA-1-07

시스템 연계성 MCI, EAI 솔루션을 적용하고 프레임워크와 연동 및 향후 유지보수가 용이한 구조가 되도록 인터페이스를 표준화.

파일럿을 통해 기본 구조를 검증한다. 설계 개발시 업무요건에 따른 지속적인 검증이 필요하다.

RQ-STM-SA-1-08

시스템 용량 확대시 재구성의 용이성

유지보수 및 운영이 용이한 형태로 어플리케이션의 배포 구조를 구성한다.

배포 뷰를 통해 검증한다.

RQ-STM-SA-1-09

로그인단일화 및 사용편리성

SSO 적용 및 X-Internet 과의 상호 인터페이스를 최적화 한다.

프로토타이핑 테스트시 확인한다.SSO 적용 확인은 통합테스트 시 확인하도록 한다.



작성일자 2008/03/28



RQ-STM-SA-1-10

네비게이션 용이성

화면 UI 설계 및 메뉴 구조 설계시 메뉴Depth 를 최소화하는 형태로 구성하고 이를 위하여 적절한 정보의 배치를 설계한다.

통합테스트 시 확인한다.(필요 정보에 대한 검색 단계 검증)

RQ-STM-SA-1-11

검색 편리성 검색엔진을 도입하여 대내외 시스템의 정보를 통합 검색할 수 있도록 한다.

통합테스트 시 확인한다.(검색의 정확성 및 검색시간 검증)

RQ-STM-SA-1-12

시스템 영속성

프레임워크를 통한 트랜젝션을 표준화하고 구현한다.복수개의 인스턴스를 구성할 수 있는 구조를 만든다.

배포 다이어그램을 통한 검증과 더불어 통합테스트시 검증하도록 한다.(시스템 테스트시 테스트)

RQ-STM-SA-1-13

재사용성컴포넌트기반의 프레임워크 구조 및 설계 환경 제공

설계 및 코드 리뷰시 검증한다.프레임워크의 공통 API 를 확인한다.

RQ-STM-SA-1-14

실시간 처리기간계의 실시간 조회는 EIS 에서 직접 기간계 DB를 접근하는 구조로 구축한다.

통합 테스트 시 검증한다. (실시간 데이터에 대한 조회 가능 여부)

RQ-STM-SA-1-15

변경 최소화

클라이언트에 설치되는 제품 (X-Internet, Reporting, PKI, SSO)선정 시 다음을 고려하도록 한다:가급적 업계 표준인 제품을 사용하도록 한다.다양한 사용자 환경을 지원하는 제품을 사용한다. 제품 업그레이드 시 지원 환경을 반드시 고려한다.

각 제품의 클라이언트 지원환경을 확인한다. 통합 테스트 시에 현업 사용자가 사용하는 다양한 종류의 단말기를 동원하여 검증한다.

RQ-STM-SA-1-16

입력 편의성X-Internet 에서 입력 모드를 자동 전환하는 기능을 활용한다.

프로토타이핑 테스트 시 검증한다.(Text Box 에 입력을 할 때 한/영 전환을 하지 않아도 자동으로 한글이 입력되는지를 테스트)

RQ-STM-SA-1-17

사용 편의성공통 기능으로 제공하도록 한다. 부하를 고려하여 가급적 클라이언트에 저장하는 방식으로 한다.

통합 테스트 시 검증한다.(TBD)

RQ-STM-SA-1-18

보고서 조회/출력

Reporting 제품을 도입한다. 보고서 출력 성능을 최적화하는 방향으로 UI 및 서버 측과 연동하도록 한다.

통합 테스트 시 검증한다.(Reporting 도구를 통해 정확한 데이터가 원하는 형태로 출력되는지를 테스트)

RQ-STM-SA-1-19

비상 로그인SSO 이외에 별도로 로그인을 할 수 있는 기능을 공통으로 제공한다.

통합 테스트 시 검증한다.(SSO 를 비활성화한 상태에서 각 Application 에 로그인할 수 있는지를 테스트)

RQ-STM-SA-1-

인증서 기반 로그인 및 데이터 통신

PKI 기반 인증서를 도입한다. 성능을 고려하여 필요한 데이터만 암호화한다.

통합 테스트 시 검증한다.(PKI 인증서를 통해 시스템에 로그인할 수 있는지를 테스트; 또한



작성일자 2008/03/28



20암호화

서버 로그를 통해 선택한 데이터가 암복호화되는지를 테스트)

RQ-STM-SA-1-21

기간계 내부 시스템 간 연계

기간계 내부 시스템 간은 EAI 를 거치지 않고 직접 원격호출을 하도록 한다. 프레임워크에서 제공하는 service to service call 을 활용한다.

통합 테스트 시 검증한다.(기간계 시스템 원격 호출 여부를 테스트)

RQ-STM-SA-1-22

동시성 관리공통 기능으로 제공하도록 한다. 업무 별로 동시성 체크가 필요한 부분에 적용한다.

통합 테스트 시 검증한다.(복수의 사용자가 동일한 데이터를 조회한 뒤, 한 사용자가 업데이트를 한 후 다음 사용자가 overwrite 할 수 있는지를 테스트)

RQ-STM-SA-1-23

업로드 파일 공유

NFS(Network File System)를 사용하여 업로드 파일을 공유할 수 있는 파일 시스템을 구성한다.

시스템 구성도를 확인한다. 통합 테스트 시 검증한다.(클러스터링 환경에서 업로드한 파일을 원활히 다운로드할 수 있는지를 테스트)

RQ-STM-SA-1-24

배치 프로그램 구동 다양성 지원

동일한 배치 프로그램을 온라인/오프라인으로 구동할 수 있도록 한다. 배치 프로그램은 프레임워크 기반으로 구현하도록 한다.

통합 테스트 시 검증한다.(동일한 배치 프로그램을 온라인 및 오프라인으로 실행할 수 있는지를 테스트)



작성일자 2008/03/28



3. 종합 소프트웨어 아키텍처

3.1 종합 동적 뷰

차세대 정보시스템의 종합적인 런타임 뷰는 위의 그림과 같다.

사용자는 SSO 를 통해 개인 인증 및 권한을 부여받고 EP 를 통해 권한별 개인화된 화면을 제공받는다. 기간계 시스템은 X-Internet 화면을 통해 서비스를 제공한다. X-Internet 과 프레임워크는 웹 컨트롤러를 통해 통신한다. 전송된 서비스 요청은 프레임워크 내의 IPPR (전문 입력 모듈)을 거쳐 업무 컴포넌트로 들어가고, 처리 종료 후 반환되는 데이터는 OPPR (전문 출력 모듈)을 통해 사용자에게 전달된다. 업무 컴포넌트는 잘 정제된 형태의 컴포넌트로 구성되어 있고 이는 쉽게 확장 및 유지보수가 가능하다. 모든 서비스는 프레임워크를 통해 제공받게 되며, BPM, RBMS, EAI, MCI 서버와 연계된다. 이 있다. 이때, MCI 서비스는 EAI 솔루션을 이용하여 처리한다.정보계를 위한 AP 서버는 별도로 존재하며 이를 통해 EIS 및 OLAP 솔루션과 연계하게 된다. 정보계 서버를 별도로 구성한 것은 기간계 트랜젝션과 명확하게 구분되면서 통계 분석 작업이 많은 정보계 시스템의 특성상 기간계 서버에 부하를 주지 않도록 하기 위함이다.



작성일자 2008/03/28



3.2 종합 배포 뷰

위의 그림은 개발된 컴포넌트 또는 프로그램이 물리적으로 어디에, 어떤 형태로 배포되는지 표현한 다이어그램이다. 참고로 서버간의 호출관계는 대표적인 것만 표기하였다. 사용자의 호출은 항상 웹서버를 통하게 되고 직접적인 EP나 AP 서버의 접근은 허용하지 않는다. 어플리케이션의 정적(Static)데이터는 웹서버에 존재하고 사용자 UI 관련 컴포넌트는 WAS 서버에 배치한다. EP 서버에는 EP 엔진과 관련 컴포넌트가 존재하며 각 단위 시스템(기간계, 정보계)에서 제공하는 포틀릿이 배치된다. 이 포틀릿을 통해 각 어플리케이션으로 연계된다. 어플리케이션의 컴포넌트들은 두대의 기간계 AP 서버와 정보계 AP 서버에 배포된다. 또한 배치 프로그램은 통합 DB 서버에 위치한다.



작성일자 2008/03/28



4. 기간계 아키텍처

4.1 개요

기간계 어플리케이션에서 사용하는 솔루션 및 호출관계를 실행관점에서 표현하면 다음과 같다.

기간계 어플리케이션의 기본구조는 X-Internet 솔루션과 J2EE 기반의 프레임워크를 활용한 업무컴포넌트를 바탕으로 이루어져 있다. 기금 사용자들은 이를 기반으로 포털 솔루션 및 SSO 가 X-Internet 과 연동하여 구축된다. 또한 본 시스템은 RBMS, BPM, 전자보증, MCI, 메일/SMS, 검색엔진, 리포트, 그룹웨어가 프레임워크와 연동하는 구조이다.

배치 프로그램은 기본적으로 온라인 프로그램과 동일한 구조이나 WAS 기반이 아닌 Standalone 으로 구현된다. 이러한 배치 프로그램은 Shell Script 에 의해 실행되는데, Batch 스케쥴러에 의해 시작되는 것이 통상적인 경우이다. End User 에 의해 실행되는 Online Batch 는 사용자의 요청을 받아 해당 배치 프로그램의 Shell Script 를 실행시킨다.



작성일자 2008/03/28



4.2 논리 뷰(Logical View)

기간계 어플리케이션의 논리뷰는 다음과 같다.

레이어간 관계의 특징은 다음과 같다. 웹 컨트롤러

Miplatform 에서 수신되는 Dataset 기반의 XML Request 를 ProFrame 의 전문 형태로 변환하여 적절한 서비스 컴포넌트로 전달한다. 그리고 반환된 처리 결과를 Miplatform 의 Response 로 Randering 하여 Client에 돌려 준다.

MCI/전자보증 컨트롤러End User 에 의해 서비스를 실행하는 것이 아니라 MCI 및 전자보증 등 별도의 채널을 통한 Request 를 받아 ProFrame 의 전문 형태로 변환하여 적절한 컴포넌트로 전달한다. 그리고 반환된 처리 결과를 다시 MCI 및 전자보증의 데이터 포맷으로 Randering 하여 전송한다.

서비스 컴포넌트



작성일자 2008/03/28



기간계 서비스의 모든 요청은 서비스 컴포넌트를 통해 전달된다. User 에 의한 Web 기반 요청은 물론, EAI/MCI 등의 Non-Web 기반 Inbound 요청도 서비스 컴포넌트를 통하도록 한다.

서비스 컴포넌트는 전문 양식에 맞추어 수신한 Request 를 분석하여 Value Object 를 적절한 User Transaction 컴포넌트로 전달하고, 처리 결과를 다시 전문 양식에 맞추어 조립하는 역할을 한다. 또한 기본적인 데이터 Validation, 보안/권한 Check 등을 수행하여 하위 레이어에 불필요한 부하를 주지 않도록 한다.

User Transaction 컴포넌트서비스 컴포넌트를 통해 들어온 Request 는 end-to-end 로 이를 처리할 Façade 역할을 하는 User Transaction 컴포넌트로 전달된다. 기본적으로 하나의 Request 는 이에 상응하는 하나의 method 에 의해 처리되어야 Transaction 을 보장할 수 있다. 하나의 Request 처리에 두 개 이상의 method 를 사용한다는 것은 그 수만큼 transaction 을 분리한다는 것을 의미한다.

User Transaction 컴포넌트는 사용자 Request 의 완수를 위해 트랜젝션 종속적인 비즈니스 로직을 처리하며, 그 과정에서 복수 개의 Domain 컴포넌트, DBIO 및 Interface 컴포넌트를 활용할 수 있다. 또한 동일한 Appliction 내라면 상이한 User Transaction 컴포넌트 간의 직접적인 호출관계도 성립할 수 있다. Application 이 다른 경우에는 Remote 호출이 필요하므로 상기한 바대로 서비스 컴포넌트를 통해 호출하도록 한다.

Domain 컴포넌트 (공통 컴포넌트)User Transaction Component 에서 직접 처리하는 비즈니스 로직을 제외한 공통 로직, 혹은 재사용 가능한 로직 등은 도메인 종속적인 (혹은 시스템 공통적인) 별도의 Domain 컴포넌트로 정의한다.

Domain 컴포넌트는 역할 수행을 위해 DBIO 및 Interface 컴포넌트를 활용할 수 있다. Domain 컴포넌트는 다른 Domain 컴포넌트와 직접적인 호출관계를 가질 수 있다. 그러나 User Tracnsaction 컴포넌트를 호출하지는 못한다.

Data Access 컴포넌트 (DAO)User Transaction 컴포넌트 혹은 Domain 컴포넌트에서 DB 처리가 필요한 경우 DBIO 를 활용하여 데이터 접근 로직을 비즈니스 로직으로부터 격리하도록 한다. Value Object 와 DB Table 간 매핑관계를 관리한다.

한 업무 패키지 내의 DBIO 는 해당 업무의 Owner 인 User Transaction 컴포넌트 혹은 Domain 컴포넌트에 의해서만 사용 가능하다. 다른 패키지의 DBIO 를 직접 호출할 수 없고 그 패키지의 User Transaction 컴포넌트 혹은 Domain 컴포넌트를 통하여 호출해야 한다.

Interface 컴포넌트User Transaction 컴포넌트 혹은 Domain 컴포넌트에서 타 솔루션 인터페이스 처리가 필요한 경우(Outbound) Interface 컴포넌트를 활용하여 Interface 로직을 비즈니스 로직으로부터 격리하도록 한다. 인터페이스에 필요한 Connection, 데이터 전환 및 전달, 로깅 등의 역할을 한다.

Value Object레이어 간, 그리고 컴포넌트 간 데이터를 주고 받을 때 사용하는 일종의 파라미터 클래스의 역할을 한다. 전문을 통해 정의된 Value Object 는 서비스 컴포넌트까지만 사용하고 그 하위 레이어부터는 전문 종속적인 내용이 없는 Map 기반의 Value Object 로 전환하여 사용한다.

ProFrame 에서 사용하는 CommonBuffer 는 서비스 컴포넌트 레이어에서만 사용하고, 하위 레이어에서는 Value Object 만을 사용하도록 한다. 이렇게 해야지만 서비스 컴포넌트를 제외한 하위 레이어가 ProFrame전문 기반이 아닌 순수 비즈니스 기반으로 유지될 수 있다.



작성일자 2008/03/28



각 컴포넌트 간 호출은 반드시 Factory 를 통해 생성하도록 한다.



작성일자 2008/03/28



4.3 주요 영역 Architecture 구성 뷰

4.3.1Presentation 레이어

통합 사용자 마스터 연계

적용 요구품질속성: RQ-STM-SA-1-04, RQ-STM-SA-1-05, RQ-STM-SA-1-09

통합 사용자 마스터 데이터는 HR 시스템에서 주기적으로 DB 에 로딩해준다. 따라서 기본적으로 본 데이터는 Read Only 로 사용한다. 여기에 별도의 사용자 관리 프로그램을 통해 HR 시스템에 없는 사용자를 추가 등록하여 통합적인 사용자 마스터를 구성하게 된다.

이러한 마스터 데이터는 기간계 뿐 아니라 전체 시스템을 구성하는 여러 단위 시스템들 간에 공유된다. 즉, 사용자에 대한 정보(직원 정보, 조직 정보 등)를 필요로 하는 정보계 시스템, EP, SSO, BPM 등이 그 대상이다. 그룹웨어는 HR 시스템과 직접 별도로 동기화를 하므로 본 마스터 데이터를 사용하지 않는다.

SSO 시스템은 본 통합 사용자 마스터 데이터를 활용하여 자체적으로 통합 사용자 계정을 관리하게 된다. 통합 계정정보는 SSO 에 위치하며, 각 시스템을 SSO 를 통해 접근할 때 이 계정 정보를 사용하게 된다. SSO 장애시에 기간계 시스템에 접근하기 위해서 (비상 로그인) 주기적으로 SSO 시스템이 가지고 있는 기간계용 계정 데이터를 백업하여 비상시에 사용한다. 기타 시스템도 이러한 비상 로그인 프로세스가 필요한 경우에 한하여 자신들의 계정 데이터를 SSO 로부터 백업받도록 한다.



작성일자 2008/03/28



EP - SSO 연계


포털 시스템과 SSO 의 연계 방식 및 처리절차는 다음과 같다.

1.사용자는 초기 로그인 시에 정해진 URL 로 접근한 후 SSO 인증을 통하여 DB 에서 사용자정보와 권한정보를 읽어 온다.

2. Portal 에서는 DB 에 접근하여 사용자 Profile 정보를 가져오고, 개인화 기능을 통해 개인 화면 및 메뉴를 보여 준다.

3.포털에서는 기간계 업무를 위한 X-Internet 전용 브라우저를 URL 호출방식으로 연다. 포탈에서 받은 SSO 토큰 정보를 뒷 단의 포틀릿 서버에 넘겨주어 SSO 처리가 되도록 한다. 즉 포털의 로그인 과정 없이 업무시스템에 접근할 경우에도 똑같이 SSO 과정을 거친다.

EP 에서 사용자 정보 연계방식은, 먼저 SSO 서버에서 통합된 사용자 Profile 을 포탈 내 User Profile 로 동기화 한다. 각 Profile 저장소에서 수정된 정보는 Automation server 를 통해 일 배치로 동기화 한다. 동기화된 사용자 프로파일을 기반으로 사용자가 요청한 페이지에서 필요한 사용자 정보를 보여준다.

사용자가 초기에 시스템에 접근할 때의 처리과정을 좀 더 자세히 표현하면 다음과 같다.



작성일자 2008/03/28



포탈서버의 WAS 에 SSO agent 를 설치, Policy Server 와 통신을 통해 로그인 사용자의 접근여부를 판단하여 처리한다. SSO agent 의 역할은 Portal WAS server 로 오는 Request 를 중간에 Intercept 하여 해당 Request 를 사용자가 SSO 제품의 로그인 여부를 credentials(Cookie 또는 Session value)의 체크를 통해 확인하고 요청 받은 Resource 에 대한 접근권한이 있는지를 Policy Server 를 통해 확인한다.

이 과정에 문제가 없다면 요청 받은 페이지로 이동을 허락하거나 문제가 있을 경우 미리 지정한 페이지로 이동한다.

EP - X-Internet 화면 연계

적용 요구품질속성: RQ-STM-SA-1-09

기본적으로 EP 에서 기간계 화면을 호출하는 방식은 URL 링크 방식을 사용한다. 사용자가 EP 에 화면을 요청할 때 기간계 특정 업무를 처리할 수 있는 URL 링크 정보가 같이 출력된다. 사용자가 해당 링크를 선택하면 Miplatform 브라우저를 실행시키는 JSP 화면을 호출하게 되는데, 이때 해당 기간계 업무의 시스템 구분, 특정 화면 ID 및 전달하고자 하는 초기 값들이 Form Parameter 형식으로 넘어간다. 이러한 값들은 Miplatfrom 브라우저의 Global Variable 의 형태로 전달되어, 브라우저가 실행되자마자 해당 시스템의 메뉴 출력과 화면 출력은 물론, 전달받은 초기 값이 출력되어 사용자가 바로 사용할 수 있는 상태가 된다.

기간계와의 SSO 연동을 위해 EP 와 사용자 간에 유지되는 SSO 토큰 정보는 Miplatform 의 브라우저에 그대로 전달이 되어야 별도의 로그인 절차 없이 SSO 연동의 대상이 된다.



작성일자 2008/03/28



X-Internet – Reporting 연계


Oz Viewer 를 통해 보고서를 출력하는 방식에는 두가지 대안이 존재한다. 첫번째는 마이플랫폼에서 입력된 파라미터 정보(보고서 출력 조건)를 Oz Viewer 에 넘겨주면 이를 Oz 리포트 서버의 자체 쿼리 실행을 통해 데이터를 fetch 해온 후 보고서 양식에 맞게 출력하는 방식이다.



작성일자 2008/03/28



대안 1. 보고서 서버를 활용한 리포트 출력



작성일자 2008/03/28



두번째 대안은 별도의 리포트 서버를 사용하지 않고 마이플랫폼에서 fectch 해온 데이터를 그대로 재활용하여 리포트를 출력하는 방식이다.

대안 2. 마이플랫폼 데이터 재활용을 통한 리포트 출력

상기한 두가지 대안은 각기 장단점을 가지고 있으므로 상황에 따라 두가지를 혼용하도록 한다.

구분 장점 단점 적용대안 1 마이플랫폼을 통해 데이터를

조회하지 않아도 보고서 츨력이 가능함별도의 보고서 서버를 활용하므로 온라인 서버에 부하를 주지 않음

마이플랫폼을 통해 조회를 이미 한 경우는 중복해서 시스템에 부하를 주게됨

병행 적용

대안 2 이미 fetch 한 데이터를 재사용하므로 보고서 출력 속도를 향상할 수 있음

Fetch 한 데이터만 보고서 출력이 가능함; 즉, 페이지네이션 등을 통해 검색 조건에 해당하는 전체가 아닌 일부 데이터만 fetch 된 경우 사용할 수 없음

병행 적용

결론: 대안 1 은 마이플랫폼을 통해 데이터를 fetch 할 일이 없을 때 사용하도록 한다 . 그 외에 Pagination 을 통해 마이플랫폼이 전체가 아닌 일정 페이지 단위의 데이터만 fetch 해 올 경우에도 대안 1 을 사용하도록 한다 .



작성일자 2008/03/28



대안 2 는 업무적인 사유로 인해 보고서 출력 전에 마이플랫폼을 통해 검색 조건의 일부가 아닌 전체 데이터를 fetch 해오는 경우 사용하도록 한다 .

Report 출력 시 데이터 가공이 필요한 경우


Oz 서버를 통해 데이터를 fetch 하는 경우, 단일 query 로 원하는 보고서를 생성할 수 있는 경우에는 보고서 내에서 직접 SQL 문을 입력하도록 한다. 그러나, 보고서의 기본 데이터 처리 기능으로는 복수 개의 query가 필요하거나 데이터 가공 시 복잡한 로직 처리가 필요한 경우에 대한 대처가 어려워진다. 이런 경우에는 다음과 같은 방식을 사용하도록 한다.

기존 방식과 동일하게 Oz Browser 를 통해 보고서에 대한 요청이 들어오면 해당 보고서 양식이 Data Intarface 에게 데이터를 요청한다. Data Interface 는 이를 특정 JSP 를 호출하는 Http Request 로 보내고, 해당 JSP 는 JDBC API 를 사용하여 Query 를 통해 데이터를 fetch 한다. 원하는 데이터를 가져오고 필요한 가공처리를 마쳤으면 이를 Renderer 를 통해 CSV 형태의 Stream 으로 변환하여 HttpResponse 에 write 한다. 이를 받은 Data Interface 는 보고서 양식에 이를 돌려주어 보고서가 생성될 수 있도록 한다.



작성일자 2008/03/28



4.3.2Process 레이어

웹컨트롤러 (Miplatform – ProFrame 간 연동)

적용 요구품질속성: RQ-STM-SA-1-01, RQ-STM-SA-1-09

브라우저의 UI 컴포넌트는 Miplatform XML 기반의 Http Request 를 서버로 전달한다. 이를 수신하는 Front Controller 는 어플리케이션 공통적으로 사용되는 하나의 Servlet 으로 구현되므로 해당 어플리케이션 내의 모든 Request 는 동일한 URI 를 가지게 된다. 실제 실행할 특정 서비스의 특정 메소드에 대한 정보는 본 Request 의 Variable 로 포함되어 ProFrame 측에 전달된다.

Front Controller 는 전달받은 Http Request 를 전문의 형태로 변환하는데, Body 에 있는 XML 데이터는 Parsing 하지 않은 상태에서 하나의 입력 전문 항목(모든 서비스가 공통으로 사용함)으로 String 화되어 IPPR 에 전달된다. IPPR 은 이를 XML 이 포함된 CommonBuffer객체로 변환하여 적절한 Service 컴포넌트에 전달한다. 해당 Service 컴포넌트는 이를 받아 Miplatform Handler 를 통해 Miplatform 관련 데이터를 추출하여 로직을 처리한다.

처리 결과는 다시 Miplatform Handler 를 통해 XML 의 형태로 구성되고, 모든 서비스가 공통적으로 사용하는 하나의 출력 전문 항목으로 String 화되어 웹 컨트롤러에 돌아온다. 결국에는 다시 Web Request Handler 에 의해 Miplatform 데이터로 변환하여 HttpResponse 에 담게된다.



작성일자 2008/03/28



Front Controller 는 이러한 Miplatform 과 Proframe 간의 연동 처리 외에 세션 처리 등 웹 레이어에서 처리해야하는 부가적인 기능을 수행한다.

웹컨트롤러 (SSO 로그인 및 사용자 세션 처리)


기금 내부 사용자는 SSO 를 통해 시스템에 로그인한다. 한번 로그인한 사용자는 원하는 시스템에 최초 접근할 때 사용자가 가지고 있는 SSO 쿠키 정보가 유효한지, 유효하다면 사용자가 해당 시스템에 접근 권한을 가지고 있는지 여부를 확인하기 위해 시스템 내부적으로 SSO 로그인을 거치게 된다. SSO로그인이 성공적으로 이루어진 경우 해당 사용자의 기본 정보를 메모리 상에 적재하여 권한 처리 등 통상적인 업무 처리 시에 수시로 참조할 수 있도록 한다. 이러한 것을 사용자 세션이라 부르며 그 처리하는 방식에는 다음과 같이 두가지 대안이 있다:

대안 1. WAS 세션에 사용자 정보를 적재

먼저 Miplaform 에서 SSO 쿠키 정보와 접근하고자 하는 시스템의 아이디가 전달되면 SSO Login 처리를 하기 위한 모듈을 실행하여 SSO 측의 Policy 서버와의 통신을 통해 SSO 쿠키 및 시스템 접근권한을 확인하도록 한다. 확인이 실패하는 경우 SSOSecurityException 을 발생하여 접근을 막도록 한다.



작성일자 2008/03/28



위의 과정은 두 대안 모두 동일하지만 로그인이 성공하는 경우부터가 차이를 나타내게 된다. 대안 1 은 User Session 처리를 담당하는 모듈을 통해 필요한 사용자 정보를 ProFrame 에서 fetch 하여 WAS Session 에 적재하게 된다. 사용자 정보가 서버 측에 로딩되게 되므로 사용자 관련 정보를 클라이언트가 가지고 있을 필요가 없고, 이후의 모든 서버 Request 를 처리할 시 WAS Session ID 만 넘겨주면 서버 Session 에서 필요한 사용자 정보를 추출하여 전문을 완성한 후 ProFrame 에 넘겨주게 된다.

대안 2. 클라이언트에 사용자 정보를 적재

반면 대안 2 는 성공적인 로그인 후 User Session 처리를 담당하는 모듈을 통해 fetch 한 사용자 정보를 WAS 세션 대신 Miplatform 에 전달하여 클라이언트 세션에 해당 정보를 적재하는 경우이다. 따라서 이후 모든 서버 Request 를 처리할 시 필요한 사용자 정보를 Request 에 실어서 서버 측에 보내도록 한다.

상기한 두가지 대안은 각기 다음과 같은 장단점을 가지고 있다:

구분 장점 단점 비고대안 1 사용자 관련 데이터가 서버에만

존재하고 네트웤을 통해 왔다갔다 하지 않으므로 보안성이 뛰어나고 네트웤에 대한 부하를 약간이지만

서버 측의 세션을 사용하므로 서버 자원을 좀 더 사용한다.서버 세션의 라이프사이클을 따라 가므로 세션 아웃일 경우 세션 재생성

적용



작성일자 2008/03/28



줄일 수 있다. 등의 추가적인 프로세스가 필요하다.대안 2 클라이언트 메모리를 사용하므로

서버 메모리 부하를 줄일 수 있다. 서버 세션을 사용하지 않으므로 세션 재생성의 프로세스가 필요 없이 간편하게 적용할 수 있다.

사용자 관련 데이터가 클라이언트에 내려오고 매 서버 Request 마다 이를 서버에 전송해야 하므로 보안이 취약하고 네트웤 부하를 발생한다.

결론: 기간계 시스템은 기금 내부 사용자 뿐 아니라 영업점 등 외부 망에 존재하는 사용자가 존재하기 때문에 세션 관리에 대한 부담 및 서버 자원의 중요성 보다 보안성이 훨씬 중요하므로 대안 1 의 아키텍처로 세션을 관리하도록 한다 .

웹컨트롤러 (Request 별 WAS 세션 및 SSO 쿠키 확인)




작성일자 2008/03/28



Miplatform 을 구동하는 JSP 페이지에서 현재 요청된 Request 내의 SSO 토큰 정보를 체크한다(1). 먼저 통합로그인을 거쳤는지, 그리고 현재 토큰이 유효한지 여부를 확인하도록 한다. 이 두가지 항목 체크에 실패하면 통합 로그인 페이지로 리디렉트한다. 정상적으로 통과하면 기간계 초기화면을 로딩하게 되는데, 이때 토큰 정보를 마이플랫폼으로 전달하도록 한다(2). 토큰정보는 마이플랫폼에서 전송하는 첫번째 Request 에 쿠키로 포함되어야 한다. 초기 Request 를 통해 사용자 정보를 세션에 저장하고, 이후부터는 SSO 의 토큰 라이프사이클을 사용하지 않고 WAS 의 세션 라이프사이클을 따르므로 추후 Request 에는 토큰정보를 쿠키에 담지 않는다.

마이플랫폼 초기 화면이 로딩되자마자 기간계 서버로 초기화를 위한 Request 를 토큰 정보와 함께 전송한다(3). 이 경우, 먼저 SSO 토큰의 유효성을 확인한 후(4), 통합 사용자 마스터 데이터를 이용하여 사용자 정보를 세션에 저장한다(6-7).

일단 초기화가 된 상태에서 다음 Request 부터는 SSO 토큰을 체크하지 않는 대신 WAS 의 세션에 사용자 정보가 있는지 여부를 확인한다(8-9). 만일 세션이 유효하지 않다면 오류 메시지를 출력하고 프로그램을 종료한다(10).

SSO 장애 시 비상 로그인


SSO 에 장애가 발생할 시에 임시적으로나마 시스템에 접근 가능할 수 있도록 하는 별도의 프로세스가 필요하다. 비상 로그인 화면에서 SSO 와 동일한 Id, Password 를 입력하면 웹 컨트롤러에 있는 Login 모듈에 의해 인증을 받아 User 세션을 생성하게 된다.



작성일자 2008/03/28



웹컨트롤러 (Exception 및 ProFrame 메시지 처리)


웹컨트롤러 내에서 발생하는 Exception 은 Unchecked Exception, 즉 Runtime Exception 에 한하도록 한다. 사용자 정의 및 비즈니스 로직에 의해 의도된 Exception 인 Checked Exception (Application Exception)은 실제 비즈니스 로직을 처리하는 ProFrame 내에서만 발생할 수 있도록 한다.

웹 컨트롤러 내부에서 발생하는 모든 Runtime Exception 은 Front Controller 에 의해 catch 되며, 공통적으로 사용하는 Exception Handler 에 의해 처리된다. 처리 방식은 서버 Message 를 담당하는 모듈에 의해 선택되며, 본 아키텍처의 경우 Miplatform Dataset 의 형태로 변환되어 클라이언트에 전달된다. 이렇게 전달된 데이터는 Miplatrform Browser 에 의해 사용자에게 출력된다.



작성일자 2008/03/28



ProFrame 내부적으로는 Runtime Exception 과 Application Exception 두가지가 모두 발생 가능하다. 발생한 Exception 은 일차적으로 Service 컴포넌트에 의해 catch 되고, ProFrame 에 의해 전문 형태로 그 내용이 변환되어 웹 컨트롤러에 전달된다. 이를 Web Request Handler 를 활용하여 Miplatform 데이터로 전환한 후 클라이언트에 전달하면 사용자가 인지할 수 있도록 랜더링하여 출력하게 된다.

Runtime Exception 은 복구할 수 없는 것으로 화면 출력시 해당 화면을 Error Page 로 덮어 더 이상의 업무 진행을 못하도록 한다. 그 외의 Application Exception 은 팝업으로 처리하도록 한다.

전자보증 컨트롤러 (Inbound)


전자보증 시스템은 HTTP 내에 XML 을 전달하는 방식으로 Request 를 서버로 전달한다. 이를 수신하는 Front Controller 는 어플리케이션 공통적으로 사용되는 하나의 Servlet 으로 구현되므로 해당 어플리케이션 내의 모든 Request 는 동일한 URI 를 가지게 된다. (http://..../exchange.do)



작성일자 2008/03/28



Front Controller 는 전달받은 Http Request 를 기간계로 전달될 전문의 형태로 변환하는데, 이때 Request 내부에는 이를 처리할 기간계의 거래번호를 포함한 필요한 데이터가 XML 의 형태로 존재한다. 이를 가지고 시스템 헤더 부분을 생성하고, 나머지는 Parsing 하지 않은 상태에서 하나의 입력 전문 항목(모든 서비스가 공통으로 사용함)으로 String 화되어 IPPR 에 전달된다. IPPR 은 이를 XML 이 포함된 CommonBuffer객체로 변환하여 적절한 Service 컴포넌트에 전달한다. 해당 Service 컴포넌트는 이를 받아 전자보증 Handler 를 통해 관련 데이터를 추출하여 로직을 처리한다.

처리 결과는 다시 전자보증 Handler 를 통해 XML 형태로 구성되고, 모든 서비스가 공통적으로 사용하는 하나의 출력 전문 항목으로 String 화되어 웹 컨트롤러에 돌아온다. 결국에는 다시 Web Request Handler 에 의해 HttpResponse 에 담게된다.

MCI 컨트롤러 (Inbound)


대외계 시스템은 HTTP 내에 XML 을 전달하는 방식으로 Request 를 서버로 전달한다. 이를 수신하는 Front Controller 는 어플리케이션 공통적으로 사용되는 하나의 Servlet 으로 구현되므로 해당 어플리케이션 내의 모든 Request 는 동일한 URI 를 가지게 된다. (http://..../channel.do)



작성일자 2008/03/28



Front Controller 는 전달받은 Http Request 를 기간계로 전달될 전문의 형태로 변환하는데, 이때 Request 내부에는 이를 처리할 기간계의 거래번호를 포함한 필요한 데이터가 XML 의 형태로 존재한다. 이를 가지고 시스템 헤더 부분을 생성하고, 나머지는 Parsing 하지 않은 상태에서 하나의 입력 전문 항목(모든 서비스가 공통으로 사용함)으로 String 화되어 IPPR 에 전달된다. IPPR 은 이를 XML 이 포함된 CommonBuffer객체로 변환하여 적절한 Service 컴포넌트에 전달한다. 해당 Service 컴포넌트는 이를 받아 MCI Handler 를 통해 관련 데이터를 추출하여 로직을 처리한다.

처리 결과는 다시 MCI Handler 를 통해 XML 형태로 구성되고, 모든 서비스가 공통적으로 사용하는 하나의 출력 전문 항목으로 String 화되어 웹 컨트롤러에 돌아온다. 결국에는 다시 Web Request Handler 에 의해 HttpResponse 에 담게된다.

EP - Proframe 간 연동

적용 요구품질속성: RQ-STM-SA-1-01, RQ-STM-SA-1-07, RQ-STM-SA-1-09, RQ-STM-SA-1-13

EP 는 기본적으로 URL 링크를 통해 마이플랫폼 브라우저를 띄운 후 마이플랫폼 브라우저에서 기간계 서버와 통신을 하게 되므로 별도의 연동이 필요없다. 그러나 일부 기간계 서비스의 경우 EP 에서 Portlet 을 통해 바로 기간계 서버에 Request 를 전송하는 경우가 있다. 이를 위해 EP 로부터 서비스를 요청받아 Response 를 돌려줄 수 있는 연동방식이 필요하다.

EP 는 HTTP 내에 XML 을 전달하는 방식으로 Request 를 서버로 전달한다. 이를 수신하는 Front Controller는 어플리케이션 공통적으로 사용되는 하나의 Servlet 으로 구현되므로 해당 어플리케이션 내의 모든 Request 는 동일한 URI 를 가지게 된다. (http://..../portal.do)

Front Controller 는 전달받은 Http Request 를 기간계로 전달될 전문의 형태로 변환하는데, 이때 Request 내부에는 이를 처리할 기간계의 거래번호를 포함한 필요한 데이터가 XML 의 형태로 존재한다. 이를 가지고 시스템 헤더 부분을 생성하고, 나머지는 Parsing 하지 않은 상태에서 하나의 입력 전문 항목(모든 서비스가 공통으로 사용함)으로 String 화되어 IPPR 에 전달된다. IPPR 은 이를 XML 이 포함된 CommonBuffer객체로 변환하여 적절한 Service 컴포넌트에 전달한다. 해당 Service 컴포넌트는 이를 받아 EP Handler 를 통해 관련 데이터를 추출하여 로직을 처리한다.

처리 결과는 다시 EP Handler 를 통해 XML 형태로 구성되고, 모든 서비스가 공통적으로 사용하는 하나의 출력 전문 항목으로 String 화되어 웹 컨트롤러에 돌아온다. 결국에는 다시 Web Request Handler 에 의해 HttpResponse 에 담게된다.



작성일자 2008/03/28



서비스 컴포넌트와 User Transaction 컴포넌트 간 데이터 전달


웹 컨트롤러에서 ProFrame 으로 넘어오는 과정은 상기한 바와 같이 명확하게 분리된다. 이렇게 전송된 전문은 ProFrame 에 의해 자동으로 Common Buffer 로 변환된다. Common Buffer 내부적으로는 화면에서 전달된 XML 이 그대로 포함되어 있으므로 이를 Parsing 하여 사용해야 한다.

ProFrame 의 Request-Response 처리를 위해 서비스 컴포넌트는 이 XML 기반의 Common Buffer 를 핸들링하는 수 밖에 없는데, 문제는 서비스 컴포넌트 이후 레이어에서 입출력되는 데이터를 어떤 형태로 사용할 것인가에 있다. 여기에는 다음 그림과 같이 세가지 대안이 존재한다:



작성일자 2008/03/28



Common Buffer 가 가지고 있는 Miplatform XML 영역과 Plain 데이터 영역을 명확하게 구분하는 것은 의미가 있다. 하위 컴포넌트(User Transaction, Domain, Dao, Interface 등)의 파라미터와 리턴 타입을 Miplatform 의 Vo 구조로 한다는 것은 해당 컴포넌트가 Miplatform XML 의 형태에 종속이 된다는 것을 의미한다. 즉, 기간계 어플리케이션 전체가 Miplatform XML 의 지배를 받는 구조가 된다.

위와 같은 사유 때문에 Miplatform XML 영역과 Plain 데이터 영역을 명확하게 구분하는 것이 아키텍처적으로 바람직하다. (대안 1 과 2) 그러나 개발 및 유지보수의 편의성을 보면 Miplatform VO 를 그대로 하위 레이어에서까지 사용하는 것이 좋아 보인다. (대안 3)

대안 1 은 별도의 Plain 한 Java Bean 을 Value Object 로 구현하여 Miplatform VO 를 Plain VO 로 전환하는 방식이다. 그에 비해 대안 2 는 별도의 VO 구현 없이 Java Map 을 활용하여 Miplatform VO 를 Map 으로 전환하는 방식이다. 대안 3 은 Miplatform VO 를 그대로 사용하는 방식이다.

각 대안의 장단점은 다음과 같다:

구분 장점 단점 비고대안 1 Common Buffer 영역과 Plain 데이터

영역을 명확하게 구분한다.Plain VO 가 직관적인 구조를 가지고 있어 이해하기 쉽다.Strong Typing 이므로 오류발생을 줄일 수 있다. Parameter/Return Type 이 명확하다.VO 와 VO 간의 관계에 대한 표현 및 정합성 체크가 용이하다.향후 Web Services 의 endpoint 로 노출하고자 할 경우 그대로 활용이 가능하다.필요시 로직을 VO 내부에 구현할 수 있다.

별도 VO 의 설계 개발 유지보수 비용이 많이 든다.런타임 시 데이터 변환에 비용이 든다. (수작업 처리시 코딩량 증가, 자동 처리시 속도 저하)

대안 2 Common Buffer 영역과 Plain 데이터 영역을 명확하게 구분한다.별도의 VO 개발 비용이 없다.런타임 시 데이터 변환을 속도 저하 없이 자동으로 처리 가능하다.

Generic 한 타입이므로 클래스 만으로는 무슨 데이터를 나타내는지 이해하지 못한다.Strong Typing 이 아니라 항상 key값을 알고 있어야 하므로 오류발생의 여지가 있다. Parameter/Return Type 이 명확하지 않다.VO 와 VO 간의 관계에 대한 표현 및 정합성 체크가 불가능하다.향후 Web Services 의 endpoint 로 노출하고자 할 경우 별도의 VO 로 전환해야 한다.

적용

대안 3 개발 및 유지보수성이 우수하다. Common Buffer 영역과 Plain 데이터 영역 구분이 불가능하다.

결론:



작성일자 2008/03/28



Common Buffer 영역과 Plain 데이터 영역을 구분하는 것이 아키텍처적으로 바람작하므로 대안 3 은 제외한다 . 대안 1 이 대안 2 보다 상대적으로 장점이 많은 것은 사실이나 , 현실적으로 VO 를 별도로 개발 및 유지보수하는 데는 많은 노력이 동반된다 . 따라서 본 아키텍처에서는 대안 2 를 사용하도록 한다 . VO 에 별도의 로직을 넣어야 할 필요가 있는 경우에는 해당 클래스를 별도 구현하여 컴포넌트 내에서 활용하도록 한다 .

서비스 컴포넌트 (User Transaction 컴포넌트 호출)




작성일자 2008/03/28



웹 컨트롤러를 통해 전송된 전문은 ProFrame 에 의해 Java 객체 형태의 CommonBuffer라는 일종의 Request 객체로 변환된다. 이 객체는 서비스 컴포넌트를 거쳐 마지막으로 ProFram 에 의해 다시 전문화되어 웹 컨트롤러에 반환된다.

User Transaction 컴포넌트로 넘어가는 파라미터와 처리 후 반환되는 리턴 타입은 전문을 객체화한 CommonBuffer 가 아닌 Input/Output Value Object 로 한다. 즉, CommonBuffer 는 입력 전문의 분석과 출력 전문의 조립을 담당하는 서비스 컴포넌트 내에서만 사용하도록 하여, 순수 비즈니스 로직 처리를 담당하는 User Trnasaction 컴포넌트로부터 전문 관련 로직을 제거하도록 한다.

서비스 컴포넌트 (Exception 및 서버 메시지 처리)


Exception 은 크게 두가지로 구분된다. 비즈니스 로직 상 필요한 시점에서 던지는 Application Exception 이 있고, 반면에 로직과는 별개로 의도하지 않게 시스템의 상태에 따라 WAS 혹은 VM 레벨에서 던져지는 Runtime Exception 이 있다.



작성일자 2008/03/28



전자의 경우는 당연히 비즈니스 로직 처리와 밀접한 관련이 있으므로 서비스 컴포넌트가 아닌 User Transaction 컴포넌트 혹은 Domain 컴포넌트에서 Application Exception 을 생성하여 던지도록 한다. 본 아키텍처에서는 ProFrame 에서 제공하는 ProFrameApplicationException 대신 ApplicationException 을 사용하도록 하여 ProFrame 종속성을 낮추도록 한다.

후자의 경우는 비즈니스 로직과 상관 없이 언제든지 발생할 수 있으므로 서비스, User Transaction, Domain, DAO 컴포넌트 등 어플리케이션 어디에서나 던져질 수 있다. 다만, 이에 대한 catch.를 서비스에서 하고, 이를 다시 ProFrameException 으로 Wrapping 해야만 ProFrame 에 의해 자동으로 전문에 반영된다.

Exception 과 상관 없이 서버 메시지를 클라이언트에 전달하고자 할 때는 서비스 컴포넌트에서 User Message 모듈을 통해 원하는 메시지를 전문 객체 (CommonBuffer)에 넣도록 한다. 그렇게 하면 이 또한 ProFrame 에 의해 자동으로 전문에 반영된다.

4.3.3Biz Logic 레이어

User Transaction 컴포넌트




작성일자 2008/03/28



서비스 컴포넌트에 의해 실행되는 User Transaction 컴포넌트는 메소드 하나가 사용자 입장에서의 end-to-end transaction 을 보장하게 된다. 즉, 실행되는 메소드의 실행 과정에 발생하는 모든 트랜젝션 자원들은 하나의 트랜젝션 Context 에 묶인다. 실행에 참여하는 트랜젝션 리소스 중 하나라도 실패하게 되면 전제가 Roll-back 하게 되고, 모두 성공해야만 비로서 Commit 된다. (Multi data source 혹은 리모트 EJB 호출의 경우 XA Driver 를 사용해야 함)

이렇게 실행되는 User Transaction 컴포넌트는 자체적으로 Use Case 에 종속적인 비즈니스 로직을 담고 있으며, 그 수행 과정에서 여러 종류의 컴포넌트를 활용하게 된다. 공통적이고 재사용 가능한 로직을 한 단위로 묶은 Domain 컴포넌트, 데이터 접근을 담당하는 DAO 컴포넌트, 그리고 타 시스템 연동을 담당하는 Integration 컴포넌트가 그것이다. User Transaction 컴포넌트는 이러한 컴포넌트들을 모두 Component Factory 를 통해 접근한다.

각 컴포넌트간의 전송 파라미터는 프레임워크에서 제공하는 VO(입출력 전문객체) 생성기를 통해 VO형태로 전송한다. 인테그레이션 계층에서 VO 는 DBIO 혹은 Proxy 에서 이해할 수 있는 형태로 변환이 되며, 이러한 변환 로직은 DAO 와 Interface 컴포넌트 내부에서 처리하도록 하여 비즈니스 로직과 격리한다.

흔하지 않은 경우지만 User Transaction 컴포넌트는 필요한 경우 동일한 Application 내의 다른 User Transaction 컴포넌트를 호출할 수 있다. 이때도 마찬가지로 Component Factory 를 통해 호출하도록 한다. 상이한 Application 간의 서비스 호출은 서비스 컴포넌트를 통한 원격 호출 방식을 사용하도록 한다.

상이한 어플리케이션 간 서비스 컴포넌트 호출




작성일자 2008/03/28



어플리케이션이 분리된 상황에서 상대편 서비스를 호출해야 하는 경우가 있다. 위의 그림과 같이 먼저 사용자 Request 를 접수하는 과정은 다른 온라인 프로그램과 동일하게 진행된다. 상대편 서비스를 원격 호출하는 것은 비즈니스 로직의 일환이므로 반드시 User Transaction 컴포넌트 내에서만 이루어져야만 해당 User Transaction 컴포넌트가 end to end 트랜젝션을 커버할 수 있게 된다.

서버스 원격 호출을 직접적으로 User Transaction 컴포넌트에서 하게 되면 서비스 호출에 대한 로직이 비즈니스 로직에 들어가게 되므로 Component Factory 를 통해 별도로 구현된 공통 컴포넌트인 Service Link Component 를 활용하도록 한다. 전문에 대한 맵 변환 및 데이터 타입 변환(CommonBuffer 로 변환)이 이 컴포넌트 내부에서 이루어 진다.

WAS 컨테이너가 분리되어 있는 경우, 혹은 동일한 컨테이너 내에라도 카테고리가 분리되어 있는 어플리케이션의 경우에는 Remote 호출 방식으로 컴포넌트를 사용하도록 한다. (데이터소스 등의 Resource 접근이 가능한 경우에는 예외로 함)

컨테이너와 카테고리 구성 방식은 배포 뷰를 참조하도록 한다.

Domain 컴포넌트




작성일자 2008/03/28



User Transaction 컴포넌트에 의해 실행되는 Domain 컴포넌트는 시스템 혹은 업무 레벨에서의 공통 로직 및 재사용 가능 로직을 담고 있는 컴포넌트이다. 따라서 유스케이스 독립적이며, 여러 유스케이스에 참여하여 담당하는 로직을 처리하는 역할을 한다.

로직을 처리하는 과정에서 여러 종류의 컴포넌트를 활용하게 된다. 데이터 접근을 담당하는 DAO 컴포넌트, 그리고 타 시스템 연동을 담당하는 Integration 컴포넌트가 그것이다. Domain 컴포넌트는 이러한 컴포넌트들을 모두 Component Factory 를 통해 접근한다.


Domain 컴포넌트는 필요한 경우 다른 Domain 컴포넌트를 호출할 수 있다. 이때도 마찬가지로 Component Factory 를 통해 호출하도록 한다. Domain 컴포넌트는 원격호출의 대상이 아니다.

4.3.4Integration 레이어

Dao 컴포넌트


Dao 컴포넌트는 User Transaction 컴포넌트 나 Domain 컴포넌트에 의해 호출되며, Value Object 와 Database간의 연동을 담당한다. 본 아키텍처에서는 ProFrame 이 제공하는 Persistence Mechanism 인 DBIO 를 활용하여 DAO 를 구현하며, 이러한 데이터 저장 로직을 비즈니스 로직으로부터 엄격하게 구분하도록 한다.

Dao 컴포넌트는 In/Out Value Object 를 받아 DB 작업을 처리한 후 필요한 경우 다시 Value Object 를 반환한다. Insert 인 경우 반환은 없고, Select 인 경우 하나 혹은 복수개의 Value Object (List/Aray)를 반환한다. update 와 delet 는 몇 개의 레코드가 영향을 받았는지를 알려주는 integer 정보를 반환한다.

Dao 의 구현은 다음과 같이 두 가지의 대안이 있다:

대안 1 은 하나의 공통 컴포넌트로 DAO 를 만든 후 이 것이 모든 Input/Output VO 와 Dbio VO 간의 데이터 매핑을 일괄적으로 처리하도록 하고 있다. 즉, 업무 별로 별도의 DAO 를 생성할 필요가 없으므로 개발 생산성을 향상할 수 있다. 이렇듯 자동 매핑이 가능한 것은 매핑 관계가 1 대 1 로 단순하며 서로의 필드 네임이 동일하다는 전제에서 Java Reflection 을 이용한다.

반면 대안 2 는 공통적인 DAO 컴포넌트를 이용하는 것이 아니라 각 Dbio 의 단위 별로 DAO 를 생성해 내는 것이다. 따라서 Input VO 와 Dbio VO 간의 매핑은 자동이 아닌 수작업을 통해 코딩이 되어야 한다. 개발하기에는 까다로우나 단순 1 대 1 매핑이 어려운 경우에 커스터마이징하기 용이하다.

상기한 두가지 대안은 각기 다음과 같은 장단점을 가지고 있다:



작성일자 2008/03/28



대안 1. 자동 매핑

대안 2. 수동 매핑구분 장점 단점 비고



작성일자 2008/03/28



대안 1 별도의 DAO 를 개발하지 않으므로 개발 및 유지보수 생산성이 향상된다.

내부적으로 Reflection 을 사용하므로 성능에 부하를 준다.Input VO 와 Dbio Vo 간에 단순 매핑 관계가 아닌 경우에는 사용이 불가능하다.

병행 적용

대안 2 코딩을 통해 직접적인 매핑을 수행하므로 성능 부하가 적다.Input VO 와 Dbio Vo 간에 단순 매핑 관계가 아닌 경우에도 코딩을 통해 사용이 가능하다.

별도의 DAO 를 일일이 개발해야 하므로 개발 및 유지보수 생산성이 저하된다.

병행 적용

결론: 본 아키텍처에서는 두가지 방식을 모두 채용하도록 한다 . 자동 매핑이 가능한 경우에는 개발 및 유지보수 생산성의 향상을 위해 대안 1 을 사용하도록 하는 것을 원칙으로 하고 , 대안 1 의 사용이 불가능한 경우에 한하여 대안 2 를 선택적으로 사용하도록 한다 .

복수 데이터의 일괄 처리


DB 에 SQL 을 실행시키는 것은 많은 자원이 소요된다. WAS 로부터 데이터소스를 얻어와서 Transaction Begin 을 선언한 후 해당 SQL 을 실행시킨다. 실행이 종료되면 데이터소스는 다시 반납을 한다. 여기에 WAS 가 관리하는 JTA(Java Transaction API)까지 관여하게 되면 일이 더욱 복잡하다.



작성일자 2008/03/28



그리드 저장 등의 이유로 대량의 데이터가 한번에 DB 에 저장이 되어야 하는 경우가 있다. 이를 건건이 SQL 을 실행시키는 것은 위에 설명한 바와 같은 과정을 반복적으로 수행하게 되므로 성능이 저하되고 부하가 증가하므로 매우 비효율적이다.

따라서 위의 그림과 같이 한번에 여러 개의 데이터를 일괄처리하는 방식을 사용하도록 한다. 먼저 User Transaction 혹은 Domain 컴포넌트 내에서 각각의 데이터의 상태별로 그룹핑을 한 후 Dao 컴포넌트에 있는 insert List, update List, delete List 를 활용한다. 본 메소드들은 다량의 데이터를 List 의 형태로 받아서 루프를 돌며 특정 SQL 을 일괄적으로 수행한다.

Interface 컴포넌트 (RBMS 연계)


Rbms 컴포넌트는 User Transaction 컴포넌트 나 Domain 컴포넌트에 의해 호출되며, Value Object 에 파라미터를 담아 원하는 룰을 RBMS 로부터 fetch 하는 역할을 담당한다. 본 아키텍처에서는 기본적으로 RBMS 의 API 를 직접 호출하지 않고 공통 Rbms 컴포넌트를 통해 접근하도록 하여 Rbms 접근 로직을 비즈니스 로직으로부터 엄격하게 구분하도록 한다.

공통적으로 사용하는 Rbms 컴포넌트는 실행하고자 하는 룰의 코드와 Vo 를 파라미터로 받는다. 전달받은 파라미터를 RBMS 가 사용하는 데이터 타입으로 자동적으로 전환하고 해당 룰을 실행한 다음, 그 결과를 다시 Vo 형태로 변환한 후 반환한다.



작성일자 2008/03/28



이렇게 공통 Rbms 컴포넌트를 사용하기 위해서는 입력되는 Vo 내 데이터의 key값과 value 의 타입이 Rule 정의 시 입력 항목과 동일해야 한다. 또한 Rule 에 의해 출력되는 항목의 명칭과 타입이 출력용 Vo 의 데이터 key값과 value 의 타입이 되는데, 이것이 사후 처리 (데이터 저장 혹은 화면 출력)에 지장이 없어야 한다. 따라서 Rule 의 설계시부터 입출력 항목의 정의에 본 사항을 고려해야 한다.

위의 제약 사항을 지킬 수가 없는 상황이라면 Rule 의 입출력 항목에 대한 Input/Output Vo 와의 매핑 로직이 필요하게 된다. 이러한 매핑로직을 User Transaction 컴포넌트나 Domain 컴포넌트가 가지는 비즈니스 로직과 격리시키기 위해 다음 그림과 같이 개별적인 Rule 컴포넌트를 구현하도록 한다.

개별적인 Rule 컴포넌트는 대상 Rule 의 단위로 만들며, Input Vo 를 받아 이를 RBMS 의 Vo 로 변환한 후 대상 Rule 을 실행시킨 후 그 결과값을 Output Vo 에 반영하여 반환한다.



작성일자 2008/03/28



Interface 컴포넌트 (전자보증 - Outbound)


본 프로젝트에서는 기간계 어플리케이션에서 전자보증 시스템을 통해 대외 기관을 호출하는 것을 기간계 시스템 입장에서의 Outbound 연계라 한다. 이러한 Outbound 연계를 위해서 본 시스템은 전자보증 연계를 위한 공통 인터페이스 컴포넌트를 사용하도록 한다. User Transaction 컴포넌트 혹은 배치의 경우 Step 클래스에서 대외계 연동 시 본 공통 컴포넌트를 호출하는데, 이때 위의 그림에서와 같이 다음과 같은 순서로 처리가 된다:

1. 업무 컴포넌트에서 전자보증 컴포넌트 호출2. log API 를 통해 전송 내역을 별도 DB 테이블에 저장한다. (전문순번 생성)3. 기간계에서 사용하는 Value Object 를 전자보증 시스템과의 통신을 위한 XML 로 자동 변환4. 기간계 연계용 서버 페이지를 통해 XML 전송5. 응답 내역을 기간계 사용 Value Object 로 자동 변환; 이때 로그 테이블에서 생성한 전문순번 반환6. 신규생성된 전문순번을 참조 키로 업무 컴포넌트에서 관련 데이터를 저장



작성일자 2008/03/28



전자보증 전송 전에 전문순번을 채번하여 사용하는 것도 가능하다.

Interface 컴포넌트 (MCI - Outbound)


본 프로젝트에서는 기간계 어플리케이션에서 대외계 시스템을 통해 대외 기관을 호출하는 것을 기간계 시스템 입장에서의 Outbound 연계라 한다. 이를 위해 연동을 위한 공통 컴포넌트를 별도로 만들어 사용한다. User Transaction 컴포넌트 혹은 배치의 경우 Step 클래스에서 대외계 연동 시 본 공통 컴포넌트를 호출하는데, 이때 위의 그림에서와 같이 다음과 같은 순서로 처리가 된다:

1. 업무 컴포넌트에서 MCI 컴포넌트 호출2. log API 를 통해 전송 내역을 별도 DB 테이블에 저장한다. (전문순번 생성)3. 기간계에서 사용하는 Value Object 를 MCI API 의 Value Object 로 자동 변환



작성일자 2008/03/28



4. MCI API 를 통해 데이터 전송5. 응답 내역을 기간계 사용 Value Object 로 자동 변환; 이때 로그 테이블에서 생성한 전문순번 반환6. 신규생성된 전문순번을 참조 키로 업무 컴포넌트에서 관련 데이터를 저장

MCI 전송 전에 전문순번을 채번하여 사용하는 것도 가능하다.

BPM 연계


BPM 을 연계는 방식은 클라이언트 연계 방식과 서버 연계 방식의 두가지가 있다. 클라이언트 연계 방식은 다음과 같다:



작성일자 2008/03/28



사용자가 포털을 통해 BPM 프로세스의 담당 Task 를 실행하면 클라이언트에 설치된 BPM Handler 가 구동되면서 JSP 에 Embed 된 해당 Task 관련 업무 화면이 로딩된다. 이때 필요한 Parqameter 정보들도 같이 전달된다. 사용자가 화면에서 작업을 처리한 후 해당 Task 를 종료하면, 종료 이벤트가 BPM Handler 에게 전달되고 BPM Handler 가 BPM 서버와 통신을 하여 Process 를 업데이트하게 된다.

상기 방식은 기간계 서버와 BPM 서버 간의 직접적인 연계를 하지 않고 클라이언트 내부적으로 연계를 하므로 서버 간의 통신에 따른 부하를 줄일 수 있다는 장점이 있으나, 클라이언트에 BPM 처리를 위한 모듈이 설치되어야 하고, 이를 통해서 업무 화면을 로딩하므로 화면 로딩 속도가 느리고 일반 화면과 BPM 업무 화면 간 UI 의 일관성이 없다는 단점을 가지고 있다.

그에 비해 서버 연계 방식은 사용자가 포털을 통해 BPM 프로세스의 Task 를 실행하면 클라이언트에 아무런 BPM 관련 모듈의 구동 없이 해당 업무 화면이 로딩된다. 여기서 사용자가 업무를 처리한 후 Task를 종료하게 되면, 기간계 서버에 해당 Request 가 전달되고 서버 측의 BPM API 를 통해 BPM 서버를 업데이트한다.

이러한 방식은 서버 측에서 BPM 과의 연계를 처리하므로 서버의 부담을 증가시키는 단점이 있으나 클라이언트에 아무런 모듈이 설치되거나 구동될 필요가 없고, UI 의 일관성을 유지할 수 있다는 점에서 장점이 있다.

이를 다시 정리하면 다음 표와 같다:

구분 장점 단점 비고클라이어트 연계

서버 부담 감소 클라이언트가 복잡해짐 (BPM Handler 설치, JSP 별도 필요, Miplatform Embed, 관련 Script 추가 등)UI 일관성 떨어짐클라이언트 로딩 속도 저하

일부 적용

서버 연계 BPM 적용으로 인한 클라이언트 상의 서버 부담 증가 (API 의 사용) 적용



작성일자 2008/03/28



차이점이 없음UI 일관성 유지

결론: 본 아키텍처에서는 상기한 장단점 중 클라이언트의 부담을 줄이고 UI 의 일관성을 유지할 수 있는 서버 연계 방식을 적용하도록 한다 . 단 , BPM 연계 업무 외에 기간계 업무를 사용하지 않는 사용자의 경우는 해당 업무 화면만을 로딩할 수 있도록 클라이언트 연계 방식을 일부 적용하도록 한다 .

서버 연계 방식의 경우 공통적으로 사용될 수 있는 인터페이스 컴포넌트를 활용하도록 한다. BPM 관련 처리는 비즈니스 로직 처리와 관련은 있으나 물리적인 트랜젝션 종료 후에 BPM 서버에 반영되어야 하는 특성이 있다. 즉, 실제적인 트랜젝션의 범위를 가지는 Service 클래스 Scope 종료 후 에 호출되어야 한다 . 그렇게 해야지만 기간계 처리가 완료된 것을 보장한 상태에서 BPM 업데이트를 할 수 있다 .

그러나 BPM 서버는 기간계와 2PC 를 지원하지 않는다. 따라서 이를 해결하기 위해 상기 그림에서와 같이 JMS(Java Message Service) 기반의 Queue 를 통해 비동기식으로 BPM 을 접근하도록 한다.



작성일자 2008/03/28



즉, BPM 업데이트를 요청하는 사용자 Transaction 에서는 비동기적으로 JMS Queue 에 이러한 요청 메시지를 전송한다. 사용자 Transaction 이 최종적으로 commit 되는 시점에서 Queue 에 있는 요청 메시지는 등록된 메시지 Listener 인 MDB(Message Driven Bean)에게 전달된다. MDB 는 새로운 Transaction 을 생성하면서 BPM 컴포넌트를 통해 실제적으로 BPM 서버에 업데이트를 시도한다. 이렇게 하므로서 반드시 기간계 처리가 완료된 것을 보장한 상태에서만 BPM 이 업데이트 된다. MDB 트랜잭션 내에서 BPM 업데이트가 실패하는 경우가 발생하면 MDB 트랜잭션은 rollback 되고 JMS Queue 는 계속해서 재시도를 하게 되므로 메시지 전달을 보장한다. (장애 시 시간이 걸리더라도 언젠가는 BPM 서버는 업데이트 된다)

Bpm 컴포넌트는 Value Object 에 파라미터를 담아 원하는 프로세스를 BPM 을 통해 실행하는 역할을 담당한다. 본 아키텍처에서는 기본적으로 BPM API 를 직접 호출하지 않고 공통 Bpm 컴포넌트를 통해 접근하도록 하여 호출 방식이 다른 식으로 변경되더라도 영향을 받지 않도록 한다.

공통적으로 사용하는 Bpm 컴포넌트는 실행하고자 하는 프로세스에 대한 정보와 Vo 를 파라미터로 받는다. 전달받은 파라미터를 BPM 이 사용하는 데이터 타입으로 자동적으로 전환하고 해당 프로세스를 실행한 다음, 그 결과를 다시 Vo 형태로 변환한 후 반환한다.

이렇게 공통 Bpm 컴포넌트를 사용하기 위해서는 입력되는 Vo 내 데이터의 key값과 value 의 타입이 Bpm의 입력 항목과 동일해야 한다. 또한 Bpm 에 의해 출력되는 항목의 명칭과 타입이 출력용 Vo 의 데이터 key값과 value 의 타입이 되는데, 이것이 사후 처리 (데이터 저장 혹은 화면 출력)에 지장이 없어야 한다.

메일/SMS 연계


메일/SMS 서버와의 연계는 해당 시스템의 DB 의 인터페이스 테이블에 발송 데이터를 저장하는 방식으로 한다. 메일/SMS 서버는 해당 테이블을 모니터링하면서 수시로 요청된 내역을 발송한다.

본 아키텍처에서는 해당 인터페이스 테이블에 발송 데이터를 저장하는 공통 컴포넌트를 사용한다. 즉, 온라인의 경우 User Trnasaction 컴포넌트에서, 배치의 경우 Step 클래스에서 각각 Mail 컴포넌트와 SMS 컴포넌트를 호출하여 발송을 요청한다.



작성일자 2008/03/28



검색엔진 연계


기간계 DB 와 파일 데이터를 검색하기 위해 별도의 검색엔진을 도입하여 사용한다. 본 검색 엔진은 자체적으로 검색 대상 데이터에 주기적으로 접근하여 색인 작업을 하며, 이를 통해 검색 결과를 제공한다.

기간계에서는 검색엔진과 두가지 방법으로 연계하는데, 기본적으로 간단하게 UI (마이플랫폼 화면) 단에서 검색페이지(JSP 화면)를 출력하는 방식을 사용한다. 단순히 검색만을 목적으로 하며, 검색 결과를 업무 화면과는 별도로 출력하고자 하는 경우에 적용한다. 이 경우 검색을 위한 request 가 기간계 서버를 불필요하게 거치지 않는다는 장점이 있다.

반면에, 검색 결과를 가지고 서버 업무 로직을 수행한 후 이를 업무 화면과 결합하여 출력해야 하는 경우가 있다. 이때는 기간계 서버에 검색 request 를 보내야 하며, 서버에서는 검색 엔진이 제공하는 API 를 사용하여 검색 서버로부터 결과를 받도록 한다.



작성일자 2008/03/28



4.3.5Batch 프로그램

ArchitectureBatch 프로그램은 Job Scheduler 에 의해 정해진 시간에 주기적 혹은 비주기적으로 구동되는데, 스케쥴러에 등록한 Job Schedule 에 따라 주기적으로 Batch 작업을 실행하거나, 즉시적 요청에 따라 수동으로 실행한다.

ProFrame 기반으로 배치 프로그램을 DB 서버에 위치시킨다. 스케쥴러에 의해 Offline 으로 실행되는 배치는 DB 서버에서 스크립트 호출로 직접 구동되고, 사용자에 의해 Online 으로 구동하는 Online 배치는 AP 서버에서 Request 를 받아 원격으로 DB 서버에 위치한 배치 프로그램을 구동한다.

Batch 프로그램은 ProFrame 기반으로 작성되나, WAS 위에서 실행되는 것이 아니라 Standalone 어플리케이션으로 동작하게 된다. 그러나 ProFrame 의 특성 상 배치 프로그램 실행 시 거래 파라미터를 참조하거나 Online 배치의 원격 호출을 위해 WAS 를 필요로 할 수 있다.

ProFrame 은 배치용 서비스를 온라인 용과는 다른 클래스를 상속 받아 구현하므로 본 아키텍처에서는 서비스 레이어 다음 레이어부터 동일한 구조가 가능하다.

Shell Script 에서 프로그램 실행




작성일자 2008/03/28



배치작업의 수행은 다음과 같이 프로프레임의 배치 아키텍처를 활용한 Batch Service 클래스를 통해 이루어진다.

Shell Script 에는 실행할 Job Code 를 등록하고 수행시 동적으로 필요한 데이터를 파라미터로 정의하도록 한다. 이렇게 하여 ProFrame 의 Batch Main 모듈을 실행하면 넘겨 받은 Job Code 에 해당하는 서비스 (실제 서비스 클래스)를 호출한다. 해당 배치 서비스에 전처리와 후처리 모듈이 등록되어 있으면 자동으로 실행된다.

Online Batch 프로그램


온라인 배치는 End User 에 의해 UI 를 통해 수작업으로 실행되는 배치를 의미한다. Miplatform 을 통해 특정 배치의 실행을 요청하면 이를 접수하는 Online 서비스가 DB 에 요청된 Batch Job 을 등록한다. 해당 DB 를 모니터링하는 Batch Demon 은 새로이 Job 요청이 등록되면 해당 요청 배치 프로그램을 Shell Script를 통해 실행한다. 이 때 해당 배치 프로그램이 실행 중인지를 사전에 반드시 확인하여 프로그램의 중복 실행을 방지하도록 한다. 배치 프로그램은 실행 과정에서 처리 결과를 배치 로그 테이블에 업데이트 한다.

온라인 배치는 비동기 방식으로 처리되므로 이를 실행시킨 사용자는 해당 배치가 종료될때까지 기다릴 필요가 없어 편리하나 처리 결과를 Response 로 받을 수 없다. 이를 해결하기 위해 온라인 배치 요청이 성공적으로 수행된 이후 작업 요청을 한 사용자에게 배치 수행 결과를 알림 기능을 통해 전달한다.



작성일자 2008/03/28



배치 Step 및 Commit Size 정의


배치 프로그램은 관련된 데이터를 처리하는데 있어서 독립적으로 트랜젝션을 완료하는 로직 단위를 순차적으로 수행하는 경우가 있다. 예를 들면, 파일을 읽어서 데이터를 만들고 이를 DB 에 저장하는 로직을 처리 완료한 후, 뒤이어 DB 에 저장된 데이터를 조회하여 그중 일부를 다른 테이블에 저장하는 식인데, 이러한 하나의 트랜젝션 적으로 자기완결적인 논리 단위(Logical Unit)를 Step 이라 한다.

즉, 하나의 배치 프로그램은 개개별로 독립적인 트랜젝션을 가지는 하나 혹은 그 이상의 Step 단위로 구성된다. 하나의 배치 프로그램을 복수 개의 Step 으로 구성하는 경우에는 후행 Step 은 반드시 선행 Step 처리가 완료되었다는 것을 확인한 즉시 실행되는 것을 보장한다. 따라서 업무 성격상 외부 Scheduler나 script 등에 의존하지 않고 반드시 선후행 관계로 실행되어야 하는 경우에는 반드시 한 프로그램 내에서 Step 을 나누어 사용하도록 한다. 이에 대한 대표적인 사례는 다음과 같다:

사례 1)

Step1: 이벤트 진행을 위해 특정 조건에 해당하는 고객을 선정, DB 에 저장



작성일자 2008/03/28



Step2: 선정된 고객 중 일부 조건 미달인 고객을 대상에서 삭제

사례 2)

Step1: 데이터 처리 완료

Step2: 데이터 처리 결과를 관리자에게 통보하기 위해 SMS 데이터 생성

사례 3)

Step1: 데이터 처리 완료

Step2: 비정상 처리된 데이터(fail list)에 대한 후처리

위의 사례에서 알 수 있듯이 주로 선행 작업으로 처리된 데이터에 대한 후처리의 개념으로 Step 을 분리하여 정의한다.

배치 거래 코드를 배치 프로그램 별로 따서 Service 클래스를 정의하고 각 Step 클래스의 Workflow 를 정의하여 실행시킨다. 배치 프로그램의 starting point 와 입력 값은 BatchContext 를 통해 전달된다.

Batch 는 Step 별로 트랜젝션 단위가 분할된다. 그러나 배치 프로그램의 특성상 한 Step 내에서 대량의 데이터를 처리할 수 있기 때문에 페이지 단위로 분할하여 commit 을 처리하는 방식을 위해 CommitSize 를 설정한다. 대상 데이터를 분할 처리하기 때문에 Step 클래스의 run() 메소드는 반복 수행되며, 수행될 때마다 자동 commit 이 된다.

Step 클래스 내에서 비즈니스 로직을 직접 처리하여 별도의 User Transaction 컴포넌트를 구현하지 않는다. 다만, 온라인 프로그램에서 작성한 User Transaction 컴포넌트를 재사용하는 경우에는 이를 호출하도록 한다. BaseBatchStep 에 정의된 abstract 메소드인 run 을 구현한다. 트랜젝션의 처리는 BaseBatchStep단위에서 TransactionMgr 을 통해 처리하므로 실제 Step 클래스에서는 트랜젝션 처리를 할 필요가 없고, 온라인 프로그램과 같이 쿼리 실행 시 DaoMgr 을 호출하면 된다.

배치 프로그램의 구조 상 Step 클래스 단에서 온라인 프로그램을 위해 구현한 User Transaction 컴포넌트, Domain 컴포넌트, Dao 컴포넌트, Interface 컴포넌트가 모두 사용 가능하다. 온라인 프로그램에서 서비스 컴포넌트로부터 비즈니스 컴포넌트를 분리한 이유 중의 하나가 바로 이러한 비즈니스 로직의 재사용에 있다.

데이터 분할 처리 단위는 Service 정의 시 설정하는 거래 파라미터에서 정의하는데, 단위의 Size 별로 Commit 이 이루어진다. 따라서 Commit 이 이루어지기 전에 오류가 발생하면 이전에 Commit했던 데이터까지가 유효하게 된다. 오류가 발생하면 해당 단위만 Skip 하고 계속 진행할지, 아니면 프로그램을 종료할지 여부는 배치 프로그램 설정에 따라 달라진다. 자세한 설명은 ‘Exception 처리’를 참조한다.



작성일자 2008/03/28



오류 발생 후 비정상 종료된 배치 프로그램을 재실행하면 이미 Commit 된 데이터 다음부터 처리되어야 한다. 배치 프레임워크에서는 정상 수행되어 Commit 이 내려진 스텝의 Point 를 저장하고 있으므로 재실행 시에도 동일한 스텝을 반복 수행하지 않고 다음 스텝으로 넘어간다. 또한 스텝 내부를 Commit Size 단위로 페이징 처리하는 경우에도 페이지 단위로 Commit 할 시 해당 Point 를 기록하므로 재실행 시 해당 지점에서 시작한다. 그러나, 이는 재실행시에 처리 대상 데이터가 최초 실행 시와 동일하다는 전제가 있어야 가능하며, 그렇지 않고 데이터가 유동적인 경우에는 Commit Point 가 valid 하지 않으므로 업무 처리 시 flag 등의 방법으로 별도로 해결해야 한다.

이와 같은 방법은 오류 발생 즉시 프로그램을 종료하는 경우에 사용 가능하며 , 밑에 설명할 Exception Skip 을 사용하는 경우는 프로그램 정상 종료로 간주되어 재실행 지점을 사용할 수 없다 .



작성일자 2008/03/28



Exception 처리


비즈니스 로직에 의한 Application Exception 은 Step 클래스에서 직접 throw 한다. 이때 BatchApplicationException 을 사용한다. 온라인 컴포넌트를 재사용하는 경우에는 해당 컴포넌트가 내부적으로 throw 하는 ApplicationException 을 그대로 활용한다. BaseBatchStep 은 이를 catch 한뒤 어떻게 처리할지를 결정하는데, 이때 해당 Step 의 Exception 처리 설정을 확인한다. (isExceptionSkip()) Exception 을 Skip 하도록 설정되어 있으면 오류 내역 로그를 남긴 후 오류가 발생한 Commit 단위를 Skip 하고 다음 단위(페이지 혹은 스텝)를 계속하여 진행한다. Skip 이 아닌 경우 Exception 은 BatchApplicationException으로 변환되어 최종적으로 배치 Service 에서 catch 하여 처리한다. 즉, Exception 발생 지점에서 해당 프로그램은 종료된다. ApplicationException 혹은 BatchApplicationException 이외의 Exception 이 발생하면 Skip 여부와 관계 없이 무조건 종료된다.



작성일자 2008/03/28



파일 처리


배치에서 파일을 읽거나 쓰기 위해 File 컴포넌트를 사용한다. 배치 Step 에서 첫번째 Run 시 File 컴포넌트를 통해 파일을 열고 read/write 를 한 후 마지막 run 에서 파일을 닫는다. 파일을 읽어서 BaseMapVo 의 형태로 돌려주고 저장할 때에는 BaseMapVo 를 받아서 파일에 저장한다. 이러한 파일 입출력을 Vo 의 형태로 정확히 수행하기 위해서는 파일의 포맷(레이아웃)을 정의해야 하는데, CSV (delimeter) 방식과 Flat (Fixed Length, 전문)방식을 둘 다 지원한다.



작성일자 2008/03/28



4.3.6보안 부분

보안은 방화벽등과 같은 하드웨어적인 보안과 소프트웨어 보안으로 구분할 수 있고, 소프트웨어 보안에서는 데이터보안과 어플리케이션 보안으로 구분한다.

SSO Authentication & Authorization


본 아키텍처에서는 기금 내부 사용자의 편의성 증대와 사용자 계정 정보의 통합 관리를 위해 통합 로그인을 구현한다. 통합 사용자 계정에 등록된 사용자는 SSO 에 로그인이 가능하다. (Authentication) 그러나 실제 특정 시스템을 사용하기 위해서는 해당 시스템에 접근할 수 있는 권한이 주어져야 한다.



작성일자 2008/03/28



사용자가 통합 로그인 화면을 통해 ID/PWD 를 입력하면 이를 확인하여 성공한 경우 SSO 쿠키를 발행한다. SSO 쿠키는 통합 대상 어플리케이션에 접근할 때 해당 어플리케이션 내 SSO Agent 에 전달되어 쿠키의 유효성 여부와 현 사용자가 해당 어플리케이션에 접근 권한이 있는지를 확인하게 되고, 쿠키가 유효하지 않는 경우는 다시 통합 로그인 화면으로 리디렉트 시킨다. 접근 권한이 없으면 권한 없음 메시지를 출력한다.

SSO 를 통해 인증을 완료하고 시스템 접근까지 통과하면, 본 아키텍처에서는 해당 시스템의 상세한 수준까지 접근 권한을 EAM(Enterprise Access Managemrnt)을 통해 관리한다. (Authorization) SSO 인증을 통과한 request 가 EAM 에 의해 보호받고 있는 특정 resource(메뉴, 서비스, 기타 리소스)를 접근하고자 하면 Application 은 해당 리소스에 대한 권한 체크를 SSO Agent 에게 요청하고 이것이 Policy 서버와 통신하여 접근 가능 여부를 확인해주는 방식이다. Policy 서버에서 반환하는 결과에 따라 적절하게 처리하는 것은 해당 Application 이 수행한다.

기금 내부 사용자는 사설인증서를 사용하여 로그인을 할 수 있다. 사용자는 사설 인증기관에서 인증서를 발급 받은 후 시스템에 초기 접근할 때 인증서를 제출하도록 한다. 제출된 인증서는 시스템 내 등록기관에서 상태 확인을 한 후 접근 허용 여부를 결정하게 된다.



작성일자 2008/03/28



본 아키텍처에서는 Id/Password 방식과 PKI (사설인증서) 로그인의 두가지 로그인 수단을 제공한다. 따라서 사용자는 로그인 수단을 선택할 수 있다. Id/Password 방식 로그인의 경우 SSO 서버를 통해 사용자 확인 후 SSO 토큰을 발행받는다. 반면 PKI 로그인의 경우는 ActiveX 로 된 인증서 제출 모듈을 통해 사용자가 가지고 있는 인증서를 제출한다. 이때 CA 서버를 통해 인증서의 유효성을 먼저 확인한 다음 SSO 서버에서 토큰을 발행받는다.PKI 로그인을 위해 SSO 서버가 가지고 있는 통합 사용자 계정 데이터를 CA 서버의 인증서 데이터와 동기화해야 한다. 그렇게 해야만 SSO 에 등록된 사용자 계정이 CA 서버에서도 인증서를 통해 확인 가능하기 때문이다.



작성일자 2008/03/28



EAM 기반 권한 처리


권한 체크를 담당하는 중추적인 역할을 하는 것이 Security 컴포넌트이다. 사용자가 SSO 를 통해 로그인을 하면 사용자 정보를 읽어와서 서버 세션에 적재하게 되는데, 이 때 Security 컴포넌트를 통해 EAM 의 Policy 서버로부터 해당 사용자의 Role 정보를 같이 조회해온다.

화면 리소스에 대한 접근 권한은 특정 페이지 별로 권한 여부를 확인하게 되는데, 현재 사용자가 특정 화면에서 사용할 수 있는 리소스에 대한 체크를 Security 컴포넌트를 통해 수행하게 된다. 화면 자체가 접근 불가하다면 해당 페이지를 닫아버리고, 화면 내 특정 리소스(버튼 포함)가 접근 불가하다면 이를 disable 시켜 사용 불가하게 만든다.

EAM 서버 장애시에도 권한 처리 기능은 동작해야 하므로 EAM 이 관리하는 권한 데이터에 접근이 가능해야 한다. 이러한 경우에도 권한 처리 방식은 기본적으로 동일하며, 다만 데이터 소스가 Policy 서버가 아니라 DBMS라는 차이가 있다.

웹 구간 데이터 암호화 처리




작성일자 2008/03/28



지점에서 공용망을 통해 기간계에 접근하는 경우 일부 보안이 필요한 데이터에 대해 암호화를 적용한다. Miplatform 클라이언트 브라우저와 기간계 AP 서버 간에 지정한 데이터에 한해 암복호화를 수행한다.

먼저 클라이언트에서 세션을 시작할 때 ActiveX 형태의 암복호화 컴포넌트를 통해 공개키 방식으로 특정 데이터를 암호화한다. 이때 해당 세션에서 사용할 암복호화 Session Key 가 생성되어 암호화된 데이터 내에 존재하게 된다. 이를 서버에 전달하여 서버 세션 시작을 요청하면 (주로 로그인 요청), 서버의 Web Request Handler 가 이를 받아서 암복호화 관련 컴포넌트를 통해 복호화한다. 이때 암복호화 Session Key를 획득하여 서버 세션에 적재하여, 이후의 동일한 서버 세션 범위 내에서 암복호화 작업 시 재사용할 수 있도록 한다.

일단 서버에 Session Key 가 성공적으로 적재되면, 이후부터의 암복호화는 대칭키 방식으로 진행된다. Miplatform 은 암복호화 컴포넌트를 통해 대칭키 방식으로 대상 데이터를 암호화하여 서버를 호출한다. 이때 어떤 데이터가 암복호화 대상인지에 대한 정보를 별도의 Dataset 으로 서버에 전달한다. 요청을 받은 Web Request Handler 는 암복호화를 담당하는 컴포넌트를 이용하여 암복호화 정보를 참조하면서 암호화된 데이터를 복호화한다. 이때 세션에 저장된 Session Key 를 사용하도록 한다.

복호화된 데이터를 가지고 로직을 처리한 후 Response 를 돌려주기 전에 다시 암복호화 대상 정보를 참조하여 필요한 데이터에 대해 대칭키 암호화를 한다. 마찬가지로 동일한 Session Key 를 사용한다. 이렇게 암호화된 데이터를 포함한 Response 가 클라이언트(Miplatform)으로 전달되면, Miplatform 은 Callback 에서 암복호화 컴포넌트를 통해 이를 복호화하여 사용자에게 보여준다.

암복호화의 경우 이와 같은 클라이언트와 서버 간에 별도의 암복호화 레이어가 추가되는 것이므로 반드시 보안이 필요한 민감한 데이터에만 적용하는 것이 바람직하다. 기간계 시스템에서는 일부 민감한 HR 데이터에 대해서 이를 적용하도록 한다.

DB 데이터 암호화 처리


주요 DB 데이터에 대해 컬럼 단위 별로 암복호화를 하도록 한다. 이를 위해 D’Amo (디아모)라는 제품을 도입 적용한다. Application 에 영향을 주지 않고 DB 에 Security Agent 를 설치하여 쉽게 적용할 수 있기 때문에 별도의 설명이 필요하지 않다.

암복호화 시에 시스템에 부하를 발생시키므로 이를 최소화하기 위해 암호화가 필수적인 데이터를 선별하여 적용하도록 한다.



작성일자 2008/03/28



4.3.7Logging

Online / Batch 공통 Log 로그는 ProFrame 의 Logger 를 사용한다. 아래 표와 같이 5 가지 레벨의 로그를 사용하여 각각의 Event 시에 로그를 남기도록 한다.

level event 내용 보관 처리 방안fatal SystemException발생시 Exception 내용,

Timestamp File 프레임워크 처리

error ApplicationException 발생시

Exception 내용, Timestamp

File 서비스 에서 throw 하면 프레임워크에서 처리 (ProFrameException)

warn 전문 처리 시 입력 데이터 중 일부 없음

File 프레임워크에서 일괄처리

info 트랜젝션 commit/rollback 내역EAI/MCI call 등 외부 서비스 호출 시

사용자, 호출 내역, Timestamp

File 프레임워크에서 처리필요 시 개발자 개별 처리

debug - 개발 시 필요에 따라 (각 Component 별 Logger 정의)- Dbio 실행 SQL- 전문 입출력 시- RBMS 실행 시- Online Batch call

개발자 정의 내용실행 SQLIO 내역Rule 실행배치 실행

File 개발자 개별 처리프레임워크에서 처리

위와 같은 로그 레벨은 다음과 같은 내역으로 거래코드 별로 별도의 File 에 저장하도록 한다.

내역 설명타임스탬프실행 클래스명로그레벨 Fatal/Error/Warn/Info/Debug/Test메시지 로그 내용

개발환경에서는 debug 레벨로 로그를 저장하고, 운영환경에서는 성능을 고려하여 info 레벨로 로그를 남기도록 한다.



작성일자 2008/03/28



Online Log

거래코드 별로 남기는 로그 이외에 온라인 트랜젝션의 부가적인 로그 내역을 별도의 Log 로 DB 에 남기도록 한다. 로그를 남기는 시점마다 File 에 해당 내역을 기록하는 로그와는 달리, 본 로그는 사용자 Request 마다 하나의 ThreadLocal 이라는 매체를 두고, 로그를 남기는 시점마다 그 내역을 ThreadLocal 에 적재만 하다가 거래 종료 시점에서 최종적으로 한번의 IO 를 통해 적재된 로그 내용을 DB 에 기록한다. 따라서 최소의 부하로 해당 트랜젝션의 상태를 알 수 있는 최대한의 데이터를 기록할 수 있게 된다.

구분 내역거래 정보 Category 명

거래 코드기능 코드거래고유번호채널구분환경구분송수신 구분송수신 일자클라이언트 IP응답코드응답 로그코드응답 제목응답 기본 내역응답 상세 내역

사용자 정보 사용자 ID사용자 명직원번호

Timestamp 웹 컨트롤러 시작 시간



작성일자 2008/03/28



서비스 시작 시간DBIO 시작 시간 (n 개 가능)DBIO 종료 시간 (n 개 가능)서비스 종료 시간웹 컨트롤러 종료 시간

위와 같은 Online 로그는 Property 파일로 활성화/비활성화 할 수 있다. 또한 활성화 시에도 거래 코드 별/사용자 별로 선별적으로 로그를 남길 수 있는데, 이는 DB 설정으로부터 캐쉬된 데이터를 참조하여 처리한다. (예: isLogEnabled(user), isLogEnabled(txCode) )

Batch Log

Batch Log 는 온라인 서비스에서 사용하는 로그를 동일하게 적용하도록 한다. 그 외에 Batch 프로그램 실행 내역을 관리하기 위해 다음의 사항을 DB 에 별도로 관리하도록 한다.

내역 설명 Event 처리방안배치 거래 코드 시작 프레임워크배치 프로그램 명 시작 프레임워크배치 스텝 스텝 시작 프레임워크배치 형태 구분 온라인/오프라인 시작 프레임워크배치 실행 요청 시각 시작(온라인 은 요청 시) 프레임워크배치 시작 시각 시작 프레임워크배치 종료 시각 종료 프레임워크배치 상태 코드 대기

처리시작처리중오류Step 별 완료

시작시작최초 Commit 시Exception 시에러없이 종료

프레임워크프레임워크개발자프레임워크프레임워크

총 처리 건수 총 건수 조회 시 개발자현재 완료된 건수 Commit 시마다 프레임워크오류 건수 Exception Skip 모드

사용시 Skip 하는 데이터 건수

Exception 발생 시마다 프레임워크

특이사항 개발자데이터 전달 정보 다음 Step 데이터 전달 필요시 개발자



작성일자 2008/03/28



4.3.8기타

전자 결재 처리 (그룹웨어 기반 연동) 적용 요구품질속성: RQ-STM-SA-1-07, RQ-STM-SA-1-13

상기한 그림에서와 같이 본 아키텍처에서는 전자 결재를 기존 그룹웨어와 연동하여 구현한다. 본 아키텍처에서 채택된 기본적인 원칙은 다음과 같다:

모든 결재 행위는 그룹웨어 내에서 수행된다. (결재선 지정 포함) 결재에 관련된 데이터(결재선, 결재 상태 등)는 그룹웨어뿐 만 아니라 기간계 내 공통

테이블에서도 관리한다. 결재 대상이 되는 업무 데이터는 해당 업무 측에서 개별적으로 관리하도록 한다.

이를 처리하기 위해서 다음과 같은 방식을 사용한다;

1. 기안자가 기간계의 업무 화면에서 품의 요청 버튼을 실행하면 기간계 서버로 전송되어 해당 업무 서비스를 호출한다. 해당 서비스는 자신의 User Transaction 컴포넌트를 통해 업무 데이터를 처리한다.

2. 업무 데이터와는 달리 결재 관련 데이터는 결재를 담당하는 공통 컴포넌트를 통해 처리된다. 이 때 품의 일련번호가 생성되며, 이는 결제 데이터와 업무 데이터를 연결하는 역할을 한다.



작성일자 2008/03/28



3. 저장된 결재 관련 데이터는 그룹웨어의 인터페이스 테이블에 Insert 되어 그룹웨어의 결재 프로세스 처리에 활용 된다.

4. 이러한 처리가 성공하면 이를 품의서의 형태로 그룹웨어에 전달하기 위해 해당 품의서가 파일로 만들어져 서버에 업로드 된다.

5. 이 상태에서 그룹웨어의 기안기를 실행시킨다.

6. 그룹웨어의 기안기가 실행되면서,

7. 앞서 작성되었던 품의서를 출력한다.

8. 기안자는 품의 내용을 확인하고 기안기에 있는 품의 상신 버튼을 실행한 후 결재선 지정을 하게된다. 이러한 품의 요청은 그룹웨어에 접수되어 결재가 진행된다.

9. 품의 상신이 완료되면,

10. 그룹웨어는 기간계 쪽으로 결재 상태 업데이트 요청을 보내게 되고,

11. 이를 접수한 기간계 공통 서비스는 해당 결재 정보를 ‘품의 완료’ 상태로 업데이트한다.

12. 또한 결재 상태에 따른 업무데이터를 업데이트하기 위해 해당 품의를 처리한 User Trnasaction 컴포넌트의 공통 인터페이스(Approvable)를 호출한다.

상기 과정을 거치면 그룹웨어를 통해 다음 결재자에게 결재 사항이 전달되고, 결재자가 화면을 열면 해당 품의서가 출력된다. 그룹웨어 안에서 결재 처리를 하면 품의 상신 때와 동일하게 기간계의 공통 서비스를 호출하여 결재 상태 정보를 업데이트하게 된다. (9-11 반복)

이러한 일련의 전자결재 과정은 품의 상신 시에 생성되는 품의 일련번호를 키로 이루어진다. 결재 중인 업무 데이터를 조회하기 위해 각 업무 모듈은 품의 번호와 업무 키간의 매핑 정보를 보관해야 한다. 또한 결재 후처리를 위해 품의 번호 별로 담당하는 업무 User Transaction 컴포넌트의 ID 를 보관해야만 공통 서비스에서 적절한 업무 컴포넌트를 호출할 수 있다. 이 정보를 저장하고 조회하는 과정은 공통으로 일괄 처리한다.

데이터 설명

품의 번호 품의 처리를 위한 고유 번호이다. 품의 시작부터 결재 종료까지의 모든 결재 프로세스가 이 번호를 키로 동작한다.

업무 키 품의 내역 조회를 위한 해당 업무 고유 키이다.

업무 User Transaction 컴포넌트 ID 공통 서비스가 주어진 품의 번호를 가지고 해당 업무 컴포넌트를 호출하기 위한 정보이다. 클래스 명이면 적절하다.

기간계 화면에서 그룹웨어 기안기로 연결되는 것은 Client 내에서 그룹웨어 서버로 http request 를 호출하면서 관련 데이터를 파라미터 형태로 넘겨주는 방식이므로 별다른 아키텍처적인 고려사항이 없다. 반대로, 그룹웨어 화면에서 처리한 내용이 기간계로 연계되는 것은 아래 그림과 같은 서버 to 서버의 처리가 필요하다.



작성일자 2008/03/28



사용자가 Groupware 에서 품의를 처리하고나면 기간계에 결재 처리 내역 업데이트 요청이 전달된다. 본 요청은 Servlet 을 통해 Groupware 로부터의 요청을 공통 처리하는 서비스로 전달되고, Approve 를 담당하는 컴포넌트를 통해 공통 테이블에 있는 결재 데이터를 업데이트한다. 이어 해당 품의의 처리를 담당하는 User Transaction 컴포넌트를 찾아 공통 인터페이스인 Approvable 의 메소드를 호출하여, 해당 업무 데이터의 후처리(업무 개별적으로 로직 정의)를 실행하게 된다.



작성일자 2008/03/28



전자 결재 처리 (BPM 기반 연동)


전자 결재 처리의 두번째 방식은 BPM 과의 연계를 통한 구현이다. 본 아키텍처에서 채택된 기본적인 원칙은 다음과 같다:

모든 결재 행위는 기간계 내에서 수행된다. (결재선 지정 포함) 결재에 관련된 데이터(결재선, 결재 상태 등)는 기간계 내 공통 테이블에서 관리하며, BPM

과의 연계를 위해 결재 이벤트 발생시마다 BPM 서버에 이를 전달하도록 한다. 결재 대상이 되는 업무 데이터는 해당 업무 측에서 개별적으로 관리하도록 한다.

이를 처리하기 위해서 다음과 같은 방식을 사용한다;

1. 기안자가 기간계의 업무 화면에서 품의 상신 버튼을 실행하면 그룹웨어의 결재선 지정 화면이 팝업으로 뜬다.

2. 결재선 지정이 완료되면 품의 내역이 기간계 서버로 전송되어 해당 업무 서비스를 호출한다. 해당 서비스는 자신의 User Transaction 컴포넌트를 통해 업무 데이터를 처리한다.



작성일자 2008/03/28



3. 업무 데이터와는 달리 결재 관련 데이터는 결재를 담당하는 공통 컴포넌트를 통해 처리된다. 이 때 품의 일련번호가 생성되며, 이는 결제 데이터와 업무 데이터를 연결하는 역할을 한다.

4. 이러한 처리가 성공하면 품의 상신이 되어 결재 프로세스가 시작된 것을 ProcessMgr 을 통해 BPM 에 전달한다.

5. BPM 에 접수된 품의 내역은 To Do List 를 통해 다음 승인자에게 전달이 되고, To Do 항목을 선택하면 결재 공통 화면이 뜨면서 해당 품의 내역이 출력된다.

6. 다음 승인자가 승인, 반려, 혹은 취소를 실행하면 이의 처리를 위해 기간계 내의 공통 서비스를 호출한다.

7. 공통 서비스는 ApproveMgr 을 통해 결재 공통 데이터를 업데이트하고,

8. 또한 결재 상태에 따른 업무데이터를 업데이트하기 위해 해당 품의를 처리한 User Trnasaction 컴포넌트의 공통 인터페이스(Approvable)를 호출한다.

9. 결재 업데이트가 완료되면 ProcessMgr 을 통해 다시 BPM 에게 프로세스 업데이트를 요청한다.

이러한 일련의 전자결재 과정은 품의 상신 시에 생성되는 품의 일련번호를 키로 이루어진다. 결재 중인 업무 데이터를 조회하기 위해 각 업무 모듈은 품의 번호와 업무 키간의 매핑 정보를 보관해야 한다. 또한 결재 후처리를 위해 품의 번호 별로 담당하는 업무 User Transaction 컴포넌트의 ID 를 보관해야만 공통 서비스에서 적절한 업무 컴포넌트를 호출할 수 있다. 이 정보를 저장하고 조회하는 과정은 공통으로 일괄 처리한다.

데이터 설명

품의 번호 품의 처리를 위한 고유 번호이다. 품의 시작부터 결재 종료까지의 모든 결재 프로세스가 이 번호를 키로 동작한다.

업무 키 품의 내역 조회를 위한 해당 업무 고유 키이다.

업무 User Transaction 컴포넌트 ID 공통 서비스가 주어진 품의 번호를 가지고 해당 업무 컴포넌트를 호출하기 위한 정보이다. 클래스 명이면 적절하다.

동시성 (Concurrency) 관리


동시성이란 한 트랙젝션의 결과를 다른 트랜젝션에서 확인하지 않은 채 다시 변경해버리는 상황을 방지하는 것을 말한다. 예를 들면, 사용자 U1 이 특정 데이터 R1 을 조회한 이후 에 사용자 U2 가 동일한 데이터 R1 을 조회한 후 내용을 R2 로 변경하여 트랜젝션을 commit 한 경우이다. 이 상황에서 U1 이 R1 을 재조회하지 않고 내용을 R3 로 수정하여 저장하는 트랜젝션을 일으키면 U2 가 변경한 R2 이 R3 로 Overwrite 되어 버린다. 즉, U1 은 R1 이 이미 R2 로 변경된지 모른채 R3 로 저장을 하게 된다는 것이다. 이는 데이터의 정합성을 해치게 되는 결과를 나을 수 있다. 따라서 이런 상황에서 U1 이 R1 을 R3 로 변경 저장하는 트랜젝션을 시도할 때 시스템은 해당 트랜젝션을 거부하고 동시성을 위배했음을 U1 에게 알리고 해당 데이터를 재조회하게 해야 한다.



작성일자 2008/03/28



이러한 동시성 보장을 위해 DBMS 에서 제공하는 Select For Update 기능을 이용하는 방법이 있다. U1 이 조회할 때 본 기능을 사용하면 R1 에 Lock 이 걸리면서 U1 이 업데이트를 하기 전까지 U2 는 조회는 가능하나 업데이트는 불가능하다. 즉, 먼저 이 기능을 사용하여 조회를 한 사용자가 업데이트의 기회를 선점하는 방식이다. 그러나 이러한 방식은 몇가지 문제를 가지고 있는데, 가장 중요한 문제는 물리적인 Lock 을 사용한다는 것이다. Select For Update 를 한 U1 이 Update 를 수행하여 제때에 Lock 을 풀어준다는 보장이 없으므로 시스템의 안정적인 운영이 침해될 수 있다. 또한 사용자가 조회 후 실제 저장을 할 지 말지 알 수 없는 경우가 대부분인데 이때마다 Select For Update 쿼리를 사용해야 한다는 것 또한 부담스럽다.

따라서 본 시스템에서는 소프트웨어적인 방법으로 이를 제어하도록 한다. U1 이 R1 을 조회할 때 R1 의 last update timestamp 인 T1 을 함께 읽어온다. 이는 U2 가 R1 을 조회할 때도 마찬가지이다. U2 가 R1 을 R2로 변경하여 저장을 시도할 때 T1 과 DBMS 에 현재 존재하는 R1 의 timestamp 가 일치하는지를 확인한다. U2 가 R1 을 조회한 후 아무도 R1 을 변경하지 않았기 때문에 두 timestamp 는 당연히 일치하므로 저장이 성공하고 따라서 R2 의 timestamp 는 현재 시각 T2 로 업데이트된다. 반면 U1 은 여전히 T1 을 가지고 있다. 마찬가지 과정을 거쳐 변경을 위한 트랜젝션을 시도하면 T1 과 T2 는 서로 다르므로 트랜젝션을 거부할 수 있게 할 수 있다.

이와 같은 방식은 누가 먼저 데이터를 조회했던 먼저 업데이트를 성공시킨 사용자에게 우선권을 주는 방식이다. 물리적인 Lock 을 사용하지 않으므로 Select For Update 와 관련한 우려 사항들을 회피할 수 있고, 구현 상에 부담이 없다.

페이지네이션 처리



작성일자 2008/03/28




대량의 데이터를 fetch 하는 경우에 한꺼번에 조회를 하면 서버 메모리 및 네크워크의 부하를 유발하여 성능 저하는 물론 심지어는 장애를 일으키는 원인이 되기도 한다. 이러한 상황을 방지하기 위해 해당 데이터를 일정 크기의 페이지 단위로 분할하여 한 페이지씩 처리하는 방식을 사용하도록 한다.

DBMS 에 오라클 Row Num 쿼리 방식을 적용하는데, 이에 필요한 파라미터인 시작 Row Num 과 Page Size 및 페이징 컨트롤을 위한 부가 정보인 hasMore(다음 페이지가 더 있는지)와 totalCount(전체 레코드 수) 등의 정보를 페이지네이션 처리가 필요한 트랜젝션마다 Client 로부터 넘겨 받아야 한다. Miplatform 에서 pagination 처리가 필요한 데이터셋 별로 Contant 로 상기한 4 가지의 정보를 정의하면 여러 데이터셋에 정의된 본 정보를 자동적으로 Page 정보를 담당하는 별도의 데이터셋으로 합쳐서 서버에 전송한다.

서버에 페이지 관련 정보가 들어가게 되고, 각 데이터셋의 상응하는 PageMapVo 에 그 정보를 셋팅하게 된다. 이를 넘겨받은 User Transaction 컴포넌트나 Domain 컴포넌트는 Dao 컴포넌트에 다시 넘겨주고, 여기서 필요한 정보를 얻어 DB 를 처리한다. 데이터가 fetch 되면 다시 결과 값을 돌려주는 PagedVoList 를 생성하고 OuputVo 와 함께 다음 페이지에 대한 Row Num 값과 hasMore 값을 업데이트하여 클라이언트에 돌려준다.

업무적인 필요성에 의한 전체 조회를 제외하고는 반드시 페이지 분할 조회를 적용하되, 조회 Page Size 는 200 건을 넘지 않도록 한다.

파일 업로드 및 공유



작성일자 2008/03/28




파일 업로드에는 위의 그림에서 보는 바와 같이 두가지의 대안이 있다. 첫번째 대안은 Miplatform 에서 하나의 사용자 Request 를 통해 AP 서버에 업무 데이터와 함께 파일을 데이터셋에 담아 전송하는 것이다. 이를 받은 AP 서버는 실제 물리적인 파일은 FTP 혹은 NFS 드라이브에 저장을 하고, 업무 데이터와 File 정보를 DB 에 저장한다. 업로드된 파일 조회 및 삭제도 같은 방식으로 이루어지도록 한다.

이에 비해 두번째 대안은 Miplatform 에서 파일 처리와 업무 데이터 처리를 분리하는 것이다. 파일은 파일 대로 FTP 혹은 HTTP 프로토콜로 서버에 저장하고, 업무 데이터와 함께 파일 정보는 별도의 트랜젝션으로 AP 서버를 통해 DB 에 저장한다.

각 대안에 대한 장단점을 비교해 보면 아래와 같다:

구분 장점 단점 비고대안 1 업무 데이터와 파일 처리 간의

트랜젝션 보장 (파일 저장/삭제 시)보안 우수 (FTP 서버 및 물리적인 파일 정보가 클라이언트에 노출 안됨)

대용량 파일의 경우 클라이언트/서버 메모리 부하 및 네트워크 부하 발생 가능성 (multipart 가 아님)

대안 2 메모리 부하 가능성 없음http multipart 를 이용할 경우 네트워크 부하 감소

트랜젝션 보장 안됨 보안 취약 (FTP 방식의 경우)

적용



작성일자 2008/03/28



결론: 본 아키텍처에서는 대안 2 를 채용하도록 한다 . 대안 1 의 경우 물리적인 파일을 기간계 서버에 직접 전달함으로써 대용량 파일이 특정 시간에 집중되는 경우 기간계 서버에 직접적인 피해를 줄 수 있다 . 따라서 부하 분산을 위해 파일 전송은 별도의 서버에 직접 하도록 하고 기간계 서버에는 업무 데이터 및 업로드 파일 정보만을 전달하는 방식이 적합하다 . 트랜젝션 문제는 클라이언트에서 공통모듈을 통해 파일 처리와 데이터 처리 순서를 조절하는 보조적인 방법을 적용하여 해결한다 .

대안 2 를 채택하되 FTP 보다는 HTTP 프로토콜로 처리하도록 한다. FTP 는 HTTP 에 비해 보안성이 취약하고 multipart 를 처리하지 못하므로 네트워크 부하가 증가한다. 따라서 좀 더 구체적으로 본 아키텍처에서 적용할 파일 업로드 구성을 살펴보면 아래 그림과 같다:

HTTP 로 파일 업로드/삭제/다운로드를 하기 위해 File 서버 측에 파일 처리용 Servlet 을 위치시킨다. 해당 파일은 NFS 로 연결된 공유 디렉토리에 저장하여 서버 노드 간에 공유가 가능하도록 한다. 대용량 파일을 업로드하기 위해서는 네크워크 bandwidth 가 커야 한다. 현재의 기술보증기금 전용망으로서는 (256K 회선) 대용량 파일을 업로드하기에는 부족하기 때문에 공용 인터넷망을 사용하도록 한다. 따라서 상기 그림에서 실제 물리적인 파일 데이터를 업로드하는 Servlet 앞에 공용 인터넷망에서 접근 가능한 Web Server 를 두도록 한다.

기간계 서버 쪽에는 업무 데이터와 파일 데이터를 처리하는데, 업무 데이터는 특정 업무를 처리하는 User Transaction 컴포넌트를 구현하도록 하고, 파일 데이터는 File Upload 를 담당하는 공통 컴포넌트를 통해 DB 에 파일 정보를 처리하도록 한다. 업무 데이터와 파일 데이터는 하나의 트랜젝션 내에서 실행되므로 트랜젝션이 보장된다. 파일 업로드 시 이미 파일은 업로드된 상태에서 기간계 서버 내에서 rollback 이 발생하는 경우를 대비하여 File Upload 컴포넌트는 해당 파일을 파일 서버에서 삭제하도록 한다.

이러한 방안은 rollback 시를 대비하여 파일 서버와 기간계 서버간의 동기화를 유지하기 위한 별도의 노력이 필요한데, 클라이언트에서는 각 상황에 맞게 순차적으로 파일 처리와 데이터 처리를 다음과 같이 하도록 한다:



작성일자 2008/03/28



상황 절차 비고

파일 업로드 1.파일 업로드 요청(File)

2.파일 업로드 성공 확인

3.데이터 저장 요청(AP)

4.데이터 저장 시 오류 발생이면, 업로드된 파일 삭제(AP)

데이터 처리를 먼저하게 되면, rollback 시 이미 commit 된 데이터를 삭제해야 하는 경우 발생; 복잡해짐

파일 조회 1.데이터 조회 요청 (AP)

2.조회 성공 확인

3.해당 파일 위치에 있는 파일 조회 요청 (File)

파일 삭제 1.파일 데이터 삭제 요청 (AP)

2.데이터 삭제 요청 성공 확인

3.파일 삭제 요청 (File)

파일 삭제를 먼저 하게 되면, rollback 시 이미 삭제한 파일을 복구해야 하는 경우가 발생함

데이터 캐쉬 및 동기화


빈번하게 사용하는 데이터를 필요할 때마다 DB 에서 조회해 오는 것은 많은 서버 부하 및 성능 저하를 야기한다. 이를 방지하기 위해 서버 측에서의 캐쉬를 사용하도록 한다. 이를 사용하는 Application 이 복수 개의 Container 에서 동작하므로 이러한 서버 캐쉬는 모든 Container 에서 접근이 가능해야 한다. 이를 위해 Shared Memory 에 필요한 데이터를 로딩할 수 있는 Proframe 의 기능을 활용하도록 한다.

WAS 는 Web Container 가 구동되는 시점에서 PFM Servlet 을 초기화 시켜준다. 이 시점에서 Cached Data를 초기화해주는 컴포넌트를 실행하게 된다. 본 컴포넌트는 먼저 Shared Memory 의 상태가 비어있음을 확인하고(중복 로딩 방지), 설정 파일에 등록된 일련의 DBIO 들을 실행하여 필요한 데이터를 DB 로부터 fetch 하여 Shared Memory 에 적재한다. 이 과정에서 오류가 발생하면 Exception 을 발생시킨다. 성공적으로 적재가 된 데이터들은 Container 의 경계 없이 각 Application 에서 필요할 때마다 조회하도록 한다.

데이터 Cache 는 서버 메모리를 소요하게 되므로 너무 많은 량을 사용하면 오히려 악효과가 날 수 있다. 따라서 그 대상을 제한해야 하는데, 그 조건은 다음과 같다:

- 데이터 자체의 안정성이 높아 자주 변경되지 않는다.

- 빈번하게 조회된다.



작성일자 2008/03/28



이러한 조건을 기준으로 보았을 때, 본 아키텍처에서는 공통코드, 메뉴, 영업일 데이터를 Cache 하도록 한다.

자주 발생하지는 않지만 이렇게 Cache 된 데이터가 관리자에 의해 변경되는 경우, 해당 관리 프로그램은 DB 에 데이터를 저장하는 기능 이외에 캐쉬 데이터를 동기화 시켜주는 기능을 제공한다. 동기화 요청을 받는 Servlet 은 Cached Data 를 초기화시켜주는 모듈을 활용하여 동기화 대상 데이터를 Refresh 한다.

공통코드 처리




작성일자 2008/03/28



공통코드는 런타임 시 클라이언트 자원 혹은 서버 자원에 위치시킬 수 있다. 클라이언트에 적재하는 것은 서버와 네트워크에 부하를 주지 않고 독립적으로 코드 처리를 할 수 있어 바람직해 보이지만, 반면 코드 수에 비례하여 클라이언트 자원에 부담을 주게되어 클라이언트 수행 속도가 저하될 수 있으며, 초기 로딩 시 서버와 네트워크에 부담을 많이 주게 된다. 또한 일단 클라이언트에 로딩된 코드는 해당 클라이언트 세션 Scope 을 가지므로 변경에 따른 시기적절한 업데이트가 복잡해진다.

클라이언트를 사용하지 않고 서버에만 의존하는 방식은 이와 반대로 초기 로딩에 대한 부담이 없고 클라이언트 자원 사용을 최소화하며, 무엇보다도 서버 측 데이터의 Refresh 만으로 변경사항을 반영할 수 있어 긍정적이다. 그러나, 이또한 공통코드가 필요한 매 순간마다 서버로의 Round Trip 이 발생하는 단점을 가지고 있다.

이러한 두가지 방식 중 본 아키텍처에서는 클라이언트의 부담을 덜기 위해 필요한 시점에서 서버로부터 공통코드를 받아오는 방식을 사용하도록 한다. 클라이언트가 코드 데이터를 필요로 하는 시점에 서버의 Cache 로부터 해당 코드 데이터를 가져와 사용한다. 한번 클라이언트로 내려온 공통 코드는 클라이언트에 적재되어 다른 페이지에서 재사용된다.

동일한 분류 내의 공통코드 중에서도 사용자의 권한에 따라 사용 가능하지 않은 코드가 있을 수 있다. 이를 처리하기 위해 Security 컴포넌트를 활용하여 코드 별로 사용 가능 여부를 처리하도록 한다.

메뉴 처리


사용자 로그인이 성공적으로 이루어지면 클라이언트에 접근가능한 메뉴 정보를 적재한다. 이를 위해 서버에서는 Menu 컴포넌트를 통해 Cache 된 메뉴 데이터를 제공한다.

사용자의 권한에 따라 접근 가능한 메뉴를 반환하기 위해 Menu 컴포넌트는 내부적으로 Security 컴포넌트를 활용한다. Security 컴포넌트는 EAM 기반의 권한 데이터를 적재하고 있으며, 따라서 현재 사용자의 권한으로 접근 가능한 메뉴의 목록을 필터링 할 수 있다.

UI 사용 편의



작성일자 2008/03/28




사용자의 사용 편의성 제고를 위해 화면의 구성을 적절히 해야하고, 메뉴 구성 또한 복잡하지 않게 하도록 한다. 이를 위해 디자인 시안과 표준, 그리고 템플릿을 사전에 정의하도록 하고, 이에 따라 각 화면의 구성 및 배치를 한다. 또한 사용자 입력의 편의를 위해 Text Box 의 입력 언어를 한글로 설정한다.

구체적인 사항은 디자인 표준 문서(KIBO_AA_디자인가이드_v.1.1.ppt)를 참고하도록 한다.

사용자 환경 설치 프로그램


ActiveX 등 사용자 환경에 직접 프로그램을 설치하는 방식은 설치 및 유지보수가 어렵다. 사용자 PC 별로 설정 환경이 다를 수 있기 때문에 중앙집중적인 통제가 거의 불가능하다. 따라서 PC 별로 설치 과정에 문제를 일으킬 수도 있고, 설치가 제대로 되었다 하더라도 추후 환경 변화로 인해 작동 상에 문제를 일으킬 가능성이 있다.

이러한 문제 때문에 가능하면 사용자 환경에 직접 설치되어 작동하는 프로그램은 최소화하는 것이 기본적인 원칙이지만, X-Internet 같이 보다 강력한 UI 처리를 위해서는 불가피하게 사용해야 하는 경우가 있다. 본 시스템에서는 다음과 같이 반드시 필요한 Client 모듈만을 사용하도록 한다:

프로그램 설명Miplatform Browser X-Internet 인 Miplatform 이 본 시스템의 기본 UI 를 담당하기 때문에 반드시

사용해야 한다. 관련 요구품질속성: RQ-STM-SA-1-09

Oz Viewer 보고서 형태로 데이터를 조회, 출력을 하기 위한 도구로서 Oz Report 를 적용하기 때문에 반드시 사용해야 한다. 관련 요구품질 속성: RQ-STM-SA-1-18

Issac Web/PKI Client 인증서 기반 로그인 및 웹 구간 암복호화를 하기 위한 도구로서 Issac 제품을 적용하기 때문에 반드시 사용해야 한다. 관련 요구품질 속성: RQ-STM-SA-1-20

Webro 전자 결재를 위한 아래아 한글 웹 편집기이다. 관련 요구품질 속성: RQ-STM-SA-1-09



작성일자 2008/03/28



4.4 구현 뷰(Implementation View)

상기 그림과 같이 기간계 시스템은 Web Server 와 WAS 위에서 구동하게 된다. Web Server 상에는 WAS 서비스가 필요없는 정적인 구현 요소들이 탑재된다. SSO 와 EP 에서 사용하는 HTML 화면 및 JavaScript library 를 배치하며, 그 밖에 X-Internet 화면 등이 올라간다.

WAS 서버는 각기 Web Container 와 EJB Container 로 구성되며, SSO 서버, EP 서버, Reporting 서버가 Web Container 가 설치된다. ProFrame 기반의 Application 은 EJB Container 상에 설치되어 동작한다.

여기서 구현 시 표준화된 패키지 구성이 필요한 부분을 발췌하여 다음과 같이 정의한다.



작성일자 2008/03/28



4.4.1Application 패키지 구성

서버 모듈의 논리 패키지 설계는 위의 그림처럼 다음 사항을 원칙으로 한다:

1. 전체 시스템 공통 Prefix 는 org.kibo 로 한다.2. 전체 시스템에서 공통적으로 사용하는 시스템 공통 패키지를 프레임워크 레벨 바로 위에

위치시키어 모든 어플리케이션에서 접근 가능하도록 한다. (org.kibo.stm.fw, org.kibo.stm.rl 등). 여기에는 공통 컴포넌트와 Base Class 및 각종 Utility 를 위치시킨다. 본 패키지는 ProFrame 및 각종 3rd Party 라이브러리들을 사용한다.

3. 시스템 공통 레이어 위에는 전체 시스템에서 공유하는 업무 공통 패키지가 위치한다. (org.kibo.stm.cm) 고객조회, 공통코드 검색 등의 공통 팝업 성 기능을 처리하는 모듈은 해당 공통 업무 명 내에 service, usertx, io, dao 등으로 패키지를 분할한다. 그외 domain 컴포넌트는 종류 별로 별도의 패키지에 인터페이스와 구현을 나누어 위치시킨다. 시스템 공통 레이어 등 하위 레이어를 사용한다.



작성일자 2008/03/28



4. 특정 Application 에서 공통적으로 사용할 수 있는 업무 공통 레이어를 업무 공통 레이어 위에 위치시킨다(org.kibo.<app 명>.cmn). 본 패키지 내부 구조는 상기한 전체 업무 공통 패키지와 동일하다. 시스템 공통 및 전체 업무 공통 레이어 등 하위 레이어를 사용한다.

5. 업무 공통 레이어 위에 특정 업무 트랜젝션을 처리하는 패키지를 위치시킨다. 업무 분류를 2 Depth로 구분하고 내부에 Service 컴포넌트, User Transaction 컴포넌트, 관련 DAO 및 VO 를 위치시킨다. 업무 패키지 내 모든 요소들은 시스템 공통 및 업무 공통 레이어의 패키지들을 사용한다. 그 외 같은 어플리케이션 내 타 업무 패키지의 구성 요소들과 직접적인 관계를 가질 수 도 있으나, 이는 타 업무 패키지와의 종속성을 유발하므로 그다지 바람직 하지 않다. 필요한 부분을 하위 레이어 (시스템 공통 혹은 업무 공통) 패키지로 내리는 것을 반드시 고려하도록 한다.

4.4.2X-Internet/Reporting UI 패키지 구성

UI 패키지는 위의 그림처럼 아래와 같은 사항을 원칙으로 구분한다:

1. 하나의 doc root 하에 어플리케이션 단위로 디렉토리를 구분하도록 한다.



작성일자 2008/03/28



2. 각 어플리케이션은 여러 개의 서브시스템(어플리케이션 그룹) 단위로 구성된다. 마이플랫폼은 어플리케이션 그룹 이상으로 분리할 수 없다.

3. 각 어플리케이션 별로 공통적인 기능을 하는 페이지 및 스크립트를 해당 어플리케이션 밑 common 및 script 디렉토리에 각각 위치한다.

4. 전체 업무에 공통적으로 사용하는 화면(공통 팝업 등)은 stm/cm 밑에 위치한다.5. 전체 어플리케이션에 적용되는 공통 페이지 및 스크립트를 doc root 밑 common 및 script 디렉토리에

위치시킨다.6. 전체 어플리케이션에서 사용하는 이미지는 리소스 번들의 형태로 관리하며, 이를 doc root 밑 image 디렉토리에 위치한다.

4.4.3Reporting 서버 패키지 구성

WAS 상에 배치되는 Reporintg 관련 데이터 접근용 구성 요소는 Web Server 에 위치하는 Reporting Form 에 일대 일로 대응된다. 따라서 Web Server 상의 구성과 동일하게 배치한다.



작성일자 2008/03/28



4.5 배포 뷰(Deployment View)

4.5.1Application Packaging

클래스 로더



작성일자 2008/03/28



J2EE 아키텍처 상의 클래스 로더 구조는 상단의 그림과 같이 계층 구조를 가진다. 최상단에 JVM 의 클래스로더를 상속 받아 각 WAS 인스턴스 별로 각각의 클래스로더를 가진다. 개별 WAS 클래스로더는 각 배포 단위(Deployment Unit; Packaging 된 Application)별로 하나의 EJB 클래스로더로 상속되고, 이는 또 여러 개의 Web 클래스로더로 상속되는 구조이다. 즉, 자식이 되는 클래스로더는 부모의 클래스로더에 자유롭게 접근하되, 부모가 자식의 클래스로더에 접근하거나 자식간의 클래스로더 접근은 허용되지 않는다.

보편적으로 사용하는 J2EE 의 Packaging Scope 은 이러한 클래스로더의 특성에 기반하게 된다. DummyApp라는 어플리케이션 내에 DummyWeb1 과 DummyWeb2라는 Web 모듈과 DummyEjb라는 Ejb모듈이 있다고 가정한다면, DummyWeb1 은 자신의 클래스로더는 물론 DummyEjb 의 클래스로더에 접근이 가능하다. 상위 로더인 WAS 및 JVM 클래스로더도 물론 가능하다. 그러나 DummyEjb 가 DummyWeb1 혹은 DummyWeb2 에 접근하지 못하며 DummyWeb1 과 2 간에도 접근이 불가능하다.

Packaging 이 다른 두 배포 단위간에는 WAS 및 JVM 클래스로더외에는 접근이 불가능하다. (동일한 WAS 인스턴스에서 Packaging 만 분리할 경우) 따라서 이 경우에 Remote 호출을 받아주는 상대편의 EJB 모듈을 이용하여 호출을 할 수 있으나 클래스로더는 엄연히 다르다. (Remote 호출은 WAS 인스턴스 여부와 상관없이 가능하다)

하단 그림은 본 시스템에 적용되는 아키텍처를 나타내는데, 기본적인 J2EE 아키텍처와는 달리 하나의 WAS 인스턴스(Jeus 는 Container라는 용어 사용)에는 하나의 Web 클래스로더와 하나의 EJB 클래스로더만이 존재하게 된다. Web 클래스로더는 웹 컨트롤러가 위치하는 곳이며, 단지 사용자의 HTTP Request 를 전문으로 변환하여 EJB 에 전달하고 반환된 결과를 전문에서 HTTP Response 로 변환하는 역할을 한다. EJB 클래스로더에 실제 업무를 처리하는 어플리케이션이 디플로이되는데, ProFrame 의 자체적인 클래스로더의 범위 내에 EJB 로 구성된 어플리케이션이 배치된다. 이러한 단위를 Category라고 부르는데, 하나의 어플리케이션으로 EJB 클래스로더를 공유하더라도 Category 의 분할에 따라 별도의 클래스로더를 사용하는 효과를 가진다. 동일한 WAS 인스턴스를 사용하는 경우 Category 를 나누더라도 런타임 시에 하나의 클래스로더처럼 Web 클래스로더와 특정 Ejb 클래스로더를 동적으로 바인딩시켜주는 기능을 Jeus 가 제공한다(Shared Class Loader 모드). 따라서 겉보기에는 마치 하나의 배포 단위로 보이게 하나, 실제의 비즈니스 서비스가 위치한 ProFrame 클래스로더는 엄연히 별도로 존재하게 되며, 클래스의 reload 시 (Hot Deploy 등) 에 ProFrame 클래스로더 단위 별로 refresh 가 된다. 그러나 Category 별로 디플로이/언디플로이를 하지는 못한다.

패키징 방안


ProFrame 의 클래스로더 아키텍처는 J2EE 의 기본 아키텍처와 차이는 있으나 배포단위의 구분은 여전히 다음과 같은 중요한 의미를 가지고 있다:

상이한 Category 로 분할되는 ProFrame 클래스로더는 독립적으로 운영된다. 즉, 클래스의 메모리 로딩이 별개로 되기 때문에 자신이 필요로 하는 클래스 및 라이브러리들만 로딩/리로딩/Garbage Collection 이 가능하다.

따라서 Category 간에 서로 영향을 주고 받지 않는다. 물론 서로 공유하고 있는 상위 클래스로더의 상태는 산하에 디플로이되는 전체 어플리케이션에 영향을 주지만, 적어도 다른 Category 의 상태로 인해 영향을 받지 않는다.



작성일자 2008/03/28



이와 같은 사실을 기반으로 본 시스템의 Packaging 아키텍처 방안을 수립할 때 다음과 같은 네가지의 대안이 가능하다 (다음 페이지 그림 참조):

대안 1 은 하나의 WAS 인스턴스에 기간계 시스템 전체를 하나의 Application 으로 Packaging 하는 것을 나타낸다. 즉 하나의 ProFrame 클래스로더 내에 시스템이 필요로 하는 모든 클래스들과 라이브러리들을 전부 로딩하게 된다.

이러한 방식은 패키징의 단위를 분할하지 않으므로 빌드 및 디플로이 관리가 용이하고, 각종 공통 클래스 및 라이브러리를 한번 로딩하여 공유함으로써 메모리를 절약할 수 있으며, 기간계 시스템 내부 간 호출은 전부 Local 로 처리되므로 성능이 향상될 수 있다는 장점이 있으나, 디플로이/리디플로이 시 한꺼번에 로딩이 일어나므로 시간이 오래 소요되고 런타임 시에 기간계 시스템의 일부 모듈의 상태로 인해 다른 모듈에 영향을 줄 수 있다는 취약점이 있다. 특히 유지보수 시에 한 조직이 담당하는 모듈을 빌드 및 디플로이하는 과정에서 불필요하게 타 조직이 담당하는 모듈의 상태에 영향을 줄 수 있는데, 이는 심각한 문제를 야기할 수 있다. 또한 한정된 WAS 클래스로더 내에 전체 어플리케이션을 디플로이하여 서비스한다는 것은 런타임 시 메모리의 부족으로 인한 장애를 초래할 수 있다.

대안 2 는 WAS 인스턴스를 업무 영역별로 분리하되 하나의 인스턴스에는 하나의 Application 으로 Packaging 하는 방식이다. 인스턴스 별로 클래스로더 영역이 명확하게 나누어지고, 그 위에 하나씩의 ProFrame 클래스로더를 가진다. 기간계 시스템은 WAS 인스턴스와 동일한 업무 영역 별로 분할하여 Packaging 한다.



작성일자 2008/03/28



대안 2 는 영역 별로 WAS 레벨부터 클래스로더를 분할하여 사용하기 때문에 배포단위 간에 독립적인 운용이 가능하다는 장점을 가지고 있다. 즉, 어떤 이유로 인해 한쪽 영역의 WAS 인스턴스가 중지된다 하더라도 다른 쪽 어플리케이션 동작에 전혀 영향을 주지 않게된다. 또한 상대적으로 배포 단위가 작아지므로 디플로이 및 리디플로이 시에 소요되는 시간이 줄어들며, 유지 보수 조직의 명확한 책임과 권한 통제가 가능하다.

그러나, WAS 인스턴스는 자체적으로 서버 자원을 많이 소비하고 각 인스턴스 별로 운영 관리가 필요하므로 과도하게 분할하여 운용하는 것은 바람직하지 않다. 배포단위를 분할하여 Packaging함으로써 빌드 및 디플로이 관리가 상대적으로 까다로와진다. (공통 클래스 및 라이브러리의 싱크 유지, 상호 호출 관계 존재 시 디플로이/리디플로이 순서 유지 등) 또한 공통 성격의 클래스와 라이브러리들을 각 WAS 인스턴스 별로 로딩하므로 메모리 소요량이 늘어난다. WAS 인스턴스 간 기능 호출이 필요한 경우에는 Remote 호출이 되므로 성능저하의 요소가 있는 단점이 있다.

대안 3 은 하나의 WAS 클래스로더를 유지하면서 업무 영역 별로 Packaging 하는 방안이다. 동일한 WAS 인스턴스 상에서 업무 단위 별로 ProFrame 클래스로더를 분할하여 디플로이한다.

이러한 방식은 ProFrame 클래스로더 레벨로 독립성을 유지하므로 대안 2 보다는 독립성이 명확하지는 않지만 상호 영향을 주고받는 위험성을 줄일 수 있는 장점이 있다. WAS 인스턴스를 분리하지 않으므로 시스템 자원을 덜 소요하고, Category 단위 별로 적절한 크기를 유지하므로 디플로이 및 리디플로이 소요시간이 최적화될 수 있으며 유지보수의 명확한 책임과 권한 영역이 가능하다. 그러나, 특정 어플리케이션에 의해 WAS 인스턴스 자체가 영향을 받아 다른 모든 어플리케이션까지 지장을 초래할 수 있다는 위험성이 있고, 한 인스턴스 내에 모든 어플리케이션을 디플로이하는 것은 런타임 시 서비스 장애를 유발할 수 있다.



작성일자 2008/03/28



대안 4 는 대안 2 와 3, 즉 시스템을 분할하되 WAS 인스턴스를 분할하는 방식과 Packaing 을 분할하는 방식의 장점을 취하고 단점을 보완하는 방안이라 할 수 있다. 먼저 WAS 인스턴스를 분리하는 것을 고려하는데, 시스템 부하 등을 고려하여 상호 WAS 레벨의 영향을 주고받지 말아야 하는 단위 별로 그룹핑을 한다. 예를 들면, 일반적으로 대량 데이터를 한꺼번에 처리하는 Reporting 모듈은 런타임 시 많은 부하를 발생하므로 일반 온라인 업무를 처리하는 모듈이 디플로이되는 WAS 인스턴스와는 분리하여 디플로이한다. 그러나, 시스템 자원이 허용하는 범위 하에 적절한 수로 분할하도록 한다. 시스템 자원의 범위를 넘어서는 것은 런타임시 불안정한 서비스로 이어지게 된다.

동일한 WAS 인스턴스 상에 같이 디플로이되는 어플리케이션은 자체 클래스로더를 가지고 독립적으로 운용할 Categoty 단위로 분할한다. 자기가 속한 WAS 인스턴스의 영향은 받지만, 상호 간의 직접적인 영향은 주고받지 않아 실제 배포 단위의 영향 범위는 물론 이를 담당하는 책임과 권한 소재 범위도 명확하게 통제한다.

이러한 방식은 WAS 클래스로더 및 ProFrame 클래스로더의 특성을 살려 최적화된 어플리케리션 운용을 가능하게 한다. 그러나, 각 배포 단위의 빌드 및 디플로이 관리는 더욱 까다로와 질 수 있으며, 필요시 Remote 호출은 피할 수 없다.

위에서 살펴본 네가지의 대안을 비교해보면 다음과 같다:

비교항목(우선순위 순)

대안 1 대안 2 대안 3 대안 4 비고

WAS 의 안정적인 서비스 및 관리

△ ○ △ ◎

독립적인 운용 ⅹ ◎ △ ○기간계 내부 호출시 성능

◎ △ ◎ △

메모리 소요 ◎ ⅹ ◎ ○디플로이/리디플로이 소요시간

△ ○ ○ ○

빌드 디플로이 관리 ◎ △ ◎ ○명확한 유지보수 범위

ⅹ ○ ○ ○

결론: 본 아키텍처에서는 대안 4 를 적용하도록 한다 . 공통적으로 사용하는 클래스들을 중복 디플로이하여 접근이 제한된 리소스 (DB 혹은 비즈니스 로직 ) 를 제외하고는 Local 호출을 하도록 한다 . 빌드 및 디플로이에 대한 관리의 어려움은 관리 프로세스를 명확하게 확립하므로서 극복하도록 한다 .



작성일자 2008/03/28



온라인 Application 단위


기간계 시스템은 위의 그림과 같이 WAS 인스턴스를 세개로 분할한다:

조사심사, 기술평가, 보증실행, 관리 및 회계 등의 영업 업무와 인사/급여, 자금, 조달 등의 본부 업무를 담당하는 본부 업무용 WAS

인사 ERP 업무를 담당하는 인사 WAS

리포트를 담당하는 리포트 WAS

리포트 서버 용 WAS 는 자체적으로 부하를 많이 발생하므로 분리한다. 리포트 출력으로 인해 다른 시스템이 장애를 일으키는 것을 방지하고, 리포트 WAS 의 서비스가 중단되더라도 다른 시스템은 정상적으로 작동할 수 있어야 한다. 인사 ERP 시스템은 별개로 운영 관리가 되어야 하므로 분리한다.

영업 및 본부 업무들은 하나의 WAS 에 배포하나, 상기 그림에서 보는 바와 같은 단위 기능 별로 개별 Category 로 구분한다.

기간계 업무와는 별개로 시스템 관리를 별도의 Category 로 분할하도록 한다. 기간계 업무와는 성격이 독립적이기 때문에 런타임 부하 발생 시 영향도를 최소화하고 독립적인 어플리케이션 운용을 할 수 있도록 하기 위함이다.

인사 ERP WAS 에는 인사 ERP 시스템을 하나의 Category 로 배포한다.

리포트 WAS 에 디플로이되는 어플리케이션은 리포팅 제품(Oz) 자체 서버모듈이며, 리포트 출력에 대한 모든 요청을 전담하게 된다.



작성일자 2008/03/28



화면 및 리포트 파일이 배포되는 Web 서버는 클래스로더의 제약이 없고 특성 상 여러 개의 인스턴스를 올리는 것이 가용성 측면에서 더 중요하므로 아래 그림과 같이 전체를 하나의 Web 서버에 배포하도록 한다.

기간계 내부 시스템 간 호출 방식


상단 그림에서 각 시스템 간 호출 관계가 점선으로 표시되어 있다. 런타임 시 타겟 시스템의 데이터 혹은 로직 처리를 필요로 하는 것으로, 그 형태가 반드시 직접적인 API 호출인 것이 아니고 요건에 따라 해당 DB 직접 접근 방식 혹은 Asynch 의 경우 JMS 서버를 활용하는 방식이 될 수 있다.

온라인 서비스 중 실시간(Synch)으로 데이터 작업이 필요한 경우에는 해당 DB 를 직접 접근하는 방식으로 처리한다. 실시간으로 로직 처리가 필요한 경우에는 해당 서비스를 직접 호출하는 방식으로 한다. 이때, 컨테이너 단위로 분리되어 있는 시스템 간의 호출은 Remote 가 되나, 동일한 컨테이너 내 Category 간의 호출은 Local 호출이 된다. Remote 호출은 성능 저하를 유발할 수 있으므로 이러한 요건을 최소화해야 하며, 따라서 해당 모듈을 동일한 컨테이너에 포함시킬 수 있는지 여부를 반드시 고려하도록 한다.

실시간 처리가 필요하지 않은 경우(Asynch) JMS 를 사용하여 처리한다. EAI 를 기간계 내부에서는 사용하지 않는다. 영업 업무 시스템의 경우 뒷 단의 본부나 인사 ERP 시스템이 장애를 일으키더라도 정상 동작이 되어야 하므로 가능하면 비동기 호출을 사용하도록 한다.

배포 Stage 구조



작성일자 2008/03/28




서비스할 클래스가 스테이징되는 구조는 위의 그림과 같다. 컨테이너로 WAS 인스턴스를 분리하기 때문에 개별적인 클래스패스를 가지도록 한다. 컨테이너 별로 독립적인 서비스를 하기 때문에 하나의 클래스패스를 공유함으로서 발생할 수 있는 불필요한 간섭현상을 막기 위해서이다.

서비스할 class 들과 전문, DBIO 등의 설정 파일들이 classes 아래 각각의 디렉토리에 위치한다. Properties 파일들은 /classes/PFM_MODULES/org/kibo/properties 에 위치시킨다.

각종 사용할 라이브러리들은 /lib 에 위치한다. 공통 모듈은 kibo-common.jar 로 묶어서 /lib 에 위치시킨다.

배치 프로그램은 온라인 프로그램과의 일관성 확보와 배포의 편의성을 위해 온라인 프로그램과 동일하게 컨테이너 별로 배포한다. 컨테이너를 나타내는 디렉토리에 온라인 프로그램과 마친가지의 구조로/ classes 와 /lib 를 위치한다. 추가적으로 배치 프로그램을 실행시킬 Shell Script 를 /script 에 위치시킨다.



작성일자 2008/03/28



4.5.2Application Topology


기간계 시스템의 토폴로지는 위의 그림과 같다. Web 서버와 Ap 서버, 그리고 DB 서버가 이중화 되어 있으며, 각 서버 별로 동일한 내용으로 구성한다. Web 서버는 앞서 살펴본 바와 같이 기간계에서 필요로 하는 모든 화면 (UI, 리포트)을 포함하는 디렉토리를 공유하면서 한 서버 당 최대 80 개의 프로세스를 띄운다. 따라서 접속자 수의 증가에 따라 최대 160 개의 프로세스가 서비스를 하게되고, 앞에 위치한 L4서버에서 로드발랜싱을 통해 이중 하나의 Web 서버로 Request 를 보낸다.



작성일자 2008/03/28



AP 서버에는 앞서 설명한 대로 업무 별로 3 가지 종류의 컨테이너가 위치하며, 가장 중요한 업무인 영업/본부 컨테이너를 4 개 띄워 가용성을 높인다. 나머지 인사 업무과 보고서 용 컨테이너를 1 개 씩 띄운다. 따라서 서버 당 총 6 개의 컨테이너가 서비스를 하게되며, 2 대를 합해 12 개의 컨테이너가 운영된다. 앞에 위치한 Web 서버가 이 중 하나의 인스턴스로 Request 를 보내게 된다. Data pool 은 같은 종류의 인스턴스끼리 동일한 데이터소스를 사용한다.

DB 서버는 두개의 서버를 Active-Active 로 운영한다. 상황에 따라서 둘 중 하나의 서버로 Request 가 전달된다. 배치 프로그램은 DB 서버에 위치하여 동작하는데, 오프라인 배치 프로그램은 1 번 서버에서 실행된다. 1 번 서버에 장애가 발생하면 동일한 프로그램이 위치한 2 번 서버의 프로그램을 실행해야하는데, Fail Over 는 자동으로 이루어지지 않으므로 관리자가 직접 실행을 해야 한다. 온라인 배치의 경우, Request 를 받는 Demon 을 양쪽 서버에 1 개씩 띄운다.



작성일자 2008/03/28



5. 정보계 아키텍처

5.1 개요

정보계 시스템은 기금 내부 사용자만 접근하는 내부 시스템이다. 정보계 어플리케이션에서 사용하는 솔루션 및 호출관계를 실행관점에서 표현하면 다음과 같다.

정보계 어플리케이션의 기본구조는세가지 스타일로 구분할 수 있다. 첫번째는 일반 JSP 및 Servlet 을 기본적인 기술구조로 가지는 경영정보 시스템의 Thin Client 스타일이고, 두번째는 dynaSight 제품의 기본 아키텍처를 활용하여 EIS 서버 엔진과 클라이언트 Applet 기반으로 구현되는 스타일이 존재한다. 세번째 스타일은 Sagent OLAP 제품의 기본 아키텍처를 활용하여 OLAP 서버 엔진과 ActiveX 기반의 UI 를 기반으로 구현된다.



작성일자 2008/03/28



이러한 세가지 스타일의 아키텍처는 ETL 툴을 통해 구성되는 DW 시스템을 데이터 소스로 활용하며, EP 를 통해 웹 기반의 서비스를 제공한다. 또한 SSO 를 통한 통합 로그인의 대상이다.



작성일자 2008/03/28




EIS 와 OLAP 의 기본적인 Application Structure 는 제품의 아키텍처를 유지하게 되므로 별도 기술을 생략하도록 한다. 여기서는 경영정보 시스템의 구조를 논리적인 관점에서 살펴본다.

경영정보 시스템은 JSP 기반의 Thin Client 스타일의 구조를 가진다. 상이한 클라이언트를 처리할 필요도 없고 컴포넌트의 재사용 가능성도 높지 않기 때문에 Process Layer 와 Biz Logic Layer 를 명확하게 나누는 서비스 컴포넌트를 제거한 구조를 가진다. 레이어간 관계의 특징은 다음과 같다. 웹 컨트롤러

HTML 혹은 JSP 에서 전달되는 Http Request 를 수신하여 적절한 User Transaction 컴포넌트로 전달한다. 그리고 반환된 처리 결과를 Http Response 형태로 Client 에 돌려 준다.

서비스 컴포넌트웹 컨트롤로를 통해 들어온 Request 는 end-to-end 로 이를 처리할 Façade 역할을 하는 서비스 컴포넌트로 전달된다. 하나의 Request 는 이에 상응하는 하나의 method 에 의해 처리되어야 Transaction을 보장할 수 있다.



작성일자 2008/03/28



서비스 컴포넌트는 사용자 Request 의 완수를 위해 트랜젝션 종속적인 비즈니스 로직을 처리하며, 그 과정에서 복수 개의 Domain 컴포넌트와 DAO 컴포넌트를 활용할 수 있다. 비교적 로직이 까다롭지 않다고 판단되므로 간단한 구조를 유지하기 위해 다른 서비스 컴포넌트를 호출하지 않도록 한다. 물론 Application 간 Remote 호출도 없다.

Domain 컴포넌트 (공통 컴포넌트)서비스 Component 에서 직접 처리하는 비즈니스 로직을 제외한 공통 로직, 혹은 재사용 가능한 로직 등은 도메인 종속적인 (혹은 시스템 공통적인) 별도의 Domain 컴포넌트로 정의한다.

Domain 컴포넌트는 역할 수행을 위해 DAO 컴포넌트를 활용할 수 있다. Domain 컴포넌트는 다른 Domain 컴포넌트와 직접적인 호출관계를 가질 수 있다. 그러나 서비스 컴포넌트를 호출하지는 못한다.

Data Access 컴포넌트 (DAO)서비스 컴포넌트 혹은 Domain 컴포넌트에서 DB 처리가 필요한 경우 DAO 를 활용하여 데이터 접근 로직을 비즈니스 로직으로부터 격리하도록 한다. Value Object 와 DB Table 간 매핑관계를 관리한다.

한 업무 패키지 내의 DAO 는 해당 업무의 Owner 인 서비스 컴포넌트 혹은 Domain 컴포넌트에 의해서만 사용 가능하다. 다른 패키지의 DAO 를 직접 호출할 수 없고 그 패키지의 서비스 컴포넌트 혹은 Domain 컴포넌트를 통하여 호출해야 한다.

Value Object레이어 간, 그리고 컴포넌트 간 데이터를 주고 받을 때 사용하는 일종의 파라미터 클래스의 역할을 한다. Value Object 는 순수히 업무적인 속성과 메소드를 가지고 있다.

경영정보 시스템은 비즈니스 컴포넌트의 재사용 가능성이 높지 않고, 웹 이외의 클라이언트로 확장할 요건이 없다고 판단된다. 또한 이러한 레이어의 명확한 구분보다는 구조의 간결성 유지가 더 유리하다고 보기 때문에 서비스 컴포넌트까지는 Http Request 의 형태를 활용하고, 하위 레이어에서는 이를 제거하여 Value Object 만을 사용하도록 한다. 따라서 Domain 컴포넌트 및 DAO 컴포넌트는 웹 전용이 아닌 순수 비즈니스 기반으로 유지될 수 있다.

각 컴포넌트 간 호출은 반드시 Factory 를 통해 생성하도록 한다.



작성일자 2008/03/28




각 레이어 별로 상세한 구성을 알아보도록 한다. OLAP 과 EIS 에 관해서는 해당 제품의 아키텍처 자료를 참고하도록 하고, 본 장에서는 경영정보 시스템에 대해 집중적으로 다루도록 한다. OLAP 및 EIS 와의 연계 관련 아키텍처는 기타에서 다루고 있다.


통합 사용자 마스터 연계


통합 사용자 마스터 데이터는 HR 시스템에서 주기적으로 DB 에 로딩해준다. 따라서 기본적으로 본 데이터는 Read Only 로 사용한다. 여기에 별도의 사용자 관리 프로그램을 통해 HR 시스템에 없는 사용자를 추가 등록하여 통합적인 사용자 마스터를 구성하게 된다.

이러한 마스터 데이터는 정보계 뿐 아니라 전체 시스템을 구성하는 여러 단위 시스템들 간에 공유된다. 즉, 사용자에 대한 정보(직원 정보, 조직 정보 등)를 필요로 하는 기간계 시스템, EP, SSO, BPM 등이 그 대상이다. 그룹웨어는 HR 시스템과 직접 별도로 동기화를 하므로 본 마스터 데이터를 사용하지 않는다.

SSO 시스템은 본 통합 사용자 마스터 데이터를 활용하여 자체적으로 통합 사용자 계정을 관리하게 된다. 통합 계정정보는 SSO 에 위치하며, 각 시스템을 SSO 를 통해 접근할 때 이 계정 정보를 사용하게 된다. SSO 장애시에 기간계 시스템에 접근하기 위해서 (비상 로그인) 주기적으로 SSO 시스템이 가지고 있는 정보계용 계정 데이터를 백업하여 비상시에 사용한다. 기타 시스템도 이러한 비상 로그인 프로세스가 필요한 경우에 한하여 자신들의 계정 데이터를 SSO 로부터 백업받도록 한다.



작성일자 2008/03/28



EP – JSP 연계


EP 에서 정보계 화면을 호출하는 방식은 URL 링크 방식을 사용한다. 사용자가 EP 에 화면을 요청할 때 정보계 특정 업무를 처리할 수 있는 URL 링크 정보가 같이 출력된다. 사용자가 해당 링크를 선택하면 해당 JSP 화면을 호출하게 되는데, 이때 전달하고자 하는 초기 값들이 Parameter 형식으로 넘어간다. 이러한 값들을 사용하여 해당 화면 출력은 물론, 전달받은 초기 값이 출력되어 사용자가 바로 사용할 수 있는 상태가 된다.

정보계와의 SSO 연동을 위해 EP 와 사용자 간에 유지되는 SSO 토큰 정보는 정보계 웹브라우저와 공유된다.

JSP – Reporting 연계


기간계 시스템과 달리 데이터를 직접 Oz Viewer 에 전달하는 방식이 가능하지 않기 때문에 화면에서 입력된 파라미터 정보(보고서 출력 조건)를 Oz Viewer 에 넘겨주면 이를 Oz 리포트 서버의 자체 쿼리 실행을 통해 데이터를 fetch 해온 후 보고서 양식에 맞게 출력하는 방식만을 사용한다.

Oz 서버는 기간계에서 사용하는 서버를 같이 사용하도록 한다.



작성일자 2008/03/28








작성일자 2008/03/28





웹 컨트롤러 (Front Controller vs. Page Controller)


Request 를 서버로 전달하고 Response 를 반환하는 처리 과정에는 다음과 같이 두가지 방식이 있다. 두 방식 다 기본적으로 MVC (Model – View - Controller) 패턴 기반으로 구성한다.

첫번째 방식은 Page Controller 를 사용하는 것이다. 사용자 Request 는 JSP 로 표현되는 페이지를 통해 서버로 전달된다. 이때 각 페이지 내의 Page Controller 에 Request 시 사용하고자 하는 서비스를 명기한다. Page Controller 는 해당 페이지의 특정 Request 를 처리하는 로직을 가진 서비스 클래스(Behind)로 라우팅 한다. 이를 받은 서비스 클래스는 Request 를 처리한 후 원래의 페이지로 반환하거나, 필요한 경우 다른 페이지로 이동하게 된다.



작성일자 2008/03/28



두번째 방식은 J2EE 웹 프레임워크에서 자주 사용하는 MVC 아키텍처의 방식인 Front Controller 와 Command Pattern 이다. 특정 화면과 별개로 사용자 Request 가 들어오면 이를 Front Controller 인 Servlet에서 일괄적으로 받아 해당 Request 를 실제적으로 처리할 Action 클래스로 라우팅한다. 이 때 파일 혹은 DBMS 에서 Request URL 과 Action 간의 매핑을 참조한다. Action 클래스에서 처리를 마친 후 그 결과를 Randering 할 View 페이지를 지정하여 출력한다.



작성일자 2008/03/28



이 두가지 방식을 비교하면 다음과 같다:

항목 Page Controller Front Controller

설정 페이지 마다 JSP 태그로 설정.XML 파일 혹은 DB 테이블에 설정하며, do 확장자를 가진 URL로 표현.

JSP 의존성 JSP 에 의존함. JSP에 의존하지 않음.

주요 사용 목적하나의 서비스 내에 동일한 유스케이스 내의 여러 기능 구현.

특정 페이지와 상관 없이 어플리케이션에서 전역적으로 사용되는 기능 구현. (로그인 등)

동작 메커니즘코드 Behind 를 이용한 이벤트 방식의 동작.

일반적인 MVC(Model View Controller) 패턴과 Command 패턴에 맞추어 동작.

장점 - 페이지 안에 자신이 사용할 서비스를 명기함으로써 이를 위한 매핑 정보를 별도로 설정할 필요가 없이 간결해짐.- Servlet Filter 를 활용한 Chain 방식으로 유연성 있게 처리할 수 있음.- Request 당 하나의 클래스를 만드는 Command 방식보다는 유스케이스 당

- 특정 페이지와 독립적으로 사용할 수 있음.



작성일자 2008/03/28



하나의 Behind 클래스로 구현할 수 있으므로 개발 및 유지보수가 편리함.

단점- 여러 페이지에 걸쳐서 사용되는 로직을 처리하기 어려움

- Request당 이를 처리하는 서비스 클래스를 생성해야 하므로 클래스 개수가 많아짐- Request와 서비스 클래스 간의 매핑 정보를 관리하는데 오버헤드 발생함

결론: 경영정보 시스템 중 대부분의 기능은 화면에 종속된 서비스라 판단되므로 보다 간결한 구조 하에서의 개발 및 유지보수를 위해 Page Controller 방식을 사용한다 . 일부 페이지에 종속되지 않는 서비스에 한 해 Front Controller 방식을 병행하여 적용하도록 한다 .

웹 컨트롤러 (Request 처리)


위와 같이 두가지 방식을 채택한 상태에서 사용자 Request 를 처리하고 Response 를 내보내는 방식은 위의 그림과 같다. 먼저 사용자 Request 가 들어오면 Front Contoller 혹은 Page Controller 가 이를 받아 원래의 HttpRequest 객체를 포함한 Request 객체로 만든다. 웹컨트롤러가 이를 서비스 클래스 (Action 혹은 Behind 객체)로 넘겨주면 여기서 필요한 정보를 추출하여 요청 사항을 처리한 후 HttpResponse 객체를 포함한 Response 객체로 만들어 다시 웹 컨트롤러에 보내게 된다. 웹 컨트롤러는 이를 해석하여 최종적으로 사용자에게 처리 결과를 출력하게 된다.

웹컨트롤러 (SSO 로그인 및 사용자 세션 처리)




작성일자 2008/03/28



기금 내부 사용자는 SSO 를 통해 시스템에 로그인한다. 한번 로그인한 사용자는 원하는 시스템에 최초 접근할 때 사용자가 가지고 있는 SSO 쿠키 정보가 유효한지, 유효하다면 사용자가 해당 시스템에 접근 권한을 가지고 있는지 여부를 확인하기 위해 시스템 내부적으로 SSO 로그인을 거치게 된다. 로그인이 성공적으로 이루어진 경우 해당 사용자의 기본 정보를 메모리 상에 적재하여 권한 처리 등 통상적인 업무 처리 시에 수시로 참조할 수 있도록 한다.

사용자 정보를 적재하는 방식은 클라이언트 쿠키를 사용하는 방식과 서버 세션을 사용하는 두가지 방식이 있는데, 기간계 시스템과 동일하게 서버 측의 세션을 사용하도록 한다.

먼저 시스템에 최초로 접근하는 Page 에서 SSO 쿠키 정보와 접근하고자 하는 시스템의 아이디가 전달되면 SSO Login 처리를 하기 위한 서블릿 필터를 실행하여 SSO 측의 Policy 서버와의 통신을 통해 SSO 쿠키 및 시스템 접근권한을 확인하도록 한다. 확인이 실패하는 경우 SSOSecurityException 을 발생하여 접근을 막도록 한다.

로그인이 성공한 후 SSO Login 서블릿 필터는 필요한 사용자 정보를 정보계에서 fetch 하여 WAS Session에 적재하게 된다. 사용자 정보가 서버 측에 로딩되게 되므로 사용자 관련 정보를 클라이언트가 가지고 있을 필요가 없고, 이후의 모든 서버 Request 를 처리할 시 WAS Session ID 만 넘겨주면 해당 Behind 가 서버 Session 에서 필요한 사용자 정보를 추출하여 Request 를 처리하게 된다.

웹컨트롤러 (Request 별 WAS 세션 및 SSO 쿠키 확인)




작성일자 2008/03/28



일반 웹 브라우저를 통해 정보계 어플림케이션에 초기 request 를 전송하면(1), 정보계 시스템은 현재 요청된 Request 내의 SSO 토큰 정보를 체크한다(2). 먼저 통합로그인을 거쳤는지, 그리고 현재 토큰이 유효한지 여부를 확인하도록 한다. 이 두가지 항목 체크에 실패하면 통합 로그인 페이지로 리디렉트한다(3).

정상적으로 통과되면 통합 사용자 마스터 데이터를 이용하여 사용자 정보를 세션에 저장한다(4-5). 일단 초기화가 된 상태에서 다음 Request 부터는 SSO 토큰을 체크하지 않는 대신 WAS 의 세션에 사용자 정보가 있는지 여부를 확인한다(6-7). 만일 세션이 유효하지 않다면 오류 메시지를 출력하고 프로그램을 종료한다(8).



작성일자 2008/03/28



SSO 장애 시 비상 로그인


기간계와 마찬가지로 SSO 에 장애가 발생할 시에 임시적으로 시스템에 접근 가능할 수 있도록 하는 별도의 프로세스가 필요하다. 비상 로그인 화면에서 SSO 와 동일한 Id, Password 를 입력하면 웹 컨트롤러에 있는 Login 모듈에 의해 인증을 받아 User 세션을 생성하게 된다.

웹컨트롤러 (Exception 처리)


서비스 클래스(Action 혹은 Behind 클래스)에서 발생하는 Exception 은 Runtime Exception 이건 Application Exception 이건 모두 웹컨트롤러에서 catch 를 한다. Catch 된 Exception 은 해당 서비스 클래스에서 정의한 Response 객체로 반환되고, 이를 Rendering 하여 사용자에게 화면을 출력하게 된다.



작성일자 2008/03/28



Exception 의 종류에 따라 Handling 이 달라지는데, Runtime 인 경우는 Error Page(500 에러)로 forward시키고, Application Exception 의 경우는 Popup 으로 에러 내역을 출력한다.

그리드 적용 방안


정보계 시스템은 목록 데이터를 출력하기 위해 HTML 의 TABLE 대신에 ActiveX 로 구현된 Grid 컴포넌트를 사용한다. 클라이언트 단에서 데이터 처리를 다양하게 하기 위함이다.

그리드 컴포넌트를 사용하여 데이터를 조회하는 경우 아래 그림과 같은 방식을 사용한다:

입력된 검색 조건과 함께 Ajax 방식으로 서버를 호출하면 서버 측의 Behind 혹은 Action 에서 Request 를 받아 데이터를 조회하고 그 결과를 해당 JSP 에 Ajax Response 로 전달하게 된다. Callback 스크립트가 작동하면서 반횐된 데이터를 그리드 컴포넌트에 바인딩하게 된다.

그리드 데이터 저장의 경우는 Ajax 호출을 통해 해당 그리드의 데이터를 서버에 전송하고, 서버는 이를 받아서 저장한다. 처리 결과에 대한 메시지를 반환하면 이 또한 Callback 함수를 통해 사용자에게 출력된다.



작성일자 2008/03/28



이러한 입출력 처리에 있어 Ajax 를 사용하는 이유는 비동기적으로 서버와 통신할 수 있어 효율적이고 또한 화면 전체의 refresh 없이 필요부분 (그리드 바인딩 등)만 업데이트가 가능하기 때문이다.

서비스 컴포넌트 내 데이터 전달


앞서 살펴보았듯이 웹 컨트롤러에서는 HttpRequest 및 HttpSession 을 Wrapping 하는 Request 객체를 생성하여 서비스 컴포넌트로 넘겨준다. 사용자의 입력 값은 Request 객체에 들어 있는데, 서비스 컴포넌트 내에서 이를 표현하고 처리하는 방식에는 다음과 같이 두가지 방식이 존재하게 된다.

대안 1 은 별도의 Plain 한 Java Bean 을 Value Object 로 구현하여 Request 객체 내에 있는 해당 데이터를 Plain VO 로 전환하는 방식이다. 그에 비해 대안 2 는 별도의 VO 구현 없이 Java Map 을 활용하여 해당 데이터를 Map 으로 전환하는 방식이다.



작성일자 2008/03/28




구분 장점 단점 비고대안 1 Plain VO 가 직관적인 구조를 가지고 있어

이해하기 쉽다.Strong Typing 이므로 오류발생을 줄일 수 있다. Parameter/Return Type 이 명확하다.VO 와 VO 간의 관계에 대한 표현 및 정합성 체크가 용이하다.향후 Web Services 의 endpoint 로 노출하고자 할 경우 그대로 활용이 가능하다.필요시 로직을 VO 내부에 구현할 수 있다.


대안 2 별도의 VO 개발 비용이 없다.런타임 시 데이터 변환을 속도 저하 없이 자동으로 처리 가능하다.

Generic 한 타입이므로 클래스 만으로는 무슨 데이터를 나타내는지 이해하지 못한다.Strong Typing 이 아니라 항상 key값을 알고 있어야 하므로 오류발생의 여지가 있다. Parameter/Return Type 이 명확하지 않다.VO 와 VO 간의 관계에 대한 표현 및 정합성 체크가 불가능하다.향후 Web Services 의 endpoint 로

적용



작성일자 2008/03/28



노출하고자 할 경우 별도의 VO 로 전환해야 한다.

결론: 대안 1 이 대안 2 보다 상대적으로 장점이 많은 것은 사실이나 , 현실적으로 VO 를 별도로 개발 및 유지보수하는 데는 많은 노력이 동반된다 . 따라서 본 아키텍처에서는 대안 2 를 사용하도록 한다 . VO 에 별도의 로직을 넣어야 할 필요가 있는 경우에는 해당 클래스를 별도 구현하여 컴포넌트 내에서 활용하도록 한다 .






작성일자 2008/03/28



웹 컨트롤러에 의해 실행되는 서비스 컴포넌트는 메소드 하나가 사용자 입장에서의 end-to-end transaction을 보장하게 된다. 즉, 실행되는 메소드의 실행 과정에 발생하는 모든 트랜젝션 자원들은 하나의 트랜젝션 Context 에 묶인다. 실행에 참여하는 트랜젝션 리소스 중 하나라도 실패하게 되면 전제가 Roll-back 하게 되고, 모두 성공해야만 비로서 Commit 된다. (Multi data source 혹은 리모트 EJB 호출의 경우 XA Driver 를 사용해야 함)

이렇게 실행되는 서비스 컴포넌트는 자체적으로 Use Case 에 종속적인 비즈니스 로직을 담고 있으며, 그 수행 과정에서 여러 종류의 컴포넌트를 활용하게 된다. 공통적이고 재사용 가능한 로직을 한 단위로 묶은 Domain 컴포넌트, 데이터 접근을 담당하는 DAO 컴포넌트, 그리고 타 시스템 연동을 담당하는 Integration 컴포넌트가 그것이다. 서비스 컴포넌트는 이러한 컴포넌트들을 모두 Component Factory 를 통해 접근한다.

각 컴포넌트간의 전송 파라미터는 프레임워크에서 제공하는 VO 생성기를 통해 Map 형태로 전송한다. 인테그레이션 계층에서 VO 는 DBIO 혹은 Proxy 에서 이해할 수 있는 형태로 변환이 되며, 이러한 변환 로직은 DAO 와 Interface 컴포넌트 내부에서 처리하도록 하여 비즈니스 로직과 격리한다.

서비스 컴포넌트는 다른 서비스 컴포넌트를 직접 사용할 수 없다. 공통적으로 사용할 로직이 있는 경우 Dmain 컴포넌트로 만들어 같이 사용하도록 한다.

Domain 컴포넌트




작성일자 2008/03/28



서비스 컴포넌트에 의해 실행되는 Domain 컴포넌트는 시스템 혹은 업무 레벨에서의 공통 로직 및 재사용 가능 로직을 담고 있는 컴포넌트이다. 따라서 유스케이스 독립적이며, 여러 유스케이스에 참여하여 담당하는 로직을 처리하는 역할을 한다.



Domain 컴포넌트는 필요한 경우 다른 Domain 컴포넌트를 호출할 수 있다. 이때도 마찬가지로 Component Factory 를 통해 호출하도록 한다.


Dao 컴포넌트


Dao 컴포넌트는 서비스 컴포넌트 나 Domain 컴포넌트에 의해 호출되며, Value Object 와 Database 간의 연동을 담당한다. 본 아키텍처에서는 Apache 의 ORM (Object Relation Mapping) Framework 인 iBatis 2.3(http://ibatis.apache.org/)을 활용하여 DAO 를 구현하며, 이러한 데이터 저장 로직을 비즈니스 로직으로부터 엄격하게 구분하도록 한다.


하나의 공통 컴포넌트로 DAO 를 만든 후 이 것이 모든 Input/Output VO 와 Dbio VO 간의 데이터 매핑을 일괄적으로 처리하도록 한다. 즉, 업무 별로 별도의 DAO 를 생성할 필요가 없으므로 개발 생산성을 향상할 수 있다.



작성일자 2008/03/28



5.3.5보

안 부분


Authentication



작성일자 2008/03/28




본 아키텍처에서는 기금 내부 사용자의 편의성 증대와 사용자 계정 정보의 통합 관리를 위해 통합 로그인을 구현한다. 통합 사용자 계정에 등록된 사용자는 SSO 에 로그인이 가능하다. (Authentication) 그러나 실제 특정 시스템을 사용하기 위해서는 해당 시스템에 접근할 수 있는 권한이 주어져야 한다.

사용자가 통합 로그인 화면을 통해 ID/PWD 를 입력하면 이를 확인하여 성공한 경우 SSO 쿠키를 발행한다. SSO 쿠키는 통합 대상 어플리케이션에 접근할 때 해당 어플리케이션 내 SSO Agent 에 전달되어 쿠키의 유효성 여부와 현 사용자가 해당 어플리케이션에 접근 권한이 있는지를 확인하게 되고, 쿠키가 유효하지 않는 경우는 다시 통합 로그인 화면으로 리디렉트 시킨다. 접근 권한이 없으면 권한 없음 메시지를 출력한다.

본 아키텍처에서는 Id/Password 방식과 PKI (사설인증서) 로그인의 두가지 로그인 수단을 제공한다. 따라서 사용자는 로그인 수단을 선택할 수 있다.

Id/Password 방식 로그인의 경우 SSO 서버를 통해 사용자 확인 후 SSO 토큰을 발행받는다. 반면 PKI 로그인의 경우는 ActiveX 로 된 인증서 제출 모듈을 통해 사용자가 가지고 있는 인증서를 제출한다. 이때 CA 서버를 통해 인증서의 유효성을 먼저 확인한 다음 SSO 서버에서 토큰을 발행받는다.

PKI 로그인을 위해 SSO 서버가 가지고 있는 통합 사용자 계정 데이터를 CA 서버의 인증서 데이터와 동기화해야 한다. 그렇게 해야만 SSO 에 등록된 사용자 계정이 CA 서버에서도 인증서를 통해 확인 가능하기 때문이다.



작성일자 2008/03/28



서비스 실행 권한


사용자의 서비스 실행 권한은 매 Request 마다 확인되는 것으로 특정 서비스 컴포넌트에 대한 Request 가 도착하면 웹 컨트롤러에 전달되기 전에 권한을 확인하는 Servlet Filter 가 이를 가로채게 된다. 권한 확인을 위해 Filter 는 세션에서 현재 사용자 정보를 가져오고, 이를 Security 컴포넌트를 통해 해당 서비스의 호출이 본 사용자에게 허용되는지를 확인한다.

허용이 되는 경우에는 예정대로 서비스 컴포넌트를 실행하게 되고, 허용이 안되는 경우에는 SecurityException 을 발생시킨 후 해당 Request 를 종료시킨다.



작성일자 2008/03/28



UI 권한 처리


특정 UI 내에서의 권한은 Page 가 로딩 될때마다 체크된다. Tag Library 를 통해 권한 통제 대상이 되는 UI 컨트롤을 지정하면 해당 페이지를 로딩할 때 마다 현재 사용자의 권한을 체크하고, 이에 따른 해당 컨트롤의 허용 여부를 결정하게 된다. 이러한 권한 별 UI 컨트롤 권한 설정은 별도의 관리 프로그램에서 이루어지며, 이러한 정의에 따라 해당 UI 컨트롤이 현재 사용자에게 접근 가능한지가 동적으로 결정된다.

이러한 UI 컨트롤에 대한 동적인 권한 처리를 위해 아래 그림과 같은 방안을 사용한다:



작성일자 2008/03/28



화면에서 권한 처리 대상인 UI 컨트롤을 Custom Tag Library 를 통해 지정하면 해당 페이지를 로딩하는 시점에서 서버에서 서버 세션에 존재하는 현재 사용자의 권한 정보를 기반으로 해당 UI 컨트롤에 대한 접근 권한 여부를 Security 를 담당하는 컴포넌트를 통해 체크한다. 그 결과에 따라 해당 UI 컨트롤을 페이지에 표시할 지 여부를 판단하여 권한을 처리한다.

이러한 권한 판단을 하는 Security 컴포넌트는 권한 관리 모듈에서 정의한 내역에 따라 이를 수행한다.

5.3.6기타

Logging

로그는 Log4J 의 Logger 를 사용한다. 아래 표와 같이 6 가지 레벨의 로그를 사용하여 각각의 Event 시에 로그를 남기도록 한다. 로그 레벨 별로 Logging 내역이 달라질 수 있으며, 저장하는 방식 및 위치도 달라진다.

level Event 내용 보관 처리 방안fatal SystemException발생시 Exception 내용,

Timestamp File 자동 처리



File 서비스 에서 throw 하면 자동 처리

trace 서비스 접근 시 사용자, IP, 실행서비스, Timestamp

File 자동 처리

warn TBD File 자동 처리info 트랜젝션

commit/rollback 내역사용자, 호출 내역, Timestamp

File 자동 처리필요 시 개발자 개별 처리

debug - 개발 시 필요에 따라 (각 Component 별

개발자 정의 내용실행 SQL

File 개발자 개별 처리자동 처리



작성일자 2008/03/28



Logger 정의)- 실행 SQL- Request/Response 내역

IO 내역

위와 같은 로그 레벨은 다음과 같이 File 에 저장하도록 한다.

Logger 는 해당 이벤트 발생 시 File Appender 를 사용하여 아래와 같은 내역을 로그 레벨 별로 해당 파일에 저장하도록 한다. 파일의 단위는 로그레벨 별로 구분하도록 한다.

내역 설명타임스탬프실행 클래스명로그레벨 Fatal/Error/Warn/Info/Debug메시지 로그 내용






작성일자 2008/03/28




DBMS 에 오라클 Row Num 쿼리 방식을 적용하는데, 이에 필요한 파라미터인 시작 Row Num 과 Page Size 정보를 페이지네이션 처리가 필요한 트랜젝션마다 Client 로부터 넘겨 받아야 한다. 웹 브라우저에서 Request 를 전송할 때 해당 정보를 파라미터의 형태로 보낸다.

이 정보는 서비스 컴포넌트를 거쳐 검색 조건과 함께 Dao 컴포넌트에게 전달되고, 여기서 필요한 정보를 얻어 DB 를 처리한다. 데이터가 fetch 되면 다시 결과 값을 돌려주는 PageList 를 생성하고 해당 Page 의 결과 값과 함께 total size, 현재 page no, list size, totoal page 의 정보를 담게 된다. 본 내용은 Custom Tag Library 에 의해 JSP 에 출력된다.

공통코드 로딩 및 동기화


기간계와는 달리 경영정보 시스템은 Thin Client 이기 때문에 런타임 시 클라이언트 자원을 사용하지 않고 전적으로 서버 자원에 공통코드를 위치시킨다.

먼저 서버에 어플리케이션이 디플로이될 때 Code 컴포넌트를 통해 모든 Code 정보를 메모리에 적재하도록 한다. 클라이언트가 코드 데이터를 필요로 하는 시점에 서버로부터 해당 코드 데이터를 Tag Libaray 를 통해 가져와 사용한다.

공통코드 관리 모듈을 통해 코드에 변경이 일어나면 서버의 Code 컴포넌트를 Refresh 하여 변경사항이 서버에 반영되도록 한다.



작성일자 2008/03/28



실시간 데이터 취합


기본적으로 정보계의 DW 시스템은 기간계의 실시간 데이터를 ETL 도구를 통하여 가져온 후에 접근 가능하므로 정보계 사용자가 신규로 반영된 데이터를 보기에는 시간차가 발생할 수 밖에 없다. 그러나 정보계 중 EIS 시스템은 기간계 시스템의 실시간 데이터를 접근하여 사용자에게 보여줘야 하는 요건이 있다.

이를 해결하는 방식은 두가지가 존재할 수 있는데, 가장 바람직한 방법은 별도의 Read Only DB 를 두는 방식이다. 본 DB 는 수시로 실시간 DB 와 동기화를 유지하도록 되어 있으므로 EIS 시스템은 실시간 DB (OLTP)에 전혀 영향을 주지 않고 Read Only DB 만을 사용하여 준 실시간 (Near Real Time) 데이터를 접근한다. 이러한 방식은 기간계 시스템과 정보계 시스템 양 쪽에 실행 시점에서의 부하를 줄이고, 상호 의존성을 주지 않으므로 매우 효과적인 것이로 판단된다. 그러나, 효율적인 관점에서 보면 별도의 DB 를 유지해야 하고 수시로 동기화를 해야하는 비용적, 관리적인 부담이 존재하게 된다.

반면, 중간의 Read Only DB 없이 실제 기간계 DB 를 직접 접근하는 것을 허용하는 방식의 경우, EIS 시스템에서 과중한 쿼리를 실행하면 그 여파가 기간계 시스템 자체에도 미치기 때문에 바람직하지 않으나, 별도의 비용과 부담 없이 구현이 용이하다는 장점이 있다.

본 아키텍처에서는 EIS 시스템에서 접근할 실시간 데이터의 량이 그다지 많지 않다는 전제 하에 기간계 DB 를 직접 접근하는 것을 허용하도록 한다. 따라서 이를 위한 별도의 비용적, 관리적 부담을 가져가지 않도록 한다.

UI 사용 편의




작성일자 2008/03/28



사용자의 사용 편의성 제고를 위해 화면의 구성을 적절히 해야하고, 메뉴 구성 또한 복잡하지 않게 하도록 한다. 이를 위해 디자인 시안과 표준, 그리고 템플릿을 사전에 정의하도록 하고, 이에 따라 각 화면의 구성 및 배치를 한다. 또한 사용자 입력의 편의를 위해 Text Box 의 입력 언어를 한글로 설정한다.

구체적인 사항은 디자인 표준 문서(KIBO_정보계_디자인가이드_v.1.1.ppt)를 참고하도록 한다.




이러한 문제 때문에 가능하면 사용자 환경에 직접 설치되어 작동하는 프로그램은 최소화하는 것이 기본적인 원칙이지만, Grid 같이 보다 강력한 UI 처리를 위해서는 불가피하게 사용해야 하는 경우가 있다. 본 시스템에서는 다음과 같이 반드시 필요한 Client 모듈만을 사용하도록 한다:

프로그램 설명VSFlexGrid 정보계 특성 상 복잡한 Grid UI Control 을 위해 사용한다.

관련 요구품질속성: RQ-STM-SA-1-09TChart 정보계 특성 상 Chart UI Control 을 위해 사용한다.

관련 요구품질속성: RQ-STM-SA-1-09Oz Viewer 보고서 형태로 데이터를 조회, 출력을 하기 위한 도구로서 Oz Report 를

적용하기 때문에 반드시 사용해야 한다. 관련 요구품질 속성: RQ-STM-SA-1-18

Issac PKI Client 인증서 기반 로그인을 하기 위한 도구로서 Issac 제품을 적용하기 때문에 반드시 사용해야 한다. 관련 요구품질 속성: RQ-STM-SA-1-20



작성일자 2008/03/28




EIS 및 OLAP 관련 구현 아키텍처는 해당 제품의 아키텍처 자료를 참조하도록 하고, 본 장에서는 경영정보 시스템의 아키텍처를 집중적으로 다루도록 한다.

경영정보 시스템은 Web Server 와 WAS 위에서 구동하게 된다. Web Server 상에는 WAS 서비스가 필요없는 정적인 구현 요소들이 탑재된다. SSO 와 EP 에서 사용하는 HTML 화면 및 JavaScript library 등을 배치한다.

WAS 서버는 분산 어플리케이션이 아니므로 Web Container 만을 사용하도록 디플로이되어 동작한다.

Application 패키지 구성


1. 전체 시스템 공통 Prefix 는 기간계와 마찬가지로 org.kibo 로 한다.2. 전체 시스템에서 공통적으로 사용하는 시스템 공통 패키지를 구성하여

모든 어플리케이션에서 접근 가능하도록 한다. (org.kibo.stm.fw). 여기에는 공통 컴포넌트와 Base Class 및 각종 Utility 를 위치시킨다.

3. 시스템 공통 레이어 위에는 전체 시스템에서 공유하는 업무 공통 패키지가 위치한다. (org.kibo.stm.cm) 고객조회, 공통코드 검색 등의 공통 팝업 성 기능을 처리하는 모듈은 해당



작성일자 2008/03/28



공통 업무 명 내에 service, dao 로 패키지를 분할한다. 그외 domain 컴포넌트는 종류 별로 별도의 패키지에 인터페이스와 구현을 나누어 위치시킨다. 시스템 공통 레이어 등 하위 레이어를 사용한다.


5. 업무 공통 레이어 위에 특정 업무 트랜젝션을 처리하는 패키지를 위치시킨다. 업무 분류를 3 Depth 로 구분하고 내부에 Service 컴포넌트 및 관련 DAO 를 위치시킨다. 업무 패키지 내 모든 요소들은 시스템 공통 및 업무 공통 레이어의 패키지들을 사용한다. 그 외 같은 어플리케이션 내 타 업무 패키지의 구성 요소들과 직접적인 관계를 가질 수 도 있으나, 이는 타 업무 패키지와의 종속성을 유발하므로 그다지 바람직 하지 않다. 필요한 부분을 하위 레이어 (시스템 공통 혹은 업무 공통) 패키지로 내리는 것을 반드시 고려하도록 한다.

UI 패키지 구성


1. 하나의 doc root 하에 어플리케이션 단위로 디렉토리를 구분하도록 한다.



작성일자 2008/03/28



2. 각 어플리케이션은 여러 개의 서브시스템 단위로 구성된다. 3. 각 어플리케이션 별로 공통적인 기능을 하는 페이지 및 스크립트를 해당 어플리케이션 밑 common

및 script 디렉토리에 각각 위치한다. 4. 전체 업무에 공통적으로 사용하는 화면(공통 팝업 등)은 stm/cm 밑에 위치한다.5. 전체 어플리케이션에 적용되는 공통 페이지 및 스크립트를 doc root 밑 common 및 script 디렉토리에

위치시킨다.6. 전체 어플리케이션에서 사용하는 이미지는 doc root 밑 image 디렉토리에 위치한다.



작성일자 2008/03/28





EIS 및 OLAP 관련 패키징 아키텍처는 해당 제품의 아키텍처 자료를 참조하도록 하고, 본 장에서는 경영정보 시스템의 아키텍처를 집중적으로 다루도록 한다.

클래스 로더






작성일자 2008/03/28



경영정보 시스템은 위와 같이 표준 J2EE 클래스로더의 구조를 준수하도록 한다.

Application 단위


경영정보 시스템은 업무적으로 분리되지 않는 하나의 독립적인 Application 이므로 하나의 컨테이너에 하나의 EAR 단위로 패키징한다. 엄밀히 이야기 하면, EJB 를 사용하지 않으므로 WAR 로 구성되는 EAR이라 할 수 있다.

위의 그림에서 보는 바와 같이, 독립적인 운용을 위해 경영정보 시스템 관리를 위한 Application 을 별도로 분리하여 구성한다.

웹 서버 또한 하나의 인스턴스에 필요한 화면 전체를 올린다. 단, JSP 는 WAS 에 디플로이되어야 하므로 제외시킨다.

배포 Stage 구조


서비스할 클래스가 스테이징되는 구조는 아래 그림과 같다. 웹 컨테이너만 사용하므로 EJB 클래스로더 구조와 Application 루트 클래스 로더(APP-INF)는 불필요하다.



작성일자 2008/03/28



JSP 파일은 구현 뷰에서의 패키지 구조와 동일하게 업무 별로 분할하여 web root 아래 위치한다. 서비스할 class 들과 관련 설정 파일들은 /WEB-INF/classes 아래 각각의 디렉토리에 위치한다. 각종 사용할 라이브러리들은 /WEB-INF /lib 에 위치한다.





작성일자 2008/03/28



정보계 시스템의 토폴로지는 위의 그림과 같다. 하나의 전용 Web 서버를 가져가고, 2 대의 Ap 서버가 있어서 각각 OLAP 서버(EIS, OLAP)와 경영정보 서버로 사용한다. 그리고 하나의 DB 서버로 DW 를 구성한다.

Web 서버는 기간계와 마찬가지로 접속 클라이언트의 증가에 따라 프로세스를 최대 80 개까지 증가시키도록 한다.

OLAP 서버에는 OLAP 서버와 EIS 서버를 위치하고, 경영정보 서버에는 가용성 제고를 위해 WAS 인스턴스를 2 개 띄우고 앞서 살펴본 패키징 구조대로 어플리케이션을 디플로이 한다. 앞에 위치한 Web서버가 이 중 하나의 인스턴스로 Request 를 보내게 된다.

보고서 출력을 위한 Resport Server 는 정보계에 별도로 구성하지 않고 기간계 AP 서버에 디플로이되는 것을 공통으로 사용하도록 한다.

EIS 에서는 DW 이외에 실시간으로 온라인 데이터를 접근하므로 기간계 서버와의 연결도 구성한다.



작성일자 2008/03/28



6. 사이버 영업점 아키텍처

6.1 개요

사이버 영업점 시스템은 주 사용자 대상이 일반 고객인 대외 서비스이다. 일부 관리자용 서비스는 기금 사용자에 의해 사용된다. 사아버 영업점 어플리케이션에서 사용하는 솔루션 및 호출관계를 실행관점에서 표현하면 다음과 같다.

사이버 영업점 어플리케이션의 기본구조는 일반 JSP 및 Servlet 을 기본적인 기술구조로 가지는 Thin Client 스타일이다. PKI 인증 처리 및 Reporting 툴 사용, 그리고 금융결재원과의 통신을 위해 각기 ActiveX 모듈을 클라이언트에 설치하게 된다. 서버 어플리케이션은 J2EE 기반으로 구축되며, 자체 DB 사용을 비롯하여 기간계 서버, 전자보증 서버 및 대량 메일/SMS DB 와 연동된다.



작성일자 2008/03/28




논리적인 관점에서 본 아키텍처는 정보계의 경영정보 시스템과 동일하다. JSP 기반의 Thin Client 스타일의 구조를 가지며, 상이한 클라이언트를 처리할 필요도 없고 컴포넌트의 재사용 가능성도 높지 않기 때문에 Process Layer 와 Biz Logic Layer 를 명확하게 나누는 서비스 컴포넌트를 제거한 구조를 가진다. 자세한 사항은 정보계 논리 뷰를 참조하도록 한다.



작성일자 2008/03/28




사이버 영업점의 기본 아키텍처는 정보계 경영정보 시스템과 매우 유사하다. 따라서 내용이 동일한 부분은 정보계 아키텍처의 해당 설명을 참조하도록 하고, 여기에서는 상이한 부분에 대해서만 집중적으로 설명하도록 한다.

각 레이어 별로 상세한 구성을 알아보도록 한다.


JSP – Reporting 연계




작성일자 2008/03/28



기간계 시스템과 달리 데이터를 직접 Oz Viewer 에 전달하는 방식이 가능하지 않기 때문에 화면에서 입력된 파라미터 정보(보고서 출력 조건)를 Oz Viewer 에 넘겨주면 이를 Oz 리포트 서버의 자체 쿼리 실행을 통해 데이터를 fetch 해온 후 보고서 양식에 맞게 출력하는 방식만을 사용한다.







작성일자 2008/03/28




웹 컨트롤러 (Front Controller vs. Page Controller)


Request 를 서버로 전달하고 Response 를 반환하는 처리 과정에는 다음과 같이 두가지 방식이 있다. 두 방식 다 기본적으로 MVC (Model – View - Controller) 패턴 기반으로 구성한다.

첫번째 방식은 Page Controller 를 사용하는 것이다. 사용자 Request 는 JSP 로 표현되는 페이지를 통해 서버로 전달된다. 이때 각 페이지 내의 Page Controller 에 Request 시 사용하고자 하는 서비스를 명기한다. Page Controller 는 해당 페이지의 특정 Request 를 처리하는 로직을 가진 서비스 클래스(Behind)로 라우팅 한다. 이를 받은 서비스 클래스는 Request 를 처리한 후 원래의 페이지로 반환하거나, 필요한 경우 다른 페이지로 이동하게 된다.



작성일자 2008/03/28



두번째 방식은 J2EE 웹 프레임워크에서 자주 사용하는 MVC 아키텍처의 방식인 Front Controller 와 Command Pattern 이다. 특정 화면과 별개로 사용자 Request 가 들어오면 이를 Front Controller 인 Servlet에서 일괄적으로 받아 해당 Request 를 실제적으로 처리할 Action 클래스로 라우팅한다. 이 때 파일 혹은 DBMS 에서 Request URL 과 Action 간의 매핑을 참조한다. Action 클래스에서 처리를 마친 후 그 결과를 Randering 할 View 페이지를 지정하여 출력한다.

이 두가지 방식을 비교하면 다음과 같다:

항목 Page Controller Front Controller

설정 페이지 마다 JSP 태그로 설정.XML 파일 혹은 DB 테이블에 설정하며, do 확장자를 가진 URL로 표현.

JSP 의존성 JSP 에 의존함. JSP에 의존하지 않음.

주요 사용 목적하나의 서비스 내에 동일한 유스케이스 내의 여러 기능 구현.

특정 페이지와 상관 없이 어플리케이션에서 전역적으로 사용되는 기능 구현. (로그인 등)

동작 메커니즘코드 Behind 를 이용한 이벤트 방식의 동작.

일반적인 MVC(Model View Controller) 패턴과 Command 패턴에 맞추어 동작.

장점 - 페이지 안에 자신이 사용할 서비스를 명기함으로써 이를 위한 매핑 정보를

- 특정 페이지와 독립적으로 사용할 수 있음.



작성일자 2008/03/28



별도로 설정할 필요가 없이 간결해짐.- Servlet Filter 를 활용한 Chain 방식으로 유연성 있게 처리할 수 있음.- Request 당 하나의 클래스를 만드는 Command 방식보다는 유스케이스 당 하나의 Behind 클래스로 구현할 수 있으므로 개발 및 유지보수가 편리함.

단점- 여러 페이지에 걸쳐서 사용되는 로직을 처리하기 어려움

- Request당 이를 처리하는 서비스 클래스를 생성해야 하므로 클래스 개수가 많아짐- Request와 서비스 클래스 간의 매핑 정보를 관리하는데 오버헤드 발생함

결론: 경영정보 시스템 중 대부분의 기능은 화면에 종속된 서비스라 판단되므로 보다 간결한 구조 하에서의 개발 및 유지보수를 위해 Page Controller 방식을 사용한다 . 일부 페이지에 종속되지 않는 서비스에 한 해 Front Controller 방식을 병행하여 적용하도록 한다 .

웹 컨트롤러 (Request 처리)




작성일자 2008/03/28



위와 같이 두가지 방식을 채택한 상태에서 사용자 Request 를 처리하고 Response 를 내보내는 방식은 위의 그림과 같다. 먼저 사용자 Request 가 들어오면 Front Contoller 혹은 Page Controller 가 이를 받아 원래의 HttpRequest 객체를 포함한 Request 객체로 만든다. 웹컨트롤러가 이를 서비스 클래스 (Action 혹은 Behind 객체)로 넘겨주면 여기서 필요한 정보를 추출하여 요청 사항을 처리한 후 HttpResponse 객체를 포함한 Response 객체로 만들어 다시 웹 컨트롤러에 보내게 된다. 웹 컨트롤러는 이를 해석하여 최종적으로 사용자에게 처리 결과를 출력하게 된다.

웹컨트롤러 (PKI 로그인 및 사용자 세션 처리)


본 시스템은 인터넷 공용망을 통해 기금 외부 사용자에게 제공되는 것으로 인증 보안 강화를 위해 PKI 를 적용한다. 공인 인증서 기반의 로그인이 성공적으로 이루어진 경우 해당 사용자의 기본 정보를 메모리 상에 적재하여 권한 처리 등 통상적인 업무 처리 시에 수시로 참조할 수 있도록 한다.

사용자 정보를 적재하는 방식은 클라이언트 쿠키를 사용하는 방식과 서버 세션을 사용하는 두가지 방식이 있는데, 기간계 시스템과 동일하게 서버 측의 세션을 사용하도록 한다.

먼저 사용자가 로그인 페이지를 통해 공인인증서를 제출하면 PKI Login 처리를 하기 위한 서블릿 필터를 실행하여 공인인증기관 서버와의 통신을 통해 유효성을 확인하도록 한다. 확인이 실패하는 경우 Exception 을 발생하여 접근을 막도록 한다.

로그인이 성공한 후 PKI Login 서블릿 필터는 필요한 사용자 정보를 사이버 영업점 DB 에서 fetch 하여 WAS Session 에 적재하게 된다. 사용자 정보가 서버 측에 로딩되게 되므로 사용자 관련 정보를 클라이언트가 가지고 있을 필요가 없고, 이후의 모든 서버 Request 를 처리할 시 WAS Session ID 만 넘겨주면 해당 Behind 가 서버 Session 에서 필요한 사용자 정보를 추출하여 Request 를 처리하게 된다.



작성일자 2008/03/28



웹컨트롤러 (Exception 처리)


서비스 클래스(Action 혹은 Behind 클래스)에서 발생하는 Exception 은 Runtime Exception 이건 Application Exception 이건 모두 웹컨트롤러에서 catch 를 한다. Catch 된 Exception 은 해당 서비스 클래스에서 정의한 Response 객체로 반환되고, 이를 Rendering 하여 사용자에게 화면을 출력하게 된다.

Exception 의 종류에 따라 Handling 이 달라지는데, Runtime 인 경우는 Error Page(500 에러)로 forward시키고, Application Exception 의 경우는 Popup 으로 에러 내역을 출력한다.

서비스 컴포넌트 내 데이터 전달


앞서 살펴보았듯이 웹 컨트롤러에서는 HttpRequest 및 HttpSession 을 Wrapping 하는 Request 객체를 생성하여 서비스 컴포넌트로 넘겨준다. 사용자의 입력 값은 Request 객체에 들어 있는데, 서비스 컴포넌트 내에서 이를 표현하고 처리하는 방식에는 다음과 같이 두가지 방식이 존재하게 된다.



작성일자 2008/03/28



대안 1 은 별도의 Plain 한 Java Bean 을 Value Object 로 구현하여 Request 객체 내에 있는 해당 데이터를 Plain VO 로 전환하는 방식이다. 그에 비해 대안 2 는 별도의 VO 구현 없이 Java Map 을 활용하여 해당 데이터를 Map 으로 전환하는 방식이다.


구분 장점 단점 비고대안 1 Plain VO 가 직관적인 구조를 가지고 있어

이해하기 쉽다.Strong Typing 이므로 오류발생을 줄일 수 있다. Parameter/Return Type 이 명확하다.VO 와 VO 간의 관계에 대한 표현 및 정합성 체크가 용이하다.향후 Web Services 의 endpoint 로 노출하고자 할 경우 그대로 활용이 가능하다.필요시 로직을 VO 내부에 구현할 수 있다.


대안 2 별도의 VO 개발 비용이 없다.런타임 시 데이터 변환을 속도 저하 없이 자동으로 처리 가능하다.

Generic 한 타입이므로 클래스 만으로는 무슨 데이터를 나타내는지 이해하지 못한다.Strong Typing 이 아니라 항상 key값을 알고 있어야 하므로 오류발생의 여지가 있다.

적용



작성일자 2008/03/28



Parameter/Return Type 이 명확하지 않다.VO 와 VO 간의 관계에 대한 표현 및 정합성 체크가 불가능하다.향후 Web Services 의 endpoint 로 노출하고자 할 경우 별도의 VO 로 전환해야 한다.

결론: 대안 1 이 대안 2 보다 상대적으로 장점이 많은 것은 사실이나 , 현실적으로 VO 를 별도로 개발 및 유지보수하는 데는 많은 노력이 동반된다 . 따라서 본 아키텍처에서는 대안 2 를 사용하도록 한다 . VO 에 별도의 로직을 넣어야 할 필요가 있는 경우에는 해당 클래스를 별도 구현하여 컴포넌트 내에서 활용하도록 한다 .






작성일자 2008/03/28



웹 컨트롤러에 의해 실행되는 서비스 컴포넌트는 메소드 하나가 사용자 입장에서의 end-to-end transaction을 보장하게 된다. 즉, 실행되는 메소드의 실행 과정에 발생하는 모든 트랜젝션 자원들은 하나의 트랜젝션 Context 에 묶인다. 실행에 참여하는 트랜젝션 리소스 중 하나라도 실패하게 되면 전제가 Roll-back 하게 되고, 모두 성공해야만 비로서 Commit 된다. (Multi data source 혹은 리모트 EJB 호출의 경우 XA Driver 를 사용해야 함)

이렇게 실행되는 서비스 컴포넌트는 자체적으로 Use Case 에 종속적인 비즈니스 로직을 담고 있으며, 그 수행 과정에서 여러 종류의 컴포넌트를 활용하게 된다. 공통적이고 재사용 가능한 로직을 한 단위로 묶은 Domain 컴포넌트, 데이터 접근을 담당하는 DAO 컴포넌트, 그리고 타 시스템 연동을 담당하는 Integration 컴포넌트가 그것이다. 서비스 컴포넌트는 이러한 컴포넌트들을 모두 Component Factory 를 통해 접근한다.

각 컴포넌트간의 전송 파라미터는 프레임워크에서 제공하는 VO 생성기를 통해 Map 형태로 전송한다. 인테그레이션 계층에서 VO 는 DBIO 혹은 Proxy 에서 이해할 수 있는 형태로 변환이 되며, 이러한 변환 로직은 DAO 와 Interface 컴포넌트 내부에서 처리하도록 하여 비즈니스 로직과 격리한다.

서비스 컴포넌트는 다른 서비스 컴포넌트를 직접 사용할 수 없다. 공통적으로 사용할 로직이 있는 경우 Dmain 컴포넌트로 만들어 같이 사용하도록 한다.

Domain 컴포넌트 적용 요구품질속성: RQ-STM-SA-1-13



작성일자 2008/03/28



서비스 컴포넌트에 의해 실행되는 Domain 컴포넌트는 시스템 혹은 업무 레벨에서의 공통 로직 및 재사용 가능 로직을 담고 있는 컴포넌트이다. 따라서 유스케이스 독립적이며, 여러 유스케이스에 참여하여 담당하는 로직을 처리하는 역할을 한다.



Domain 컴포넌트는 필요한 경우 다른 Domain 컴포넌트를 호출할 수 있다. 이때도 마찬가지로 Component Factory 를 통해 호출하도록 한다.


Dao 컴포넌트


Dao 컴포넌트는 서비스 컴포넌트 나 Domain 컴포넌트에 의해 호출되며, Value Object 와 Database 간의 연동을 담당한다. 본 아키텍처에서는 Apache 의 ORM (Object Relation Mapping) Framework 인 iBatis 2.3(http://ibatis.apache.org/)을 활용하여 DAO 를 구현하며, 이러한 데이터 저장 로직을 비즈니스 로직으로부터 엄격하게 구분하도록 한다.


하나의 공통 컴포넌트로 DAO 를 만든 후 이 것이 모든 Input/Output VO 와 Dbio VO 간의 데이터 매핑을 일괄적으로 처리하도록 한다. 즉, 업무 별로 별도의 DAO 를 생성할 필요가 없으므로 개발 생산성을 향상할 수 있다.



작성일자 2008/03/28



기간계 AP 서버 연계


사이버 영업점에서 기간계 시스템으로 업무 실행을 요청하는 경우가 있는데, 이때 조회성이 아닌 CUD 가 동반된 경우에는 반드시 2PC (Two Phase Commit) 처리가 되어야 한다. 사이버 영업점 어플리케이션으로 트랜잭션이 동반된 Request 가 전송되면 JTA (Java Trasaction Architecture)에 의해 WAS 레벨에서 User Transaction 이 시작된다. 이러한 Trasaction Context 하에서 Action 혹은 Behind 는 동작을 하게 되고, 기간계 호출을 내부적으로 처리하는 Biz Delegate 컴포넌트를 호출한다. (Business Delegate Pattern 적용)

Biz Delegate 컴포넌트는 EJB stub 을 통해 rmi/iiop 프로토콜로 기간계에 디플로이되어 있는 Session EJB 를 호출한다. Session EJB 는 Stateless 로 관리하며, Transaction Attribute 는 Supports 로 설정하여 사이버 영업점에서 전달된 Transaction Context 에 참여되게 한다. 해당 Session Bean 은 실제 업무를 처리할 기간계의 User Transaction 컴포넌트를 실행한다. 이때 기간계의 DB Connection 은 글로벌 XA 로 설정되어야 한다.



작성일자 2008/03/28



전자보증 시스템 연계 (Outbound)


본 프로젝트에서는 사이버 영업점 어플리케이션에서 전자보증 시스템을 통해 대외 기관을 호출하는 것을 Outbound 연계라 한다. 이러한 Outbound 연계를 위해서 본 시스템은 전자보증 연계를 위한 공통 인터페이스 컴포넌트를 사용하도록 한다. Action 혹은 Behind 클래스에서 대외계 연동 시 본 공통 컴포넌트를 호출하는데, 이때 위의 그림에서와 같이 다음과 같은 순서로 처리가 된다:

1. 전자보증 컴포넌트 호출2. log API 를 통해 전송 내역을 별도 DB 테이블에 저장한다. (전문순번 생성)3. 사이버 영업점에서 사용하는 Value Object 를 전자보증 시스템과의 통신을 위한 XML

로 자동 변환4. 연계용 서버 페이지를 통해 XML 전송5. 응답 내역을 Value Object 로 자동 변환; 이때 로그 테이블에서 생성한 전문순번 반환6. 신규생성된 전문순번을 참조 키로 업무 컴포넌트에서 관련 데이터를 저장

전자보증 전송 전에 전문순번을 채번하여 사용하는 것도 가능하다.



작성일자 2008/03/28



메일/SMS 시스템 연계


기간계 방식과 동일하다. Behind 혹은 Action 에서 대량 메일/SMS 공통 컴포넌트를 호출하도록 한다.



작성일자 2008/03/28



메일/SMS 서버와의 연계는 해당 시스템의 DB 의 인터페이스 테이블에 발송 데이터를 저장하는 방식으로 한다. 메일/SMS 서버는 해당 테이블을 모니터링하면서 수시로 요청된 내역을 발송한다.

본 아키텍처에서는 해당 인터페이스 테이블에 발송 데이터를 저장하는 공통 컴포넌트를 사용한다. 즉, 온라인의 경우 User Trnasaction 컴포넌트에서, 배치의 경우 Step 클래스에서 각각 Mail 컴포넌트와 SMS 컴포넌트를 호출하여 발송을 요청한다.

6.3.5보안 부분


Authentication




작성일자 2008/03/28



기금 내부 사용자 외 일반 고객 등 외부 사용자의 경우는 SSO 를 적용하지 않는 대신 PKI 를 도입하여 공인된 사용자만이 시스템에 접근할 수 있도록 한다. 사용자는 공인 인증기관에서 인증서를 발급 받은 후 시스템에 초기 접근할 때 인증서를 제출하도록 한다. 제출된 인증서는 시스템 내 등록기관에서 상태 확인을 한 후 접근 허용 여부를 결정하게 된다.

서비스 실행 권한


사용자의 서비스 실행 권한은 매 Request 마다 확인되는 것으로 특정 서비스 컴포넌트에 대한 Request 가 도착하면 웹 컨트롤러에 전달되기 전에 권한을 확인하는 Servlet Filter 가 이를 가로채게 된다. 권한 확인을 위해 Filter 는 세션에서 현재 사용자 정보를 가져오고, 이를 Security 컴포넌트를 통해 해당 서비스의 호출이 본 사용자에게 허용되는지를 확인한다.

허용이 되는 경우에는 예정대로 서비스 컴포넌트를 실행하게 되고, 허용이 안되는 경우에는 SecurityException 을 발생시킨 후 해당 Request 를 종료시킨다.

UI 권한 처리



작성일자 2008/03/28




특정 UI 내에서의 권한은 Page 가 로딩 될때마다 체크된다. Tag Library 를 통해 권한 통제 대상이 되는 UI 컨트롤을 지정하면 해당 페이지를 로딩할 때 마다 현재 사용자의 권한을 체크하고, 이에 따른 해당 컨트롤의 허용 여부를 결정하게 된다. 이러한 권한 별 UI 컨트롤 권한 설정은 별도의 관리 프로그램에서 이루어지며, 이러한 정의에 따라 해당 UI 컨트롤이 현재 사용자에게 접근 가능한지가 동적으로 결정된다.

이러한 UI 컨트롤에 대한 동적인 권한 처리를 위해 아래 그림과 같은 방안을 사용한다:

화면에서 권한 처리 대상인 UI 컨트롤을 Custom Tag Library 를 통해 지정하면 해당 페이지를 로딩하는 시점에서 서버에서 서버 세션에 존재하는 현재 사용자의 권한 정보를 기반으로 해당 UI 컨트롤에 대한 접근 권한 여부를 Security 를 담당하는 컴포넌트를 통해 체크한다. 그 결과에 따라 해당 UI 컨트롤을 페이지에 표시할 지 여부를 판단하여 권한을 처리한다.

이러한 권한 판단을 하는 Security 컴포넌트는 권한 관리 모듈에서 정의한 내역에 따라 이를 수행한다.

6.3.6기타

Logging

로그는 Log4J 의 Logger 를 사용한다. 아래 표와 같이 6 가지 레벨의 로그를 사용하여 각각의 Event 시에 로그를 남기도록 한다. 로그 레벨 별로 Logging 내역이 달라질 수 있으며, 저장하는 방식 및 위치도 달라진다.

level Event 내용 보관 처리 방안fatal SystemException발생시 Exception 내용,

Timestamp File 자동 처리



File 서비스 에서 throw 하면 자동 처리



작성일자 2008/03/28



trace 서비스 접근 시 사용자, IP, 실행서비스, Timestamp

File 자동 처리

warn TBD File 자동 처리info 트랜젝션

commit/rollback 내역사용자, 호출 내역, Timestamp

File 자동 처리필요 시 개발자 개별 처리

debug - 개발 시 필요에 따라 (각 Component 별 Logger 정의)- 실행 SQL- Request/Response 내역

개발자 정의 내용실행 SQLIO 내역

File 개발자 개별 처리자동 처리

위와 같은 로그 레벨은 다음과 같이 File 에 저장하도록 한다.

Logger 는 해당 이벤트 발생 시 File Appender 를 사용하여 아래와 같은 내역을 로그 레벨 별로 해당 파일에 저장하도록 한다. 파일의 단위는 로그레벨 별로 구분하도록 한다.

내역 설명타임스탬프실행 클래스명로그레벨 Fatal/Error/Warn/Info/Debug메시지 로그 내용





DBMS 에 오라클 Row Num 쿼리 방식을 적용하는데, 이에 필요한 파라미터인 시작 Row Num 과 Page Size 정보를 페이지네이션 처리가 필요한 트랜젝션마다 Client 로부터 넘겨 받아야 한다. 웹 브라우저에서 Request 를 전송할 때 해당 정보를 파라미터의 형태로 보낸다.

이 정보는 서비스 컴포넌트를 거쳐 검색 조건과 함께 Dao 컴포넌트에게 전달되고, 여기서 필요한 정보를 얻어 DB 를 처리한다. 데이터가 fetch 되면 다시 결과 값을 돌려주는 PageList 를 생성하고 해당 Page 의 결과 값과 함께 total size, 현재 page no, list size, totoal page 의 정보를 담게 된다. 본 내용은 Custom Tag Library 에 의해 JSP 에 출력된다.



작성일자 2008/03/28



공통코드 로딩 및 동기화


기간계와는 달리 경영정보 시스템은 Thin Client 이기 때문에 런타임 시 클라이언트 자원을 사용하지 않고 전적으로 서버 자원에 공통코드를 위치시킨다.



작성일자 2008/03/28



먼저 서버에 어플리케이션이 디플로이될 때 Code 컴포넌트를 통해 모든 Code 정보를 메모리에 적재하도록 한다. 클라이언트가 코드 데이터를 필요로 하는 시점에 서버로부터 해당 코드 데이터를 Tag Libaray 를 통해 가져와 사용한다.

공통코드 관리 모듈을 통해 코드에 변경이 일어나면 서버의 Code 컴포넌트를 Refresh 하여 변경사항이 서버에 반영되도록 한다.




이러한 문제 때문에 가능하면 사용자 환경에 직접 설치되어 작동하는 프로그램은 최소화하는 것이 기본적인 원칙이지만, Grid 같이 보다 강력한 UI 처리를 위해서는 불가피하게 사용해야 하는 경우가 있다. 본 시스템에서는 다음과 같이 반드시 필요한 Client 모듈만을 사용하도록 한다:

프로그램 설명VSFlexGrid 복잡한 Grid UI Control 을 위해 일부 화면에서 사용한다.

관련 요구품질속성: RQ-STM-SA-1-09Oz Viewer 보고서 형태로 데이터를 조회, 출력을 하기 위한 도구로서 Oz Report 를

적용하기 때문에 반드시 사용해야 한다. 관련 요구품질 속성: RQ-STM-SA-1-18

PKI Client 인증서 기반 로그인을 적용하기 때문에 사용한다. 관련 요구품질 속성: RQ-STM-SA-1-20

금결원 Client TBD



작성일자 2008/03/28




사이버 영업점 시스템은 Web Server 와 WAS 위에서 구동하게 된다. Web Server 상에는 WAS 서비스가 필요없는 정적인 구현 요소들이 탑재된다. SSO 와 EP 에서 사용하는 HTML 화면 및 JavaScript library 등을 배치한다.

WAS 서버는 분산 어플리케이션이 아니므로 Web Container 만을 사용하도록 디플로이되어 동작한다.

Application 패키지 구성


1. 전체 시스템 공통 Prefix 는 기간계와 마찬가지로 org.kibo 로 한다.2. 전체 시스템에서 공통적으로 사용하는 시스템 공통 패키지를 구성하여 모든 어플리케이션에서

접근 가능하도록 한다. (org.kibo.stm.fw). 여기에는 공통 컴포넌트와 Base Class 및 각종 Utility 를 위치시킨다.

3. 시스템 공통 레이어 위에는 전체 시스템에서 공유하는 업무 공통 패키지가 위치한다. (org.kibo.stm.cm) 고객조회, 공통코드 검색 등의 공통 팝업 성 기능을 처리하는 모듈은 해당 공통 업무 명 내에 service, dao 로 패키지를 분할한다. 그외 domain 컴포넌트는 종류 별로 별도의 패키지에 인터페이스와 구현을 나누어 위치시킨다. 시스템 공통 레이어 등 하위 레이어를 사용한다.



작성일자 2008/03/28




5. 업무 공통 레이어 위에 특정 업무 트랜젝션을 처리하는 패키지를 위치시킨다. 업무 분류를 3 Depth로 구분하고 내부에 Service 컴포넌트 및 관련 DAO 를 위치시킨다. 업무 패키지 내 모든 요소들은 시스템 공통 및 업무 공통 레이어의 패키지들을 사용한다. 그 외 같은 어플리케이션 내 타 업무 패키지의 구성 요소들과 직접적인 관계를 가질 수 도 있으나, 이는 타 업무 패키지와의 종속성을 유발하므로 그다지 바람직 하지 않다. 필요한 부분을 하위 레이어 (시스템 공통 혹은 업무 공통) 패키지로 내리는 것을 반드시 고려하도록 한다.

UI 패키지 구성


1. 하나의 doc root 하에 어플리케이션 단위로 디렉토리를 구분하도록 한다.2. 각 어플리케이션은 여러 개의 서브시스템 단위로 구성된다.



작성일자 2008/03/28



3. 각 어플리케이션 별로 공통적인 기능을 하는 페이지 및 스크립트를 해당 어플리케이션 밑 common 및 script 디렉토리에 각각 위치한다.

4. 전체 업무에 공통적으로 사용하는 화면(공통 팝업 등)은 stm/cm 밑에 위치한다.5. 전체 어플리케이션에 적용되는 공통 페이지 및 스크립트를 doc root 밑 common 및 script 디렉토리에

위치시킨다.6. 전체 어플리케이션에서 사용하는 이미지는 doc root 밑 image 디렉토리에 위치한다.



작성일자 2008/03/28





클래스 로더




사이버 영업점 시스템은 위와 같이 표준 J2EE 클래스로더의 구조를 준수하도록 한다.



작성일자 2008/03/28



Application 단위


사이버영업점 시스템은 업무적으로 분리되지 않는 하나의 독립적인 Application 이므로 하나의 컨테이너에 하나의 EAR 단위로 패키징한다. 엄밀히 이야기 하면, EJB 를 사용하지 않으므로 WAR 로 구성되는 EAR 이라 할 수 있다.

위의 그림에서 보는 바와 같이, 사이버 영업점 APP 를 하나의 어플리케이션으로 배포하고, 이와는 독립적인 운용을 위해 사이버 영업점 시스템 관리를 위한 Application 을 별도로 분리하여 구성한다. 또한 리포트 서비스를 위해 별도의 WAS 에 Report App 를 운영하여 Report 업무로 인한 온라인 서비스의 영향을 최소화하고자 함이다.

웹 서버 또한 하나의 인스턴스에 필요한 화면 전체를 올린다. 단, JSP 는 WAS 에 디플로이되어야 하므로 제외시킨다.

배포 Stage 구조


서비스할 클래스가 스테이징되는 구조는 아래 그림과 같다. 웹 컨테이너만 사용하므로 EJB 클래스로더 구조와 Application 루트 클래스 로더(APP-INF)는 불필요하다.



작성일자 2008/03/28



JSP 파일은 구현 뷰에서의 패키지 구조와 동일하게 업무 별로 분할하여 web root 아래 위치한다. 서비스할 class 들과 관련 설정 파일들은 /WEB-INF/classes 아래 각각의 디렉토리에 위치한다. 각종 사용할 라이브러리들은 /WEB-INF /lib 에 위치한다.



사이버 영업점 시스템의 토폴로지는 아래 그림과 같다. Web 서버와 WAS, 그리고 DBMS 를 하나의 노드에 배치한다. 좀 더 신뢰성 있는 서비스를 하기 위해 Web 서버 인스턴스를 두 개로 운영하고, 사이버 영업점 APP 가 존재하는 WAS 도 두 개의 인스턴스로 운영한다. Report 서버는 별도 WAS 인스턴스에 배치한다.


PMC · Web view차세대 정보시스템 구축을 위한 아키텍처 결정의 기본요소로는...

Documents

Transcript of PMC · Web view차세대 정보시스템 구축을 위한 아키텍처 결정의 기본요소로는...