화이트보드 패턴
Whiteboard Pattern |
화이트보드 디자인 패턴은 OSGi 프레임워크의 서비스 레지스트리에 영향을 미치는 OSGi 서비스 모델입니다.화이트보드 패턴은 전통적인 모델의 복잡하고 오류가 발생하기 쉬운 특성 때문에 생겨났습니다.수신기 패턴(관찰자 [1]패턴이라고도 함).
OSGi 서비스 모델은 서비스 레지스트리를 지원하는 협업 모델입니다.서비스 레지스트리를 사용하면 애플리케이션 또는 번들에서 서비스를 등록할 수 있으며, 이는 다양한 기능을 구현하기 위한 단순한 Java 인터페이스입니다.서비스 레지스트리의 동적 특성은 언제든지 나타나거나 떠날 수 있는 서비스를 추적하는 데 유용합니다.화이트보드 패턴은 수신기 [1][2]패턴에서 지원되지 않는 이러한 OSGi 서비스 모델을 지원하기 위해 만들어집니다.
소개
청취자[1] 패턴
수신기 패턴은 일반적으로 관찰자 패턴이라고 합니다.이것은 다른 개체의 상태에서 동적인 변화를 처리하는 행동 패턴(퍼블리시-구독이라고도 함)입니다.
수신기 패턴은 이벤트 수신기가 이벤트 원본에 등록되는 구조를 따릅니다.이제 이벤트 소스가 상태를 변경할 때마다 모든 이벤트 수신기에 이벤트 개체를 통해 변경 사항에 대한 알림이 표시됩니다.이 패턴에서 모든 것은 이벤트 소스에 의해 제어됩니다.
수신기 패턴의 구현은 매우 복잡합니다.수신기 패턴은 많은 이벤트 수신기를 지원하므로 모든 수신기가 이벤트 원본에 등록됩니다.이벤트 수신기는 이벤트 소스에 대한 액세스 제어 권한을 가지고 있지 않으므로 모든 서비스에 대해 새 파일이 생성됩니다.이로 인해 클래스 파일의 오버헤드가 발생하고 프로그램 실행 시간과 메모리 사용량에 영향을 미칩니다.또한 이벤트 수신기가 종료될 때 이벤트 원본에서 등록이 취소됩니다.반대로 이벤트 소스가 종료될 때 이벤트 수신기의 모든 참조가 제거됩니다.여기서는 정리가 자동으로 수행되는 것으로 가정하지만, 지속적으로 실행되고 동적인 일부 내장 애플리케이션은 이 가정을 검증할 수 없으며 심각한 문제를 야기합니다.
화이트보드 패턴
화이트보드 패턴은 이벤트 수신기가 특수 서비스를 찾는 역할에 의해 제안될 수 있습니다.또 다른 역할은 이벤트 수신기가 검색된 서비스를 찾는 경우일 수 있습니다.
화이트보드 패턴은 이벤트 수신기가 이벤트 원본에 등록되는 구조를 따릅니다.이 서비스 등록은 서비스를 관리하기 위한 응용 프로그램 프로그래밍 인터페이스인 서비스 레지스트리에 의해 유지됩니다.번들은 이 인터페이스를 구현하고 서비스 레지스트리에 서비스를 등록합니다.번들은 일반적으로 잘 작성된 매니페스트 파일이 제공되는 Java 클래스 그룹으로, 다른 많은 서비스와 바인딩하는 데 도움이 됩니다.이제 이벤트 수신기는 서비스 레지스트리에서 서비스를 찾거나 서비스가 실행될 때 응답할 수 있습니다.이 패턴에서는 이벤트 수신기에 제어 권한이 부여됩니다.
화이트보드 패턴은 모든 서비스를 동적으로 처리해야 하므로 구현이 복잡합니다.이러한 동적 특성을 처리하기 위해 화이트보드 패턴은 응용프로그램 번들과 서버 번들을 사용하여 구현됩니다.프레임워크 레지스트리를 동적으로 재사용할 수 있으므로 구현이 쉬워집니다.애플리케이션 번들과 서버 번들 모두 [1][3]서비스와 프레임워크에 대한 상호 의존성을 관리합니다.
장점과 단점:수신기 패턴 초과
장점[1][4]
- 새 번들을 쉽게 추가할 수 있습니다.
- 제공 및 구성된 번들은 어떤 방식으로든 하위 시스템에서 사용할 수 있습니다.따라서 레지스트리는 구성 관리를 지원합니다.
- 번들과 번들 간의 연결을 테스트하는 것은 쉽습니다.
- 프레임워크 레지스트리를 재사용하기 때문에 구현 및 디버깅이 쉽습니다.수신기 패턴을 사용하여 동일한 서비스를 구현하는 것은 지루한 작업이며 재사용할 수 없습니다.
- 안전합니다.이벤트 수신기는 이벤트 원본 및 모든 상태 변경에 대해 액세스 제어를 가지므로 이벤트 수신기에 알림을 받는 반면 수신기 패턴에서는 이벤트 수신기에 대한 액세스 권한이 없습니다.
단점[1][4]
- 내용의 상대적 위치를 결정하는 것은 이벤트 원본 및 이벤트 수신기인 반면, 수신기 패턴에서는 모든 내용이 이벤트 원본에서 가져옵니다.
- 서비스 레지스트리의 범위가 정의되지 않았습니다.따라서 번들 집합이 서로 다른 하나의 프레임워크에서 요청하는 여러 이벤트 수신기를 지원할 수 없습니다.
사용 및 예제
일반적으로 화이트보드 패턴용 OSGi 모델은 많은 [5]번들과의 상호 종속성을 처리합니다.일부 용도는 다음 예를 사용하여 명시됩니다.
TV 쇼는 LCD에 투사될 것입니다.'디스플레이' 서비스라는 이름의 서비스가 여러 번들에 걸쳐 다른 컨텐츠를 포함하는 내용을 투영한다고 가정합니다.이 콘텐츠가 일부 '공급자'에 의해 제공되었다고 가정합니다.인터페이스는 콘텐츠를 표시하려는 모든 번들에 의해 구현될 수 있으며, 여기서 '공급자'는 콘텐츠를 가져오기 위해 쿼리됩니다.'디스플레이 강사'는 서비스 레지스트리의 모든 화면을 순환하여 특정 시점에 최종 콘텐츠를 표시해야 하며, 이는 '공급자'[1]를 구현하는 '타임 매니저'가 관리합니다.
이것은 '디스플레이 강사'와 '시간 관리자' 사이의 종속성이 처리됨을 나타냅니다.그리고 둘 다 언제든지 동시에 또는 어떤 순서로 작업할 수 있습니다.
II) 친구 그룹은 웹 기반 UI 포털을 사용하여 기사를 저장합니다.친구들이 기사의 섹션에서 일하고 있습니다.섹션에는 그룹의 일부 구성원이 추가한 내용이 포함됩니다.화이트보드 패턴을 사용하여 내용을 추가하고 웹 포털에 표시하기 위한 종속성을 처리합니다.그리고 이 두 가지 작업은 언제든지 동시에 또는 어떤 순서로 수행될 수 있습니다.
결론[1]
화이트보드 패턴 구현은 더 작고 간단하므로 프로그래밍 오류가 발생할 가능성이 적습니다.코드 크기에 따라 수신기 패턴이 화이트보드 패턴보다 교착 상태일 가능성이 더 많다는 것이 중요합니다.
OSGi 환경은 Java의 기본 프로그래밍 규칙을 완전히 따르지 않고 Java에 대한 자체 기능을 보여줍니다.수신기 패턴은 첫 번째 단점으로 간주될 수 있는 OSGi 환경에 이러한 프로그래밍 규칙을 적용합니다.이와 별개로 청취자 패턴은 OSGi 환경에서 예상되는 동적 변경에 적합하지 않습니다.
이벤트 청취자의 프로그래머인 청취자 패턴이 프로그램을 완전히 담당합니다.그는 수신기에 등록된 이벤트 소스와 이벤트 소스 간의 모든 종속성을 결정합니다.
번들은 다른 응용 프로그램에서 자동으로 실행되는 응용 프로그램이 아닙니다.환경의 다른 번들과 바인딩하기 위해 실행 중인 구성 요소입니다.번들을 올바르게 구성하고 관리해야 합니다.번들은 직접 제어가 되지 않는 형식으로 작성되어야 하며, 다른 번들과 연결하고 구성할 수 있는 서비스를 제공해야 합니다.화이트보드 패턴은 번들의 이러한 기능을 지원하며 수신기 패턴에 비해 상당히 개선되었습니다.
이러한 이유는 번들 간 종속성을 관리해야 하는 화이트보드 패턴을 적용하는 데 있어 위협적인 요소입니다.
