기본적으로, 브로커는 원하는 모든 subscriber에 publication을 송신한 후
publication을 제거합니다. 그러나 publisher는 브로커가
publication 사본을 보관하고자 함을 지정할 수 있습니다. 이 publication을 보유
publication이라 합니다.
보유 publication의 사본은 브로커에 의해 해당 publication의 토픽에 등록한
모든 subscriber로 송신됩니다. 이는 새 subscriber가
정보를 수신하기 전에 정보가 다시 publish되기를 기다리지 않아도 됨을 의미합니다.
예를 들면, 주가에 대한 subscription을 등록하는 subscriber는 주가가 변경되어
다시 publish될 때까지 기다리지 않고 가장 최근에 publish된 가격을 곧바로 수신합니다.
RetainPub가 Publish 메시지의 publication 옵션으로 지정된 경우, 브로커는 publication을
보유하며 해당 토픽의 이전 보유 publication을 바꿉니다.
브로커는 토픽 및 subscription 지점마다 하나의 publication만 보유하므로,
새 publication이 도착하면 이전 publication이 삭제됩니다.
보유 publication의 사용 여부를 결정할 때는 다음 질문을 고려하십시오.
- publication에 상태 정보 또는 이벤트 정보가 포함됩니까?
일반적으로 이벤트 정보는 보유되지 않으나 상태 정보는 보유됩니다. 그러나 토픽에서 publish가 수행되기 전에 해당 토픽에 대한 모든 Subscription이
제 위치에 있고 새 Subscription이 예상되지 않는 경우, publication은 publish되는
즉시 모든 subscriber에 전달되므로 publication(상태 정보의 publication 조차도)을 보유할
필요가 없습니다.
상태 정보를 포함하는 publication 역시 매우 빈번하게(예: 매초) publish될 경우에는
보유할 필요가 없습니다. 이처럼 자주 publish되면, 새 subscriber(또는 실패에서 복구한
subscriber)는 거의 publication을 subscribe하는 즉시 현재 상태를 수신합니다.
- 요청 시에만 publication을 수신하고자 합니까?
보유 publication을 사용할 경우,
subscriber는 Register Subscriber 메시지의 PubOnReqOnly 옵션을 사용하여
등록할 수 있습니다. 이는 subscriber가 갱신을 요청할 때에만
브로커가 해당 subscriber에 publication을 송신함을 의미합니다. 그 다음 브로커는 subscription과 일치하는 현재의 보유 publication을 송신합니다.
- 동일한 토픽에서 보유 publication과 비보유 publication을 혼합할 수 있습니까?
이것은 권장하지 않습니다. 보유 publication이 있는 상태에서 동일한 토픽에서
비보유 publication을 publish하면, 기존의 보유 publication이 그대로 보유됩니다. 비보유 publication으로 갱신되지 않습니다. Subscriber가 Register Subscriber 메시지의
PubOnReqOnly 옵션을 사용하여 등록할 경우에는 비보유 publication에 액세스할
수 없습니다.
브로커는 갱신 요청에 대한 응답으로 현재 보유 publication만 송신합니다.
- 동일한 토픽에서 보유 publication을 publish하는 둘 이상의 응용프로그램을 가질
수 있습니까?
동일한 토픽에서 보유 publication을 publish하는 응용프로그램은 하나가 바람직합니다. 이러한 응용프로그램이 둘 이상이고 타이밍이 동시에 가까우면,
어느 publication이 보유되는지 명확하지 않습니다. publisher가 서로 다른 브로커를 사용할 경우, 각 브로커에 동일한 토픽의
서로 다른 보유 publication이 저장될 수도 있습니다.
- Subscriber 응용프로그램이 실패에서 어떻게 복구됩니까?
Publisher가
보유 publication을 사용하지 않을 경우, subscriber 응용프로그램은 현재 상태를
로컬로 저장해야 할 수도 있습니다. Publisher가 보유 publication을 사용하면,
subscriber는 재시작 후 상태 정보를 새로 고치기 위해 갱신을 요청할 수 있습니다.
브로커는 subscriber가 실행 중이 아닌 경우에도 등록된 subscriber에
계속해서 publication을 송신합니다. 이로 인해 subscriber 큐에 메시지가
누적될 수 있습니다.
Subscriber가 Register Subscriber 메시지의 PubOnReqOnly
옵션을 사용하여 등록하면 이러한 누적을 피할 수 있습니다. 이 경우, subscriber는 갱신을 요청하거나 임시 다이나믹 큐를 사용하여 해당
상태를 주기적으로 새로 고쳐야 합니다.
- 보유 publication은 성능에 어떠한 영향을 미칩니까?
브로커는 보유 publication을 데이터베이스에
저장해야 합니다. 이로 인해 처리량이 감소합니다. Publication이 매우 크면,
각 토픽의 보유 publication을 저장하기 위해 상당한 양의 디스크 공간이
필요합니다. 멀티브로커 환경에서는 일치하는 subscription이 있는 다른 모든
연결된 브로커에 의해 보유 publication이 저장됩니다.
보유 publication의 만기 간격을 설정하려면 메시지 설명자(MQMD)의
만기 필드를 사용하십시오.
WebSphere Message Broker와 함께 제공되는 샘플 확인 응용프로그램에 Soccer Results 서비스가
있습니다. 이 샘플에서는 보유 publication을 사용하여 모니터 중인 각 축구 경기의
최신 득점 상황을 기록합니다. 샘플 코드는 이 옵션을 지원하는 데 필요한
프로그래밍을 설명합니다.
모든 응용프로그램이 보유 publication을 publish할 수 있는 것은 아니며,
모든 보유 publication에 만기 날짜를 적용할 수 있는 것은 아닙니다. 다음 표에서는 보유 publication을 publish할 수 있는 응용프로그램과
보유 publication에 만기 날짜를 적용할 수 있는지의 여부를 보여줍니다.
|
MQ |
SCADA |
JMS/IP |
보유 |
예 |
예 |
아니오 |
만기 날짜 |
예 |
아니오 |
아니오 |
표의 열은 세 개의 응용프로그램 유형을 표시합니다. 첫 번째 행은 publication이 보유 publication이 될 수 있는지의 여부를 표시하고,
두 번째 행은 publication에 만기 날짜를 적용할 수 있는지의 여부를 표시합니다.