브로커 패턴

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

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

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

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

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

6. 통합 온라인 게임 모티브

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

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

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

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

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

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

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

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

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

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

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

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

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

20. 메시징 방식의 변화

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

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

23. 순서

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

25. Broker 구성요소 • Client • Server • Broker • Client-Side Proxy • Server-Side Proxy • Bridge

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

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

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

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

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

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

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

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

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

35. 2. 요청 보내기 Server-Side Proxy Server Client Client-Side Proxy Broker 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

36. 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

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

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

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

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

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

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

43. Variant • Direct Communication Broker System • Message Passing Broker System • Trader System • Adapter Broker System • CallBack Broker System

44. Known use

45. 결론 단점 장점

46. 추가로 봐야 할 패턴들

47. 그럼 브로커가 짱인가요?

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

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

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