버스에 다중 WS-Notification 서비스 작성 이유
일반적으로 각 서비스 통합 버스에 둘 이상의 WS-Notification 서비스를 작성할 필요는 없지만 작성하는 것이 유리한 경우가 있습니다.
셀에 다중 서비스 통합 버스가 정의되어 있고 각 버스에 정의된 메시징 자원에 WS-Notification 액세스를 제공하려는 경우 각 버스에 WS-Notification 서비스를 정의해야 합니다. WS-Notification 액세스가 필요한 각 서비스 통합 버스에 한 개의 WS-Notification 서비스를 구성하는 것은 권장되는 접근 방식입니다. 이를 사용하면 다른 WS-Notification 서비스에 연결되는 애플리케이션이 정보를 서로에게 전달하지 못하거나 개입할 수 없도록 할 수 있습니다.
클라이언트 애플리케이션 그룹을 해체된 세트로 분리하기 위해 단일 버스에 여러 개의 WS-Notification 서비스를 정의하도록 선택할 수 있으며 예를 들어, 이 절의 이후에 나열된 요구사항 중 하나를 충족하도록 수행할 수 있습니다. 그렇지만 이 패턴은 조심해서 사용해야 합니다. 이는 특히 WS-Notification 서비스에 정의된 WS-Notification 토픽 네임스페이스와 연관되는 경우 이를 선택하면 중요한 사항이 내포되기 때문입니다. 토픽 네임스페이스 패턴에 대한 자세한 정보는 버스 토픽 공간과 영구 토픽 네임스페이스 연관 옵션의 내용을 참조하십시오.
- 다른 네임스페이스를 사용하여 애플리케이션 분리. 각각의 서비스를 사용하는 애플리케이션을 분리하기 위해 두 개의 WS-Notification 서비스에서 구분되는 토픽 네임스페이스 URI(및 동등하게 다른 서비스 통합 버스 토픽 공간)를 사용할 수 있습니다. 자세한 정보는 서비스 통합 버스 토픽 공간과 토픽 네임스페이스 URI 사이의 "1 대 1" 연관의 내용을 참조하십시오. 이런 방식으로 분리하는 것은 단일 WS-Notification 서비스를 사용해서도 가능합니다.
- 동일한 네임스페이스를 사용하여 애플리케이션을 강제로 분리합니다. 단일 버스에 다중 WS-Notification 서비스를 정의하는 중요한 장점은 서로 상호 작용하지 않는 둘 이상의 그룹에서 동일한 토픽 네임스페이스를 사용하도록 작성되는 애플리케이션 콜렉션의 파티셔닝 기능입니다. 이를 사용하여 첫 번째 WS-Notification 서비스에 연결된 애플리케이션은 두 번째 WS-Notification 서비스에 연결된 애플리케이션과 완벽하게 분리되어 조작할 수 있으며 이들이 동일한 토픽 네임스페이스를 사용하여 거의 동일한 토픽 세트를 사용하는 경우에도 마찬가지입니다. 자세한 정보는 서비스 통합 버스 토픽 공간과 토픽 네임스페이스 URI 사이의 "다 대 1" 연관의 내용을 참조하십시오.
- 대체 JAX-RPC 핸들러 목록 및 아웃바운드 보안 설정. 이 특성은 각 아웃바운드 포트가 아니라 각 WS-Notification 서비스에 대해 지정됩니다. 이 특성에 대해 대체 옵션이 필요한 경우 각 대체 아웃바운드 구성에 대해 동일한 버스에서 별도의 WS-Notification 서비스를 작성해야 합니다.