Tibco EMS vs MSMQ vs MQ

Question

không thể tìm thấy một câu trả lời về câu hỏi này, vì vậy tôi muốn khởi này:

Tibco EMS vs MSMQ vs MQ.

3 công nghệ này so sánh như thế nào? Cái nào tốt hơn và trong đó các loại kịch bản nào? Cụ thể, tôi nghĩ rằng để sử dụng một trong những điều này trong môi trường SOA (.NET + WCF), nơi mà kịch bản sẽ trưởng thành theo thời gian.

Tôi có một lợi ích cụ thể khác về hiệu suất, điều quan trọng cần đề cập. Vì vậy, nếu được lựa chọn, hiệu suất là một ưu tiên quan trọng.

Tôi sẽ đánh giá cao việc có bảng so sánh để có hình ảnh rõ ràng.

Cảm ơn!

EDIT:

Tôi đang tập trung vào hai tham số: hiệu suất và khả năng mở rộng. Khả năng mở rộng - các công nghệ này so sánh như thế nào về số lượng người dùng đồng thời được hỗ trợ? có thể hỗ trợ nhiều người dùng hơn? kịch bản không quan trọng, hãy chọn kịch bản được hỗ trợ bởi tất cả chúng - ví dụ: hàng đợi đơn giản. Hiệu suất - trong chính xác các trường hợp tương tự, hoạt động nhanh hơn?

Answer 1

Nếu bạn muốn sử dụng WCF hơn là không thực sự quan trọng. Bạn sẽ nhận được hầu hết trong số họ chỉ khi bạn sử dụng API trực tiếp của họ.

MSMQ - Công nghệ MS được cài đặt với mọi cài đặt Windows. Nó chỉ là công nghệ vận tải với sự hỗ trợ cho hàng đợi.

Tibco EMS - công nghệ Tibco hỗ trợ cả hàng đợi và chủ đề (xuất bản/đăng ký). Nó là tốn kém và phù hợp hơn cho các kịch bản doanh nghiệp. Bạn có lẽ sẽ cần các công cụ và công nghệ Tibco khác để triển khai giải pháp SOA đầy đủ (bộ sản phẩm Tibco ActiveMatrix). .NET và WCF sẽ chỉ là các ứng dụng được kết nối với cơ sở hạ tầng này, được thiết kế nhiều hơn cho thế giới Java. Nó cũng chạy trên các nền tảng không phải của Windows và cùng với Tibco Business Works nó cung cấp các kết nối (bộ điều hợp) cho nhiều ứng dụng LOB. Tôi thích API cho các sản phẩm Tibco nhưng tôi thực sự không thích giao diện người dùng của các công cụ của họ.

IBM MQ - công nghệ IBM hỗ trợ hàng đợi và nó cũng bằng cách nào đó mô phỏng các chủ đề (xuất bản/đăng ký). Một lần nữa nó là giải pháp thương mại đắt tiền phù hợp hơn cho các kịch bản doanh nghiệp mà các khung hình chính có liên quan - đó là lợi thế MQ lớn nhất - nó chạy "ở khắp mọi nơi". Nhưng đó là kết thúc của lợi thế. API cho cả Java và .NET là khủng khiếp. .NET API có đầy đủ các lỗi và nó không hoạt động như mong đợi. IBM không hiểu thư viện .NET phiên bản dẫn đến các vấn đề khủng khiếp khi di chuyển ứng dụng khách hàng của bạn để máy với khách hàng MQ khác nhau được cài đặt vv

Edit:

Đã có nhiều câu hỏi/ý kiến ​​về những vấn đề MQ có? Như một vài ví dụ bạn có thể kiểm tra my MQ questions. Không phải mọi câu hỏi thực sự là một vấn đề nhưng bạn sẽ thấy vài trong số họ chỉ trực tiếp đến lỗi. Những vấn đề đó có thể đã được sửa trong các phiên bản máy khách MQ mới nhưng điều đó không có nghĩa là không có sự khác. Nói chung tôi thấy MQ .NET API là thư viện bực bội nhất mà tôi từng sử dụng - nó thậm chí còn bị đánh bại bởi SharePoint.

