버스 토픽 공간과 영구 토픽 네임스페이스 연관 옵션

WS-Notification 서비스에서 영구 토픽 네임스페이스를 구성하는 경우, WSN 알림 조작에 대한 응답으로 메시지가 공개되고 등록과 일치하는 경우 수신되는 서비스 통합 버스 토픽 공간을 지명합니다. 셀에 정의된(즉, 해당 셀에 정의된 모든 WS-Notification 서비스에 대한) 영구 토픽 네임스페이스 세트와 이 네임스페이스가 연관된 통합 버스 토픽 영역 간에 다대다 관계를 작성할 수 있습니다. 이러한 관계는 WS-Notification 서비스에 연결하는 애플리케이션에 필요한 토폴로지에 따라 상당히 복잡할 수 있습니다. 이 토픽은 특정 구성이 적절하거나 적절하지 않을 수 있는 지침을 제공합니다.

다음 옵션은 복잡성의 증가 순서대로 배열됩니다. "1 대 1" 연관을 제외하고는 구성 시 주의해야 합니다.

서비스 통합 버스 토픽 공간과 토픽 네임스페이스 URI 사이의 "1 대 1" 연관

이 버스에서 한 개의 WS-Notification 서비스가 정의되거나 두 개의 WS-Notification 서비스가 정의되는 상황에서 두 번째 서비스는 동일한 서비스 통합 버스 토픽 공간에 연괸된 토픽 네임스페이스를 포함하지 않습니다.

이 구성은 WS-Notification 애플리케이션이 이벤트 알림을 서비스 통합 버스 토픽 공간에 삽입(또는 여기에서 알림 수신)하는 WS-Notification 애플리케이션 기능을 제공하며 여기에는 알림이 포함되거나 버스의 다른 클라이언트로 시작될 수도 있습니다.

제공된 버스에 여러 개의 WS-Notification 서비스가 정의되는 상황에서 이 "1 대 1" 연관은 각 서비스에 접속된 클라이언트 사이의 분리를 보장하며 이는 첫 번째 WS-Notification 서비스를 사용하여 삽입되는 이벤트 알림이 두 번째 WS-Notification 서비스를 통해 연결된 애플리케이션에서 수신되지 않음을 의미합니다. 이 분리 패턴은 두 개의 WS-Notification 서비스를 동일한 버스에서 작성하는 이유 중 하나입니다.

서비스 통합 버스 토픽 공간과 토픽 네임스페이스 URI 사이의 "다 대 1" 연관

이 경우, 단일 토픽 네임스페이스 URI가 여러 개의 서비스 통합 버스 토픽 공간과 연관됩니다. 이는 네임스페이스 URI가 제공된 WS-Notification 서비스에서 한 개의 서비스 통합 버스 토픽 공간과만 연관 가능하기 때문에 여러 개의 WS-Notification 서비스가 정의된 경우에만 발생할 수 있습니다.

이 접근 방식은 동일한 네임스페이스 URI를 사용하는 몇 개의 클라이언트가 있고 다른 클라이언트와 서로 상호 작용하지 않도록 클라이언트 서브세트를 분리하려는 경우에만 사용해야 합니다. 이를 수행하는 정확한 이유는 전적으로 현재 상황에 따라 다르지만 일반적으로 이는 필요하지 않아야 합니다. 이 분리 패턴은 두 번째(대부분 부득이한 경우) 제공된 버스에서 둘 이상의 WS-Notification 서비스를 작성하는 이유입니다.

서비스 통합 버스 토픽 공간과 다중 토픽 네임스페이스 URI 사이의 "1 대 다" 연관

이런 상황에서는 다중 영구 토픽 네임스페이스가 동일한 서비스 통합 버스 토픽 공간을 지시하는 동일한 WS-Notification 서비스에 정의됩니다.

