11. 소프트웨어 아키텍처 뷰 설계 예제 명지대학교 융합소프트웨어학부 김정호 교수

포털 시스템 개요 - 예제 목적 이 문서는 소프트웨어 아키텍처를 수립하는 뷰에 대한 예제를 제공하는데 그 목적이 있다. 전형적인 소프트웨어 시스템 (Portal, Channel)과 관련된 소프트웨어 아키텍처 예제를 제공함으로써 소프트웨어 아키텍팅을 쉽게 할 수 있게 한다. 여기서 제시하는 전형적인 시스템의 소프트웨어 아키텍처 뷰들은 일반적인 경우를 소프트웨어 아키텍처를 표현한 것으로 프로젝트 특성에 맞게 수정해서 사용하는 것이 좋다. 시스템 별 영역

포털 시스템 개요 - 예제 3. 포탈 시스템 소프트웨어 아키텍처 수립 방법 프로젝트에 따라서 소프트웨어 아키텍처 설계하는 방법은 다양하다. 포탈 시스템을 구축한다고 하면 제안단계나 고객 협의 과정에서 포털 솔루션을 선정하고 그 솔루션에서 제공하는 서비스를 별도로 분석한 후에 소프트웨어 아키텍처를 작성하는 경우가 있다. 소프트웨어 아키텍트가 포탈 시스템의 아키텍처를 설계하면서 우선적으로 필요한 기능을 정의(모듈 뷰를 통해)하고 이와 관련된 런타임 뷰를 작성하여 그 기능을 명확하게 처리할 수 있는 방법을 설계한다. 소프트웨어 아키텍처를 작성한 이후에 이 아키텍처를 가장 잘 처리할 수 있는 포탈 솔루션을 선정한다. 솔루션을 도입하지 않고 In-house로 개발할 수도 있지만 복잡한 기능을 개발하는 것보다는 개발하려고 하는 시스템이 원하는 기능을 가장 잘 도입할 수 있는 포탈 솔루션을 선택하는 것이 좋다.

포털 시스템 아키텍처 - 예제 Context Diagram - Frontend Portal System은 다양한 사용자의 채널을 하나로 통합하여 주는 역할을 한다. 이 때 사용자의 환경을 잘 이해해야 할 필요가 있다. 이 시점에 필요한 것이 사용자 관점의 context diagram이다. 명확한 사용자와 함께 포털로 묶일 시스템을 같이 정의하면 보는 사람이 포탈 시스템을 이해하기가 편하다. 아키텍처 Description 사용자는 크게 내/외부 사용자(직원)과 서비스 사용자(유/무선)으로 나뉜다. 내부 사용자(직원)은 인증과 관련된 절차가 편리하지만 외부에서 접근하는 사용자(직원, 서비스 가입자 모두)는 공인인증 방식의 인증을 사용한다. . 무선 가입자를 위한 포탈 시스템을 위해 별도의 무선 사용자 포탈 화면 개발이 필요하다. 포탈 시스템과 연계되는 시스템은 KMS, Mail등의 기존 시스템과 새로 개발된 기간계, 정보계 시스템이 포함된다. Back-end로 연계될 시스템은 추후 변경이 가능하므로 변경을 고려한 아키텍처 설계가 필요하다.

포털 시스템 아키텍처 - 예제 2. Context Diagram – Backend 여기서는 생략되었지만 연동될 시스템의 사양에 대해서 자세한 정보(연동 프로토콜, 서비스 제공 타입(웹 UI, 별도의 Client 등), 시스템 OS 등)을 노트 수준으로 적는 것도 유용하다. 아키텍처 Description 포털 시스템으로 연계될 Back-end 시스템은 크게 현재 제공되고 있는 서비스 시스템과 신규 개발된 시스템과 연계될 시스템으로 나뉠 수 있다. 현행 업무 시스템은 본사 업무 담당 시스템, KMS, E-mail, CTI, Intranet, Message server 등이고 향후 연동될 시스템은 신규로 개발될 시스템인 CRM, BPM, WM, 리스크 관리 시스템, 리서치 업무 등이다. 향후 포탈 시스템 아키텍처를 구성할 경우 위의 시스템의 특성을 충분히 파악한 후에 연계 Portlet을 작성하도록 한다. 5

