tibco 정적 브리지 대기열 대 정적 내구성

Question

TIBCO의 JMS 대기열에서 새 작업을하고 다음을 알고 싶습니다.

는 여러 부서

• 부서
• 부서 B
• 부서 C

외부 소스로부터 받았다 메시지가 다른 부서에서 사용하기 위해 필요로하는 회사를 생각해 보자. 각 부서의 고객이 tibco 정적 브리지 대기열 또는 정적 내구성 주제가 있습니까?

어떤 장단점의 장점/단점은 무엇입니까?

Answer 1

JMS 큐와 JMS 토픽 (jms queue! = FIFO)의 차이점을 이미 알고있는 것으로 가정하고 [http://en.wikipedia.org/wiki/Java_Message_Service] [1]을 참조하십시오. 여기 주소가 아닌 보안 문제의 전부입니다.

그래서 보안에주의를 기울여야한다고 가정 해 봅시다. 주된 질문은 클라이언트가 대기열에서 메시지를 가져 와서 대기열에 넣으면 대기열에 문제가 없지만 프로세스를 생성하는 경우입니다. 특정 채널에 가입 한 다음 대기열을 원하는 사용자.

모든 부서가 동일한 대기열에 메시지를 드롭 한 다음 해당 클라이언트 만 대기열에서 메시지 만 가져온 경우를 보았습니다.이 작업은 jms 등록 정보 세트 및 선택자를 사용하여 수행 할 수 있습니다.

이 솔루션은 클라이언트가 "자리 표시 자"대기열/주제에서 메시지를 읽는 방법을 변경하는 구현 유형의 솔루션입니다. 성능은 TIBCO EMS에서 모두 잘 수행됩니다. 나는 1 백만 메시지/초 이상의 처리량을 보았습니다. 메시지가 이동하는 속도는 "서비스가 수행하는 시간/소요 시간"과 클라이언트가 읽는 속도에 따라 결정됩니다.

클라이언트와 서비스 수준 모두에서 성능을 고려한 경우 EMS 시스템이 잘 작동합니다. -에 "입력"항목은 (EMS 대상 교량으로) 다리를 여러 부서 큐

을에

옵션 2 대

옵션 1 : 나는 당신의 질문을 이해하면

Answer 2

, 당신은 비교하려는 - 모든 부서의 동일한 입력 주제에 대한 정적 영구 가입

다음은 앞에서 본 차이점입니다. 대기열 및 고정 영구 가입자를 다른 구성 파일에 구성해야합니다 대기열 설정에 대한 유연성이 훨씬 더 큽니다. 저장소 (fs 위치), 지속성 옵션, 만료 옵션 등을 선택할 수 있습니다. 대기열은 여러 인스턴스 (한 홉 제한)에서 라우팅 될 수 있으며 항목도 라우팅 될 수 있습니다 정적 영구 가입은 대상 서버에서 로컬로 설정해야합니다.

요약하면 거의 동일하지만 대기열은 정적 영구 가입보다 많은 구성 옵션을 제공합니다.

실험 참고 : 정적 영구 가입이 대상 큐의 일부 속성을 "빌려"합니까? 예 : 주제와 동일한 상점을 사용합니까?

마지막 참고 사항 : 비 정적 영구 가입 (클라이언트가 아닌 구성 요소가없는 구성)은 더 주목할만한 기능 일 수 있습니다. 그러나 찾고있는 것은 아닙니다. 정적 내구성이 대기열과 매우 유사하여 시간을 할애 할 가치가 없을 수도 있습니다.