Sự khác biệt giữa một Nhà môi giới Tin nhắn và một ESB

Question

Tôi đã trải qua các câu hỏi/bài viết khác nhau về Người môi giới Thông báo và ESB (Ngay cả trên stackoverflow). Vẫn không phải là một đầu mối vì sự khác biệt rõ ràng giữa CLEAR và một ESB là gì? Bây giờ tôi đang cố gắng so sánh các sản phẩm, Websphere Broker và Mule ESB !!

Thứ nhất, là (mọi phiên bản) Webshere Broker a ESB? Các sản phẩm IBM của chúng tôi tuyên bố nó là một ESB! (Tôi không ngạc nhiên về điều đó).

Thông tin giới hạn của tôi cho tôi biết rằng Nhà môi giới thư hoạt động trên mô hình HUB-SPOKE. Tuy nhiên ESB hoạt động trên kiến ​​trúc bus. Bây giờ những gì trên trái đất là nghĩa vụ phải có nghĩa là gì? Tôi đã đọc hơn nếu HUB thất bại (không có sẵn tôi đoán) sau đó các nhà môi giới hoàn toàn thất bại. Đó không phải là trường hợp của một ESB (Vì vậy, những kẻ nói). Những gì tôi không hiểu ở đây là "Nếu BUS" thất bại thì sao?

Bây giờ các công cụ thông thường về ESB và môi giới là, chúng cung cấp định tuyến, chuyển đổi, dàn nhạc vv .. Vì vậy, nếu cả hai đều cung cấp, thì tại sao tôi chọn cái kia.

Khu vực xung đột khác liên quan đến TRANSFORMATION. ESB có tạo điều kiện thuận lợi cho nó theo một cách khác khi so sánh với Người môi giới thư không? Tôi thực sự rất thích cái nhìn sâu sắc về điều này.

Bây giờ, hãy nói về quy mô HORIZONTAL. Ai vượt trội hơn ai? Hoặc cả hai đều có thể mở rộng về mặt độ phức tạp (hoặc bất kỳ yếu tố nào khác). Ofcourse chi phí khôn ngoan, Webshpere môi giới là sẽ tính phí cho bạn cho mỗi hộp (hãy để một mình mỗi CPU). Tôi tin rằng, ngay cả MULE ESB thương mại cũng không làm điều đó. Bỏ qua phần chi phí của nó, những tác động của việc mở rộng quy mô ESB và mở rộng môi giới thông điệp là gì. Tôi tình cờ biết bạn có thể mở rộng lên Cấp dịch vụ trong ESB. Điều này có thể xảy ra trong một Nhà môi giới thông điệp không?

Answer 1

Bạn có thể sử dụng nhà môi giới chuyển đổi không có xe buýt dịch vụ và ngược lại. Về mặt các sản phẩm cụ thể, tôi không nghĩ bất kỳ một sản phẩm nào hoàn toàn là một hoặc loại khác vì cách thức bổ sung cho nhau. Một số sản phẩm mạnh hơn trong một khu vực, khác mạnh hơn trong một khu vực khác. Có lẽ một sự lựa chọn cần phải được thực hiện dựa trên đó chức năng tốt nhất bao gồm một vấn đề cá nhân.

Một nhà môi giới có thể có "khối lego" tích hợp sẵn để xây dựng chuỗi chuyển đổi hơn so với sản phẩm ESB. Một nhà môi giới được đưa vào hoạt động với tư cách là một ESB có thể bị nghiền nát dưới tải và không có quy mô tốt, hoặc có thể thiếu các nhật ký và công cụ mạnh mẽ để xử lý các tạp chí.

Một số ESB cho phép cập nhật cơ sở dữ liệu được cuộn lại và hàng đợi được phát lại vào ứng dụng đã sửa khi một lỗi nghiêm trọng trong logic đã được phát hiện và sửa lỗi.Tôi không nghĩ rằng hầu hết các nhà môi giới tích hợp mức hỗ trợ giao dịch đó. Đối với điều này để làm việc tại tất cả các "giao dịch" của bạn gần như phải là sự kiện kinh doanh (bán hàng, đổi mới, thay đổi quyền sở hữu, vv) thay vì một cái gì đó giống như RPCish "cập nhật cơ sở dữ liệu."

Answer 2

Tuyên bố từ chối trách nhiệm: Tôi là chuyên gia tư vấn của IBM và chuyên về WebSphere ESB. Nhận xét này không được để lại trong bất kỳ khả năng chính thức nào.

