화이트보드 패턴
도입
OSGi 서비스의 다이내믹한 특징 때문에 프로그래머가 그 변경 사항을 추적해야 하는 노고가 필요한데, 이전에는 리스너들을 사용했었는데 이게 너무 복잡해지고 에러가 발생할 여지가 많아서 이 문서에서 그 이슈를 살펴보고 보다 쉽고 근본적으로 더 신뢰할 수 있는 모델을 설명하고자 한다.
배경
1. 리스너 패턴
자바의 기본적인 이벤트 리스너 구조 설명 생략.
리스너 패턴의 단점. 클래스 파일이 너무 많다. 프로그램 시작 시간에 영향을 주고 프로그램 사이트에도 영향을 주고 따라서 실행시 오버헤드가 존재한다. 대부분의 경우 이벤트 소스는 단일 리스트만 등록한다. 그런데도 이벤트 소스는 리스너들 리스트를 다룰 수 있도록 반드시 추가적인 벡터를 가지고 있어야 한다. 물론 이 문제가 메모리가 남아돌고 CPU가 빠른 데탑에서는 별 문제가 아니지만 임베디드 환경에서는 매우 중요한 오버헤드다.
또 다른 이슈는 이벤트 소스와 리스너 사이의 의존성이 분명하지 않다는 것이다. 이벤트 소스가 사라지면 그것이 물고 있던 리스너들도 제거되어야 한다. 만약 리스너가 없어지면 해당 리스너를 리스너 목록에서 제거해야 한다. 이런걸 사이프 사이클 이슈라고 한다. 일반적인 자바 애플리케이션에서는 이게 별 문제는 아니다. 일반적으로 초기화 과정 중에 리너너들을 등록하는데 이건 뭐 구현하기도 쉽고 확인하기도 쉽다. 하지만, 제거 하는 과정은 검증하기가 어렵고 보통 전혀 이런 과정을 다루지도 않는다. 워크스테이션 환경에서는 이게 별 문제가 아니다. 하지만 임베디드 환경에서는 이런 가정을 할 수 없으며 완전히 동적이지도 않다.
2. OSGi 환경
OSGi 환경에는 다음고 같은 것들이 필요하다
• Small devices
• Collaboration model
• Continuously up and running VM
• Life cycle management
작은 장치. 각각의 클래스 파일은 300 에서 500 바이트의 오버헤드를 가지고 있다. 따라서 파일이 많아질 수록 안 좋다. 따라서 OSGi 스펙 만드는 초기 시절에는 어설픈 예외 클래스나 어댑터 클래스들을 만들지 않기로 결정했었다.
작은 장치는 성능과 동적 메모리에도 제약이 있다. 메모리를 사용하는 객체들을 만드는 것도 최소화하는 방안을 스펙을 만들며 시도했다.
OSGi 협력 모델은 서비스 레지스트리를 사용하여 만들어졌다. 이 레지스트리는 번들(이게 곧 애플리케이션)이 서비스를 등록하도록 한다. 서비스는 보통 자바 객체이며 자바 인터페이스를 사용하여 다른 구현체로 갈아 칠 수도 있로고 한다. 레지스트리의 동적인 성격은 서비스가 언제 나오고 들어가는지 서비스 추적할 수 있는 무언가를 필요로 하게 됐다.
지속적인 수정과 실행 기능은 "라이프 사이클 관리"와 "다른 프로그래밍 규칙을 필요로하는 서비스 레지스트리"에 관련되어 있다.
3. 화이트보드 패턴
화이트보드 패턴은 리스너 패턴으로 인해 필요한 사적인 레지스트리를 만드는 대신 서비스 레지스트리의 사용을 강화한 것이다. 이벤트 리스너를 이벤트 소스에 등록해서 이벤트를 추적하는 대신 화이트보드 패턴은 리스너 자체를 서비스로 등록하고 이벤트 소스가 이벤트를 가지고 서비스 레지스트리에 있는 모든 리스너들을 호출하는 방법이다.
보통은 서버 번들과 애플리케이션 번들 간에 복잡도 트레이드 오프가 있기 마련인데, 이 경우에는 둘 다 복잡도가 낮아진다. 둘 모두 OSGi 서비스 레지스트리에게 책임을 위임했기 때문이다.
추가적인 장점
- 디버깅: 이벤트 리스너를 레지스트리에서 볼 수 있다. 어떤 프레임워크도 레지스트리를 탐색하는 도구를 지원할꺼다.
- 시큐리티: OSGi 프레임워크 ServicePermissions는 이벤트 소스로의 접근을 제어할 수 있다. 이벤트 리스너가 이벤트 리스너 인터페이스를 등록할 수 있는 권한을 가지고 있어야하기 때문이다.
- 프로퍼티즈: 레지스트리는 모든 리스너중 부분집합을 선택할 때 서버가 사용할 프로퍼티즈를 사용할 수 있다. 이런 매카니즘을 설정 관리에 사용할 수 있다.
참조 : http://www.osgi.org/documents/osgi_technology/whiteboard.pdf