Pattern-Oriented Software Architecture 2008.04.07 안준석 브로커 패턴 거인의 어깨 위에서 Pattern-Oriented Software Architecture 2008.04.07 안준석

개요 POSA 1 의 아키텍처 패턴인 브로커를 공부한다. 여러 온라인 게임을 통합하는 예를 통해 브로커 개념을 이해하도록 한다. ‘거인의 어깨 위에서’ 라는 뉴턴의 말을 메타포로 패턴의 유용성을 살펴본다.

순서 인증서버 통합 프로젝트 거인의 어깨 위에서 Broker 패턴 소개 세상이 변하고 있다

인증서버 통합 프로젝트 가상 통합 온라인 게임

상황 국가 사업(?) 신규 통합 게임 온라인게임 축제! 모든 게임 캐릭터들을 수용하는 게임을 개발 하라! 킹오브파이터 와 비슷한 컨셉 자신이 즐기는 특정 온라인 게임 캐릭터로 별도의 회원 가입 없이 즐길 수 있는 온라인 게임 과금과 인증은 각 게임 회사에서 함

통합 온라인 게임 모티브

구현 시나리오 일단 뮤, 리니지, 와우 유저 대상. 자기가 즐기는 게임의 캐릭터로 플레이 클라이언트, 서버는 구현이 완료 된 상태 다른 게임들도 수시로 참여할 수 있다.

나만 봐!!!! 통합 인증 서버 구현 목표 유저 로그인과 과금 통합 시스템 구축 다양한 게임의 인증 정보를 처리 유연하고 확장성 있는 구조 설계

기본 연동 구조 클라이언트 접속 게임 선택 캐릭터 선택 해당 게임 서비스에서 인증 해당 게임 서비스에서 과금 게임 시작 다른 게임의 캐릭터들 바글바글

구현 1 DB 복사 보안 문제 및 이권 문제 과금은 어떻게? 하드코어 해결법

구현 2 클라이언트가 각 게임 인증 서비스 접속 클라이언트가 여러 연결을 책임짐 보안 이슈 발생 유연성이 떨어짐 뮤 인증 리니지인증 와우인증 클라이언트가 각 게임 인증 서비스 접속 클라이언트가 여러 연결을 책임짐 보안 이슈 발생 유연성이 떨어짐

구현 3 담당자들이 협조를 잘 해줄까? 디버깅은? 분산 시스템 디버깅? OTL 통합 인증 처리 서버를 만듬 클라이언트 통합 인증서버 통합 인증 처리 서버를 만듬 통합 인증 서버가 각 게임의 인증 서비스들과 연동 담당자들이 협조를 잘 해줄까? 디버깅은? 분산 시스템 디버깅? OTL

통합 인증 서버 구조 클라이언트 통합 인증서버 문제점 서로 다른 프로토콜 구조 -서로 다른 OS 플랫폼 MU 클라이언트 통합 인증서버 리니지 문제점 서로 다른 프로토콜 구조 -서로 다른 OS 플랫폼 -서로 다른 Machine WOW

벌써 마무리? 통합 인증 서버 Plus? Proxy 클라이언트 Proxy 통합 인증서버 Proxy Proxy 위치 투명성 제공 MU Object로 통신 위치 투명성 제공 벌써 마무리? Proxy 클라이언트 Proxy 통합 인증서버 리니지 Proxy WOW 브로커 Proxy

거인의 어깨 위에서 브로커 메시징 방식의 변화 분산 객체 시스템

뉴턴 아저씨 한 말씀 "만일 내가 다른 사람보다 조금이라도 더 멀리 내다 볼 수 있었다고 한다면 그것은 나에게 거인들의 어깨가 있었기 때문이다. "

브로커 패턴 transfer message transfer message Client-side Proxy Broker pack_data uppack_data send_request return Broker main_event_loop update_repository register_service acknowledgment find_server Find_client Forward_request Forward_response Server-side Proxy pack_data uppack_data call_service send_response calls uses API calls uses API calls Client call_server start_task use_Broker_API Bridge pack_data uppack_data forward_message transmit_message Server initialize enter_main_loop run_service use_Broker_API

통합 인증 서버 Plus Broker Proxy 클라이언트 Proxy 통합 인증서버 Proxy Proxy 위치 투명성 제공 MU Object로 통신 위치 투명성 제공 Proxy 클라이언트 Proxy 통합 인증서버 리니지 Proxy WOW 브로커 Proxy