포털 시스템 아키텍처 - 예제 3. Module View – 상위 수준의 Logical View 포탈 시스템의 상위 수준의 모듈 뷰는 기능 분할 위주의 그림이다. 보다 상세한 application 로직(Portlet의 관계, 권한 관리 체계)을 담당하는 모듈 뷰를 작성할 수 있으나 일반적으로 이 부분은 포탈 시스템(혹은 솔루션 담당자)에서 설계하므로 SA 입장에서의 상위 수준의 모듈 뷰만을 작성한다. 아키텍처 Description 포탈 시스템은 크게 통합/개인화 영역과 인증/권한 관리 영역으로 구분된다. 통합/개인화 영역은 다시 UI 계층, Application 계층, Data 계층으로 구분이 된다. UI 계층은 개인화 서비스와 포털 구성과 관련된 서비스를 제공해야 하고 Application 계층에서는 사용자 인증 및 권한 관리 부분, Workflow 부분, 포탈 관리와 관련된 부분으로 나뉜다. Data 계층은 포털과 관련된 개인 정보나 연계되는 시스템 정보를 가지게 된다. 인증/권한 관리 영역은 암호화, 통합 인증(SSO), 권한 관리 서비스를 제공하고 이들 서비스를 위한 인증, 권한 관리 데이터를 유지하는 LDAP으로 구성된다. 6

포털 시스템 아키텍처 - 예제 4. Runtime View – 전체 구조도 7

포털 시스템 아키텍처 - 예제 Runtime View – 전체 구조도 설명 런타임 구조와 관련된 아키텍처 Description을 간단히 기술할 수 없으므로 다른 사례를 직접 참조하는 것이 좋다. 간략한 설명은 다음장의 요소 설명과 behavior 아키텍처에서 설명하기로 한다.

포털 시스템 아키텍처 - 예제 Runtime View 요소 설명 및 모듈 뷰와의 관계 모듈 뷰 요소 관련 런타임 뷰 요소 설명 개인화 서비스 Personalization 개인화된 사용자 환경을 지원하기 위한 개인화 정보관리 Portlet 포탈 기반의 화면 연동을 위한 기능 제공 Portal 구성 UI Processor 화면 처리 프로세서 Workplace 사용자 개인화된 workplace 제공 User Management SSO Agent 인증 및 권한 기능 서버와 연동하기 위한 Agent Workflow Management 없음 Portal Management Portal Server Management 사용자 세션 정보를 생성/유지하며 프로토콜 변환 및 워크로드를 관리 서비스 Listner 사용자 요청을 대기하는 역할을 수행함 Service Request Back-end 시스템과의 연동을 위한 서비스 제공 User 데이터/시스템 테이터 Portal DB(사용자 정보, Portal Meta 정보) Portal 관련 데이터를 별도로 관리하는 DBMS 통합 인증(SSO) SSO/Policy Management Server 인증 및 권한 관리를 관리하고 워크로드를 관리하는 기능을 제공 SSO, 권한관리 사용자 요청을 대기하고 역할을 수행함 인증(CA, RA) 서버 통합 인증과 관련된 기능(SSO, 인증서 인증기관 연동, 인증서 등록 기관 연동 등)을 제공 권한 관리 권한 관리 서버 사용자 권한 관리 정책서버 인증 권한 정보 LDAP(인증 정보, 권한 정보) 사용자 인증 및 권한 관리 정보 저장소 역할로서 대규모 Access에 적합한 LDAP을 주로 사용 암호화

포털 시스템 아키텍처 - 예제 5. Runtime View – 로그인 (내부 사용자) 전체 runtime view는 전체 시스템을 이해하는데 사용하는 것이라면 이것은 특정 상태에 대한 snapshot으로 특정 상태를 이해하는데 도움이 된다. 아키텍처 Description 내부 사용자가 처음 포탈 시스템으로 Access하면 포털 시스템은 초기 로그인 화면을 제공하고 사용자는 로그인 정보를 포털 시스템에 전송한다. 로그인 정보를 받은 포털 시스템의 통합 개인화 영역은 SSO Agent를 통해 로그인 정보를 보내고 인증과 인증 성공 후 권한 정보를 요청한다. 인증 요청을 받은 인증 영역의 서비스 Listener는 인증 서버에 인증을 요청한다. 인증 서버는 내부 User 정보(LDAP 내부)에 인증 정보를 요청하여 인증을 진행한다. 이 성공으로 끝나면 SSO/Policy server Manager는 권한 관리 서버에 권한 정보를 요청한다. 권한 정보를 cookie에 담은 인증 성공 메시지가 내부 사용자에게 전달된다. 10