이를 수행하는 대부분의 명확한 이유는 이미 두 개의 다른 URI를 사용하도록 코딩된 두 개의 애플리케이션 그룹이 있고 이 애플리케이션 그룹은 서로 어떻게든 연결되어 따라서 동일한 서비스 통합 버스 토픽 공간을 사용하여 이를 지원하려고 하기 때문입니다. 이는 다음 이유 중 하나일 수 있습니다.
  • 두 개의 애플리케이션 그룹에서 사용되는 토픽은 겹치지는 않지만 동일한 WS-Notification 이외의 애플리케이션과 상호 작용하려고 합니다. 이 패턴을 사용하여 다른 버스 애플리케이션은 두 애플리케이션 그룹에서 메시지를 수신할 수 있도록 단일 토픽 공간에만 연결해야 합니다.
  • 두 개의 애플리케이션 그룹을 사용하는 토픽은 어떤 식으로든 겹치고 다른 그룹의 애플리케이션이 전송한 공개를 해당 애플리케이션 그룹이 수신할 수 있도록 하려고 합니다. 예를 들어, 두 네임스페이스에 정확하게 동일한 토픽이 포함되어 있지만 네임스페이스 URI가 일부 표준화된 이름 지정 설계를 준수하기 위해 변경되는 경우 이전 애플리케이션은 원래 이름을 사용하지만 새 애플리케이션은 새 이름을 사용합니다.
동일한 WS-Notification 서비스에 다중 토픽 네임스페이스를 정의(동일한 서비스 통합 버스 토픽 공간을 사용하지만 다른 네임스페이스 URI로)하는 두 번째 이유는 다른 애플리케이션 그룹에 다른 토픽 공간 문서를 적용하기 위해서입니다. 이는 다음 이유 중 하나일 수 있습니다.
  • 토픽 네임스페이스는 전혀 연관되지 않지만 별도의 서비스 통합 버스 토픽 공간 작성을 위한 관리 비용을 방지하기 위해 동일한 서비스 통합 버스 토픽 공간을 사용하려고 합니다. 이는 일반적으로 네임스페이스로 사용하는 토픽이 겹치지 않는 경우에 수행해야 하며 그렇지 않으면 두 애플리케이션 세트 사이에서 개입할 수 있습니다.
  • 네임스페이스 겹침에 정의된 토픽 및 각 네임스페이스를 사용하는 애플리케이션은 동일한 WS-Notification 이외의 애플리케이션과 상호 작용하려고 합니다. 이런 경우, 토픽 네임스페이스 문서를 사용하여 트리 구조로 특정 토픽 네임스페이스에 적용되는 토픽 서브세트를 정의하고 해당 문서를 애플리케이션의 특정 그룹과 연관시킵니다. 애플리케이션의 다른 두 그룹에 대한 토픽 네임스페이스 문서가 겹치는 토픽 구조를 정의하는 경우, 겹치는 토픽을 등록하는 WS-Notification 이외의 애플리케이션은 두 애플리케이션 그룹에서 공개된 알림을 수신합니다.

서비스 통합 버스 토픽 공간과 다중 토픽 네임스페이스 URI(다른 WS-Notification 서비스) 사이의 "1 대 다" 연관

여러 개의 WS-Notification 서비스를 정의한 경우 WS-Notification 서비스에 연결된 모든 클라이언트에 동일한 기능을 제공하기 위해 각 서비스에서 동등한 영구 토픽 네임스페이스를 작성할 수 있습니다. 그렇지만 이는 단일 서비스에 연관된 서비스 위치에 연결하려는 모든 애플리케이션을 가져와서 더 쉽게 수행할 수도 있습니다.

동일한 서비스 통합 버스 토픽 공간 이름의 다른 버스

혼동할 수 있는 다른 상황은 두 개의 서비스 통합 버스가 있고 각각에는 (단일) WS-Notification 서비스가 정의되어 있으며 버스에는 동일한 서비스 통합 버스 토픽 공간 이름이 포함되어 있습니다. 이런 경우, 사용되는 토픽 공간 대상은 완벽하게 분리되어(링크되지 않음) 두 개의 WS-Notification 서비스를 사용하는 애플리케이션 사이에서 전혀 겹치지 않습니다. 이런 상황에서의 혼동 가능성을 인식하고 적절한 조치를 수행해야 합니다.


주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjwsn_ptn_options
파일 이름:cjwsn_ptn_options.html