아키텍쳐 패턴 - Broker 패턴

만약 현재 개발중인 환경이 독립적인 협력 컴포넌트들로 구성된 이질적인 분산시스템이라면 Broker 패턴을 생각해 봐야 한다.

분산은 아래와 같은 장점이 있다.
  - 경제성
  - 성능과 범위성
  - 고유 분산성
  - 신뢰성

그해 비해 단점은 중앙집중적 시스템이 가지고 있는 것과는 근본적으로 다른 소프트웨어가 필요하다는 것이다. 보통의 경우 분산 시스템은 느리고(비효율적) 예외의 종류가 비약적으로 증가하기 때문에 만들기가 훨씬 더 어렵다.

간단히 말하자면 브로커 패턴은 중개인을 통해 원격 컴포넌트의 위치 투명성을 제공하는 것이다. 컴포넌트는 위치 투명한 서비스 호출을 통해서 다른 컴포넌트가 제공하는 서비스에 억세스 할수있고 런타임에 컴포넌트의 추가나 제거가 가능해야 한다. 그리고 아키텍쳐는 특정 시스템에 국한된 세부사항(system-specific details)과 특정 구현에 국한된 세부사항(implementation-specific details)을 숨겨야 한다. 

브로커패턴의 예에는 CORBA(common object request broker architecture)와 DCOM(OLE 2.x)이 있는데 현재는 두 사양 모두 많이 사용되지는 않고 EJB2도 위 패턴을 도입했지만 느린 속도등의 이유로 역시 활성화 되지는 못하였다. 

개인적인 의견이지만 분산환경에서 위치투명성이란 코드적 관점이지 프로그래머적 관점은 아니라고 생각한다. 무슨 말이냐면 브로커 패턴을 이용한 분산 시스템에서 코드는 위치투명한 컴포넌트의 서비스 코드를 사용하지만 그걸 작성하는 사람은 이게 원격호출인지 아닌지를 알고 있어야 한다는 뜻이다. 그렇지 않으면 최소한 지금의 네트워크 환경에서는 Hello World 정도의 프로그램이 아닌 보통의 실제 어플리케이션의 복잡함을 감당할 실행속도가 나오기가 힘들다고 생각한다. (비록 coarse-grained 패턴을 쓴다고 해도 말이다. ) 이 블로그의 AL Framework는 이런 관점의 브로커 패턴을 사용한 프레임워크이다.


Broker 패턴은 분산 어플리케이션을 개발하면서 어쩔 수 없이 야기되는 복잡성을 줄인다. Broker 패턴을 사용할 경우 개발자는 분산 구조를 투명하게, 다시 말해서 개발을 위해 필요한 부분과 필요하지 않은 부분을 명확하게 구별해 파악함으로서 분산의 전체 구조를 바라볼 수 있다. 확장된 이 분산 어플리케이션은 이기종 머신에서 실행될 수 있고 각기 다른 프로그래밍 언어로 작성될 수 있다.



브로커 패턴은 아래와 같은 장단점이 있다.
장점
1. 위치 투명성이 제공된다.
2. 컴포넌트의 가변성과 확장성이 보장된다.
3. 플랫폼간의 이식 가능성이 제공된다.
4. 서로 다른 Broker 시스템들간의 상호 운용성이 지원된다.
5. 재사용성이 확보된다.

 

단점
1. 효율이 낮다.
2. 장애 허용성이 낮다.
3. 테스트와 디버깅이 한편으론 용이하고 다른 한편으론 복잡하다.

Broker 패턴은 거대 규모의 인프라 패러다임으로 단일 어플리케이션을 구축할 때에는 잘 사용되지 않으며 여러 어플리케이션 전체를 위한 플랫폼 역할을 한다.