팁코 EMS 대 MSMQ 대 MQ

Question

이 질문에 대한 답을 찾을 수 없습니다, 그래서이를 시작하고 싶습니다 :

팁코 EMS 대 MSMQ 대 MQ.

이러한 3 가지 기술을 어떻게 비교합니까? 어느 것이 더 좋으며 어떤 종류의 시나리오입니까? 특히 SOA 환경 (.NET + WCF)에서 이러한 시나리오 중 하나를 사용하는 것이 좋습니다. 시나리오는 시간이 지나면 성숙해질 것입니다.

성능에 대한 추가 관심사가 하나 있습니다. 이는 중요합니다. 따라서, 선택이 주어지면, 성능은 중요한 우선 순위입니다.

분명히 알 수있는 비교표가 있어야합니다.

감사합니다.

편집는 :

나는 두 개의 매개 변수에 집중하고있다 : 성능과 확장 성을. 확장 성 - 지원되는 동시 사용자 수와 관련하여 이러한 기술을 어떻게 비교합니까? 더 많은 사용자를 지원할 수 있습니까? 시나리오가 중요하지 않은 경우 모든 시나리오에서 지원되는 시나리오를 선택해 보겠습니다. 간단한 대기열. 성능 - 정확히 동일한 시나리오에서 더 빠르게 수행됩니까?

Answer 1

WCF를 사용하고 싶지 않은 경우 WCF를 사용하려면 정말로 중요합니다. 직접 API를 사용할 때만 대부분을 얻을 수 있습니다.

MSMQ - MS 기술은 모든 Windows 설치와 함께 설치됩니다. 대기열을 지원하는 전송 기술 일뿐입니다.

Tibco EMS - 대기열과 주제를 모두 지원하는 Tibco 기술 (게시/구독). 엔터프라이즈 시나리오에 비싸고 더 비쌉니다. 전체 SOA 솔루션 (Tibco ActiveMatrix 제품군)을 구현하려면 다른 Tibco 도구와 기술도 필요합니다. .NET과 WCF는 Java 세계를 위해 더 많이 설계된이 인프라에 연결된 앱일 것입니다. 비 Windows 플랫폼에서도 실행되며 Tibco Business Works와 함께 많은 LOB 응용 프로그램에 커넥터 (어댑터)를 제공합니다. Tibco 제품 용 API는 마음에 들지만 도구의 UI가 마음에 들지 않습니다.

IBM MQ - 대기열을 지원하는 IBM 기술 및 주제를 어떻게 든 모방합니다 (게시/등록). 다시 말해서 메인 프레임이 관련되어있는 엔터프라이즈 시나리오 (가장 큰 MQ 이점)에 더 적합한 고가의 상용 솔루션으로, "어디에서나"실행됩니다. 그러나 그것이 장점의 끝입니다. Java와 .NET 모두를위한 API는 끔찍합니다. .NET API는 버그로 가득 차서 예상대로 작동하지 않습니다. IBM 등 설치 다른 MQ 클라이언트와 컴퓨터에 클라이언트 응용 프로그램을 이동할 때 끔찍한 문제에 이르게 .NET 라이브러리 버전을 이해하지 못하는

편집 :

몇 가지 질문/어떤 문제에 대한 의견이 있었다 MQ가 있습니까? 몇 가지 예를 들면 my MQ questions을 확인할 수 있습니다. 모든 문제가 실제로 문제가되는 것은 아니지만 버그를 직접 지적하는 사례는 거의 없을 것입니다. 이러한 문제는 새로운 MQ 클라이언트 버전에서 이미 해결 될 수 있지만 다른 것이 없다는 것을 의미하지는 않습니다. 일반적으로 MQ .NET API는 내가 사용 해본 라이브러리 중 가장 실망 스럽습니다.

반면에 메시지를 보내고 받고 특별한 것을하거나 낮은 수준의 기능을 사용할 계획이 없다면 괜찮을 것입니다. 결국 API는 잠시 동안 사용되며 회귀 버그를 치기에 충분하지 않은 경우 일반적인 사용 사례가 작동해야합니다.

Answer 2

다시는 메인 프레임이

당신이 메인 프레임을 언급 한 이유는 확실하지

를 참여 기업 시나리오 고가의 상용 솔루션 더 적합합니다. 많은 MQ 엔터프라이즈 고객은 MQ 엔터프라이즈를 가지고 있지 않습니다.

IBM MQ - IBM 기술 큐를 지원하고 또한 어떻게 든 기본 기능으로 술집/하위 항목을 주제 (게시/가입)

MQ의 V7.0.0 (2008 년 발표)를 에뮬레이트하고 이후 지원 , 관련된 에뮬레이션이 없습니다.

Java 및 .NET 용 API는 끔찍합니다.

Java 및 JMS 용 MQ 클래스는 10 년 이상 발전했으며 수천 개의 기업에서 많이 사용됩니다.

.NET API에 버그가 있으며 예상대로 작동하지 않습니다.

.Net API는 몇 가지 주요 MQ 릴리스보다 7 년 이상 계속되었습니다. 나는 명백한 버그가 지금까지 흔들릴 것이라고 생각한다.

성능 및 확장 성의 두 가지 매개 변수에 집중되었습니다.

MQ의 확장 성은 무제한입니다. 튜닝을하지 않아도 성능은 매우 좋습니다.

Answer 3

MQ는 많은 메인 프레임과 통합해야하는 경우에만 가장 적합합니다. Pub/Sub가 제대로 구현되지 않았고 많은 API가 '이상하게 사용됩니다'.

모든 응용 프로그램이 Windows 인 경우 MSMQ를 선택하는 것이 좋지만 Unix 또는 Java 환경에 연결할 수는 없습니다.

전체 Java 커뮤니티가 JMS에서 표준화되어 있으므로 비 Windows 응용 프로그램에 연결하려는 경우 TIBCO EMS를 사용하는 것이 좋습니다.

Answer 4

간단한 통합 시나리오 (예 : 2 개의 응용 프로그램이 지점 간 방식으로 상호 작용하는 경우)에는 차이가 없습니다. 응용 프로그램 내의 각 기술에 대한 지원을 확인하는 것이 좋습니다. 그리고 이러한 유형의 시나리오에서는 메시징 시간이 주요 문제가 아니어야하므로 성능에 대해 걱정할 필요가 없습니다. 반면, 실제 선택은 전체 엔터프라이즈 통합을위한 목표 모델을 기반으로합니다. 예 : - 데이터 변환, 프로토콜 매핑 등과 같은 중재 기능을 수행하고 있습니까? - 지점 간 방식으로 시스템을 통합합니까, 아니면 허브/ESB를 고려할 수 있습니까? - 통합 시나리오 (인증, 인증, 감사, 암호화, 인증서 교환 등)에서 보안 측면을 다룰 것입니다 ...등) 마지막으로 그러한 비전을 가지고 있으면 설계에 대한 실제 제약 조건을 더 잘 이해할 수 있습니다. 개인적으로 복잡한 통합 시나리오가 필요하지 않으며 솔루션에 돈을 쓰지 않을 경우에만 WCF에 참여할 것입니다. SOA를위한 기반을 구축한다면 IBM에 갈 것입니다. 정의 된 범위로 Java 기반 통합을 계획하고 있다면 Tibco로 갈 것입니다.