Một ESB có nhiều mô hình kiến ​​trúc hoặc khái niệm hơn là một sản phẩm - một cách rộng rãi, một cách dựa trên dịch vụ kỹ thuật ghép nối lỏng lẻo. Định nghĩa của nó được chiến đấu và không chính xác được đặt trong đá. Nói chung, một ESB được thiết lập các dịch vụ không liên quan (theo nghĩa kỹ thuật) - chúng phơi bày các giao diện và chúng tiêu thụ chúng từ các dịch vụ khác. Nói chung không có một trung tâm và nói về kiến ​​trúc liên quan, mặc dù có thể được.

IBM chắc chắn tiếp thị cả WebSphere Message Broker và WebSphere ESB làm sản phẩm giúp dễ dàng xây dựng ESB (cùng với thiết bị phần cứng DataPower). Họ có nguồn gốc công nghệ khác nhau, nhưng có một số chồng chéo trong mục đích. Ngoài ra, đó không phải là để nói rằng bạn không thể xây dựng một ESB với rất nhiều thứ khác mà không có thương hiệu như là một 'sản phẩm ESB'.

Điều đó không trả lời tất cả các câu hỏi của bạn, nhưng hy vọng địa chỉ phần IBM.

Answer 3

Tôi vừa đọc bài viết này của Udi Dahan cách đây vài ngày, điều này có thể cung cấp cho bạn cái nhìn rõ ràng hơn về những gì tôi cảm thấy là một sự khác biệt cơ bản.

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

Trích dẫn:

Nguyên tắc mà chỉ có thể có một nhà xuất bản đơn cho một cho sự kiện loại là một trong những điều mà phân biệt xe buýt từ nhà môi giới, mặc dù cả hai rõ ràng cho phép bạn có nhiều người đăng ký

.. .

Thật không may, có rất nhiều công nghệ môi giới kiểu ngoài kia đang được bán trên thị trường dưới sự biểu ngữ của Enterprise Service Bus. Trong khi một số sản phẩm có khả năng được triển khai trong cả một thời trang tập trung và phân phối (đôi khi gọi là “liên” hoặc “nhúng” mode), nhiều người không thi hành “duy nhất endpoint xuất bản cho mỗi sự kiện kiểu” qui định.

Nếu không có ràng buộc này, nó chỉ là quá dễ mắc lỗi.

Hy vọng điều đó sẽ hữu ích.

Answer 4

Một Enterprise Service Bus cung cấp ba giá trị chìa khóa để kinh doanh:

1. Context- hoặc trang nội dung dựa trên định tuyến của giao dịch;
2. Chuyển đổi từ một miền thư hoặc chuyển sang miền thư khác hoặc truyền tải;
3. kết nối dịch vụ nhiều người.

ESB cung cấp dịch vụ ghép nối lỏng lẻo, cho phép dịch vụ được hoàn nguyên thành ngữ cảnh ứng dụng hoàn toàn khác với khi dịch vụ được hình dung hoặc phát triển lần đầu tiên và thúc đẩy sử dụng lại ứng dụng mà không cần phải mã hóa lại ứng dụng. WebSphere Message Broker (hoặc bây giờ được gọi là IBM Integration Bus) là một ví dụ điển hình của Bus Service của Enterprise. Đối với một ví dụ về sự đơn giản của mã mang lại sức mạnh tuyệt vời trong một vài dòng, bạn có thể xem bài đăng của tôi ở đây: http://soabus.org/viewtopic.php?f=3&t=13. Cấu trúc cơ bản bên trong thời gian chạy IIB được gọi là Cây thông điệp hợp lý (LMT). Mọi thứ mà nhà phát triển muốn làm là một số loại hoạt động trên LMT. ESQL là ngôn ngữ hiệu quả nhất mà nhà phát triển có thể sử dụng để thực hiện các hoạt động này trên LMT, mặc dù nhiều ngôn ngữ khác được hỗ trợ (ví dụ: Java, PHP, Python, v.v.) Không có sản phẩm nào khác gần với hiệu quả và dễ phát triển ESB các ứng dụng hơn IBM Integration Bus vì 90% mã hóa các ứng dụng này được thực hiện bằng cách kéo và thả các nút vào một pallet. Điều đó chỉ để lại 10% mã hóa được thực hiện bởi nhà phát triển Message Flow.Nhân tiện, WebSphere ESB đã bị ngừng lại bởi IBM và nhiều sản phẩm cạnh tranh cho IBM Integration Bus đã không thấy bất kỳ sự phát triển mới nào trên chúng trong vài năm nay. Bạn có thể xem danh sách các sản phẩm ESB khác nhau tại địa chỉ soabus.org.