Mặt khác, nếu bạn chỉ cần gửi và nhận một số tin nhắn và không định làm bất cứ điều gì đặc biệt hoặc sử dụng các tính năng cấp thấp, bạn nên OK. Vào cuối API được sử dụng trong một thời gian và các trường hợp sử dụng phổ biến sẽ hoạt động - nếu bạn không đủ hạnh phúc để đạt các lỗi hồi quy.

Answer 2

Một lần nữa nó là giải pháp thương mại đắt tiền phù hợp hơn cho các kịch bản doanh nghiệp nơi mainframe có liên quan đến

Không chắc lý do tại sao bạn đề cập đến máy tính lớn. Nhiều khách hàng doanh nghiệp MQ không có chúng.

IBM MQ - công nghệ IBM hỗ trợ hàng đợi và nó cũng phần nào mô phỏng chủ đề (xuất bản/đăng ký)

MQ phiên bản 7.0.0 (phát hành năm 2008) và trở đi hỗ trợ pub/sub chủ đề như một tính năng bản địa , không có thi đua nào liên quan.

API cho cả Java và .NET là khủng khiếp.

Lớp MQ cho Java và JMS đã phát triển hơn 10 năm và được hàng nghìn doanh nghiệp sử dụng.

API .NET có đầy đủ các lỗi và không hoạt động như mong đợi.

API .Net đã có từ 7 năm trở lên trong một vài phiên bản chính của MQ. Tôi sẽ tưởng tượng rằng các lỗi rõ ràng sẽ bị lung lay ngay bây giờ.

Tôi tập trung vào hai tham số: hiệu suất và khả năng mở rộng.

MQ có khả năng mở rộng không giới hạn. Hiệu suất là rất tốt ngay cả khi không có điều chỉnh.

Answer 3

MQ chỉ tốt nhất nếu bạn cần tích hợp với nhiều khung hình chính. Pub/Sub được thực hiện kém và nhiều API là 'lạ để sử dụng'.

Nếu tất cả các ứng dụng của bạn là Windows, MSMQ có thể là một lựa chọn tốt, nhưng sẽ rất khó để kết nối với thế giới Unix hoặc Java.

Toàn bộ cộng đồng Java được tiêu chuẩn hóa trên JMS vì vậy TIBCO EMS là một lựa chọn tốt nếu bạn muốn kết nối các ứng dụng không phải của Windows.

Answer 4

Đối với kịch bản tích hợp đơn giản - tức là 2 ứng dụng tương tác theo cách điểm đến điểm, không có sự khác biệt nào ở đó. Bạn sẽ kiểm tra tốt hơn sự hỗ trợ của từng công nghệ trong ứng dụng của bạn. Và trong loại kịch bản đó, bạn không nên lo lắng về hiệu suất vì thời gian nhắn tin không phải là vấn đề chính. Mặt khác, lựa chọn thực sự sẽ dựa trên mô hình mục tiêu để tích hợp toàn bộ doanh nghiệp của bạn. Ví dụ: - Bạn có đang thực hiện bất kỳ chức năng dàn xếp nào không - ví dụ: chuyển đổi dữ liệu, ánh xạ giao thức ... vn - Bạn sẽ tích hợp hệ thống theo điểm hay bạn có thể cân nhắc có Hub/ESB? - Bạn sẽ bao gồm các khía cạnh bảo mật trong kịch bản tích hợp của mình (Cấp phép, xác thực, kiểm tra, mã hóa, trao đổi chứng chỉ ...vv) Cuối cùng có tầm nhìn như vậy sẽ giúp bạn hiểu rõ hơn về những hạn chế thực sự mà bạn đã thiết kế cho mình. Cá nhân, tôi sẽ đi WCF chỉ khi tôi không mong đợi các kịch bản tích hợp phức tạp và tôi không sẵn sàng chi tiền cho giải pháp. Và tôi sẽ đi cho IBM nếu tôi xây dựng nền tảng cho SOA. Và sẽ đi đến Tibco nếu tôi đang lập kế hoạch tích hợp dựa trên Java với phạm vi được xác định.