거인의 어깨에 오르면서! 메시징 방식의 변화 분산 객체 시스템이란?

메시징 방식의 변화 메시지 교환 RPC Object 송수신 – 분산 객체 시스템

분산 객체 시스템이란? “즉, 원격에 있는 객체들을 내 컴퓨터에 있는 것처럼 사용하는 것! “ 브로커의 소셜 포지션 ORB(Object Request Broker) Transaction Processing Coordinator CORBA, COM+

Broker 구조 작동 시나리오 구현 결론

순서 구조 시나리오 구현 결론

브로커 패턴 transfer message transfer message Client-side Proxy Broker pack_data uppack_data send_request return Broker main_event_loop update_repository register_service acknowledgment find_server Find_client Forward_request Forward_response Server-side Proxy pack_data uppack_data call_service send_response calls uses API calls uses API calls Client call_server start_task use_Broker_API Bridge pack_data uppack_data forward_message transmit_message Server initialize enter_main_loop run_service use_Broker_API

Broker 구성요소 Client Server Broker Client-Side Proxy Server-Side Proxy Bridge

Client 기능 최소한 1 가지 서비스 Server에 접근한다. Broker에게 요청을 전달한다. Client는 Access 할 Server의 위치를 알 필요가 없다. 역할 정의 유저 사용 기능 구현 Client-Proxy를 통해 Server에 요청 Client call_server start_task use_Broker_API

Server 기능 Server 초기화 부분 초기화 initialize() Broker에 서비스 등록 use_Broker_API (register_service) 처리 부분 Part 이벤트 루프 작동 run_service enter_main_loop run_service() { … enter_main_loop() } Server initialize enter_main_loop run_service use_Broker_API

Server 인터페이스 역할 정의 IDL Server Binary Standard 서비스를 구현 한다. Broker에게 자신을 등록 시킨다. Server-side proxy 를 통해 Client에게 응답을 보낸다. Server initialize enter_main_loop run_service use_Broker_API

Broker 기능 역할 정의 Client 요청을 Server 에 보낸다. 응답 결과 및 예외를 Client 에 보낸다. 시스템 ID를 기반으로 요청을 처리할 Reciever 의 정보를 갖는다. 역할 정의 Server 들의 등록과 해지 API 제공 메시지 전송 에러 복구 Bridge를 이용한 Broker 간의 상호 작용 서버들의 위치 정보 관리 Broker main_event_loop update_repository register_service acknowledgment find_server Find_client Forward_request Forward_response

Client-Side Proxy 기능 역할 정의 Client와 Broker 사이의 계층으로 투명성을 제공 한다 원격 객체가 로컬 객체로 보이도록 한다. Client 의 상세 구현을 숨긴다. Client 와 Broker 간의 메시지 전달에 필요한 IPC 메카니즘 메모리 블록의 생성과 소멸 파라미터와 결과 값의 마샬링 역할 정의 System-specific 기능을 캡슐화 한다. Client 와 Broker 를 중재한다. Client-Side Proxy pack_data uppack_data send_request return

Server-Side Proxy 기능 역할 정의 Client-Side Proxy 와 비슷한 기능 서버 안의 서비스를 호출한다. 요청을 받는다. 받은 데이터 Unpacking 파라미터 Unmarshaling 적절한 서비스 호출 Client 에 응답이나 예외 등을 보내기 전에 Marshaling 역할 정의 서버 안의 서비스를 호출한다. System-specific 기능을 캡슐화 한다. Server 와 Broker 를 중재한다. Server-side Proxy pack_data uppack_data call_service send_response

Bridge 기능 역할 정의 두 개의 브로커가 상호작용하기 위한 상세 구현을 숨긴다. Optional 한 컴포넌트이다. 두 개의 브로커가 상호작용하기 위한 상세 구현을 숨긴다. Optional 한 컴포넌트이다. 다른 네트워크 환경 이나 OS 와의 통신 System-specific 기능을 캡슐화 한다. 역할 정의 Network-specific 기능을 캡슐화 한다. Local Broker 와 Remote Broker 를 중재한다. Bridge pack_data uppack_data forward_message transmit_message

작동 시나리오 Scenario 1. 등록 Scenario 2. 요청 보내기 Scenario 3. Broker 간의 상호 작동