Answer 5

Sự khác biệt giữa Nhà môi giới thư và ESB chủ yếu là từ 'xe buýt'.

Với tôi, Nhà môi giới thư là một quy trình (lớn) của chúng tôi chuyển đổi dữ liệu từ một cấu trúc này sang cấu trúc khác hoặc sửa đổi nội dung.

ESB là phần mềm trung gian được định hướng thư (MOM) cùng với các dịch vụ bổ sung, một trong số đó là có thể là Nhà môi giới thư. Vì vậy, một ESB có thể bao gồm một môi giới thông điệp là một trong những thành phần của nó. Một xe buýt bao gồm nhiều hơn một quy trình, nếu không tôi sẽ không gọi nó là 'xe buýt'. Bản chất của một chiếc xe buýt là có nhiều thành phần phục vụ các nhiệm vụ khác nhau, mỗi một giao tiếp qua một MOM và tôn trọng một số dạng 'định dạng dữ liệu chung'. Một xe buýt sẽ bao gồm: các ứng dụng gửi dữ liệu đến MOM, bộ điều hợp cơ sở dữ liệu, Nhà môi giới tin nhắn, cầu MOM, v.v.

Sự tách biệt là một chút dần dần, nhưng khác biệt lớn nhất giữa kiến ​​trúc Message Broker và Bus là của mức độ chi tiết. Nếu nhiệm vụ của bạn là tích hợp các ứng dụng A, B, .., Z và một vài cơ sở dữ liệu, bạn có thể làm điều này với một Nhà môi giới thông điệp lớn kết nối mọi người và mọi người. Hoặc với một ESB, nơi nhiều thành phần nhỏ đảm nhận các nhiệm vụ nhỏ. Ví dụ: một bộ điều hợp kết nối với A, một bộ chuyển đổi khác kết nối với A, một bộ chuyển đổi khác thành B (nhưng chúng không thực hiện chuyển đổi), sau đó mỗi người gửi nội dung của họ tới một (hoặc nhiều) Nhà môi giới thư, mỗi người nên được giữ càng đơn giản càng tốt - ví dụ: không phải biết về mô hình dữ liệu của 'A' hoặc 'B'. Một ESB tốt nên có định nghĩa dữ liệu chung trên xe buýt, tóm tắt từ 'sự khác biệt' của các ứng dụng riêng biệt.

CHUYỂN ĐỔI: ESB không giúp chuyển đổi, trừ khi nó đi kèm với Nhà môi giới thư. Nhưng mỗi ESB tốt nên bao gồm một môi giới thông điệp anyway. Nhà môi giới thông điệp phải là chuyên gia xe buýt của bạn để chuyển đổi, nhưng không có gì khác.

Chia tỷ lệ HORIZONTAL: nếu bạn chỉ có 3 thứ để kết nối (hiện tại và mãi mãi), có lẽ không đáng để nỗ lực để có được ESB toàn diện. Một nhà môi giới thông điệp có lợi thế là chỉ là một quá trình lớn. Bạn có thể cấu hình mọi thứ trong đó và có một vị trí trung tâm cho tất cả ánh xạ dữ liệu, lọc và định tuyến của bạn.

Nhưng nếu bạn có 30 ứng dụng để kết nối, một Nhà môi giới tin nhắn có thể sẽ ngừng nghiền. Tất nhiên bạn có thể mua nhiều trường hợp hơn, chạy những thứ thừa, v.v. nhưng bạn nên thay đổi chiến lược của mình thành công việc 'bản địa hóa'. Bộ điều hợp của mỗi ứng dụng (có thể là một cá thể của Môi giới thư nhỏ) sẽ có thể tạo và/hoặc nhận một mô hình dữ liệu chung được trừu tượng hóa (ví dụ: XML với một XSD được chia sẻ). Cũng có thể là một Message Broker trung tâm cho các nhiệm vụ chuyển đổi, nhưng trường hợp đó không nên biết về mô hình dữ liệu A hoặc B. Vì vậy, một ESB nên chuyển chế biến sang thành phần chuyên gia thay vì giữ mọi thứ ở vị trí trung tâm.