포털 시스템 아키텍처 - 예제 6. Runtime View – 로그인 (외부 사용자) 외부인의 로그인 흐름은 내부 사용자와 약간의 차이가 있다. 이 부분을 내부 사용자 로그인 프로세스와 비교하여 아키텍처를 작성하면 로그인 프로세스 구분에 대한 명확한 지침이 마련될 수 있다. 아키텍처 Description 외부 사용자가 처음 포탈 시스템으로 Access하면 포털 시스템은 초기 로그인 화면을 제공하고 사용자는 로그인 정보를 포털 시스템에 전송한다. 로그인 정보를 받은 포털 시스템의 통합 개인화 영역은 SSO Agent를 통해 로그인 정보를 보내고 인증과 인증 성공 후 권한 정보를 요청한다. 인증 요청을 받은 인증 영역의 서비스 Listener는 인증 서버에 인증을 요청한다. 인증 서버는 외부 사용자임으로 HTTP 헤더를 통해서 인증하고 외부 인증 센터에 인증을 진행한다. 이 성공으로 끝나면 SSO/Policy server Manager는 권한 관리 서버에 권한 정보를 요청한다. 권한 정보를 cookie에 담은 인증 성공 메시지가 내부 사용자에게 전달된다. 11

포털 시스템 아키텍처 - 예제 7. Runtime View – Portal 화면 호출 아키텍처 Description 사용자 인증이 완료되면 포탈 시스템으로 Access하면 포털 시스템은 초기 로그인 화면을 제공하고 사용자는 로그인 정보를 포털 시스템에 전송한다. 로그인 정보를 받은 포털 시스템의 통합 개인화 영역은 SSO Agent를 통해 로그인 정보를 보내고 인증과 인증 성공 후 권한 정보를 요청한다. 인증 요청을 받은 인증 영역의 서비스 Listener는 인증 서버에 인증을 요청한다. 인증 서버는 외부 사용자임으로 HTTP 헤더를 통해서 인증하고 외부 인증 센터에 인증을 진행한다. 이 성공으로 끝나면 SSO/Policy server Manager는 권한 관리 서버에 권한 정보를 요청한다. 권한 정보를 cookie에 담은 인증 성공 메시지가 내부 사용자에게 전달된다. 12

포털 시스템 아키텍처 - 예제 8. Runtime View – 로그인(내부 사용자) Behavior 타입 이와 같은 형태도 아키텍처의 일부이며 일반적으로 Architecture Behavior View이라고 한다. 13

포털 시스템 아키텍처 - 예제 9. Allocation View 일반적으로 하드웨어에 porting된 OS, WAS, Portal Server 등의 계층구조로 표현한다. 포탈 시스템은 크게 포털 서버와 SSO/권한 관리 서버로 구분하여 작성된다. 아키텍처 Description 외부 사용자가 처음 포탈 시스템으로 Access하면 포털 시스템은 초기 로그인 화면을 제공하고 사용자는 로그인 정보를 포털 시스템에 전송한다. 로그인 정보를 받은 포털 시스템의 통합 개인화 영역은 SSO Agent를 통해 로그인 정보를 보내고 인증과 인증 성공 후 권한 정보를 요청한다. 인증 요청을 받은 인증 영역의 서비스 Listener는 인증 서버에 인증을 요청한다. 인증 서버는 외부 사용자임으로 HTTP 헤더를 통해서 인증하고 외부 인증 센터에 인증을 진행한다. 이 성공으로 끝나면 SSO/Policy server Manager는 권한 관리 서버에 권한 정보를 요청한다. 권한 정보를 cookie에 담은 인증 성공 메시지가 내부 사용자에게 전달된다. 14

소프트웨어 아키텍처 뷰타입 종류 4+1 view

소프트웨어 아키텍처 뷰타입 종류 4 view

Question ?