1. 서버 등록 start main_evnet_loop() Initialize() register_service() Server Broker start Initialize() main_evnet_loop() register_service() update_repository() acknowledgment enter_main_loop()

2. 요청 보내기 Client Client-Side Proxy Broker Server-Side Proxy Server call_server send_request pack_data forward_request find_server call_service unpack_data run_service forward_response pack_data return find_client unpack_data result

3. Broker 간 상호 연동 Broker A Bridge A Bridge A Broker A forward request find_server forward_message pack_data transmit_message unpack_data forward_request find_server

실제 구현 Object 모델 결정 상호 운용성 결정 브로커 API 제공 프록시 구현 브로커 구현 IDL 컴파일러? (오브젝트 모델에 따라)

1. Object 모델 결정 이미 있는 것을 사용할 것인가? 아니면 도메인에 맞게 새로 생성할 것인가? Name Requests Values Supported Type 등 MS 에서는 도메인에 최적화된 Object 생성기를 만드는 것을 권장

2. 상호 운용성 결정 WCF 에선 XML 표준으로 객체 모델링! 바이너리 포맷을 사용할 것이냐? 프로토콜을 이용한 느슨한 객체 생성을 할 것이냐? High-Level IDL Binary Standard MS OLE COM CORBA Web Services CORBA 처럼 프로토콜을 이용해 객체 생성? COM 처럼 객체 바이너리를 주고 받을 거냐? WCF 에선 XML 표준으로 객체 모델링!

3. 브로커 API 제공 투명하게 브로커를 기능을 사용하도록 API 를 제공하게 한다.

4. 프록시 구현 Client 와 Server 의 구현 상세를 숨기기 위해 Proxy 를 구현한다. Client Object Serer Object Client Proxy Server Proxy BROKER Client 와 Server 의 구현 상세를 숨기기 위해 Proxy 를 구현한다. Layer 패턴을 이용한 투명화!

5. 브로커 구현 3. 과 4. 를 동시에 수행하는 Broker Component 디자인 - Proxy 들과 상호 작용할 수 있는 Raw 프로토콜 정의 - Local Broker 는 네트워상의 모든 머신에서 사용 가능해야 한다 - 모든 결과와 예외를 요청한 Client에게 전달해야 한다. - 만약 Proxy가 마샬링/언마샬링을 메커니즘을 제공 안 한다면 Broker가 구현해야 한다. - 비동기 통신을 지원한다면 임시 저장 장소를 제공해야 한다. - 디렉토리서비스를 포함시켜 식별자와 물리적 위치를 결합시킨다. - 서버 등록을 다이나믹하게 생성할 것을 요구한다면 Name Service를 구현 한다.

Variant Direct Communication Broker System Message Passing Broker System Trader System Adapter Broker System CallBack Broker System

Known use CORBA SOM DSOM WWW ATM-P COM+

결론 단점 장점 효율성에 제약 결함처리 능력 미약 테스팅과 디버깅이 힘듬 위치 투명성 컴포넌트의 교체와 확장성 Broker 시스템의 쉬운 이동성 Broker 간의 연동 재사용성 효율성에 제약 결함처리 능력 미약 테스팅과 디버깅이 힘듬

추가로 봐야 할 패턴들 Forwarder-Receiver Pattern Proxy Pattern Client-Dispatcher-Server Pattern Mediator Pattern

그럼 브로커가 짱인가요?

세상이 변하고 있다 프로그래밍 패러다임 변화 변화에 대처하기

프로그래밍 패러다임의 변화

변화에 대처하려면? 변화를 예측 하라! 변하는 것과 변하지 않는 것을 구분 하라!

마무리 Reference

Reference POSA Vol.1 P.99~P.124 Evacast.net MSDN GOF Pattern

통합 인증 서버 Plus Broker Proxy 클라이언트 Proxy 통합 인증서버 Proxy Proxy 위치 투명성 제공 MU Object로 통신 위치 투명성 제공 Proxy 클라이언트 Proxy 통합 인증서버 리니지 Proxy WOW 브로커 Proxy

끝 감사합니다. 거인의 어깨에 오르려면 많은 노력이 필요! WCF, 닷넷 등 최신 기술에 민감해 집시다! joonseok.ahn@live.co.kr 2008.04.07 안준석