Ưu điểm của một tin nhắn qua mạng

Câu hỏi của tôi đến từ một quan điểm hơi vô học.

Các giá trị tương đối của hệ thống " truyền thông điệp " so với hệ thống " dựa trên sự kiện " là gì.

Tại sao người ta sẽ chọn cái này hơn cái kia? Điểm mạnh và điểm yếu của họ là gì?

Tôi muốn biết không chỉ là "trên lý thuyết", mà còn "trong thực tế".

CHỈNH SỬA:

Vấn đề cụ thể :

Tôi muốn xây dựng hệ thống các thành phần có khả năng cắm hoạt động như các dịch vụ quy mô nhỏ (mỗi dịch vụ thực hiện một số nhiệm vụ nhỏ và hoặc cung cấp một số thông tin).

Các dịch vụ có thể:

• được xếp lớp sao cho đầu ra của một dịch vụ có thể đóng vai trò là một trong những đầu vào cho dịch vụ khác
• có hệ thống phân cấp ngăn chặn để một dịch vụ có thể được chứa bởi một dịch vụ khác mà không có mối quan hệ đầu vào-đầu ra cụ thể như được đề cập trong câu trước

Mục tiêu của hệ thống là chuyển một luồng các sự kiện cấp thấp trong hệ thống khác thành thông tin và chức năng cấp cao hơn, ngoài ra còn cung cấp một kênh quay lại hệ thống khác cung cấp một chuỗi các sự kiện.

Tôi có thể cung cấp thêm chi tiết nếu điều này là không đủ.

Sau khi nhìn xung quanh một số chi tiết. Điều này và điều này có lẽ mô tả tình hình của tôi tốt hơn.

Điều này có vẻ phù hợp với hoàn cảnh của tôi: http://akka.io/

Theo kinh nghiệm của tôi, sự khác biệt cụ thể duy nhất là trong hầu hết các hệ thống chuyển tin nhắn, người gửi tin nhắn đều biết (và thường tuyên bố) ai là người nhận tin nhắn.

Vì vậy, thay vì đưa ra một sự kiện và bất kỳ ai đăng ký tham gia sự kiện đó, người gửi sẽ xác định một số id của người nhận dự định hoặc nhóm người nhận logic và sau đó gửi tin nhắn trực tiếp đến họ hoặc thông qua người môi giới tin nhắn (mặc dù HĐH có thể được xem như một nhà môi giới tin nhắn trong một hệ thống dựa trên sự kiện).

Rõ ràng có trường hợp phân luồng mà Telastyn đề cập đến khi triển khai các sự kiện của C #, nhưng bạn vẫn có thể tạo mô hình pub / sub của riêng mình thực thi trên các luồng khác nhau.

Đây là táo và cam:

Một hệ thống hướng sự kiện có thể phản ứng với các sự kiện được truyền dưới dạng tin nhắn (tin nhắn trong ngữ cảnh này được ngụ ý là dữ liệu không chia sẻ bất biến ) khi các sự kiện được nêu ra. Đây là một thiết kế kiến ​​trúc hoàn toàn.

Một hệ thống Truyền tin nhắn có thể được điều khiển bởi các sự kiện tạo và truyền tin nhắn. Đây là một thiết kế thực hiện hoàn toàn.

Cả hai không loại trừ lẫn nhau.

Ví dụ: Bạn có thể triển khai thiết kế hướng sự kiện bằng bất kỳ ngôn ngữ nào cũng có thể là môi trường truyền thông điệp như trong Erlang.

Phần lớn sự nhầm lẫn giữa "truyền thông điệp" và "dựa trên sự kiện" có liên quan đến kiến ​​trúc so với chi tiết triển khai. Tôi đã thấy (và bằng văn bản) các hệ thống điều khiển sự kiện thực sự sử dụng các thông báo do OS cung cấp để triển khai. Tôi đoán bạn đang thực sự đề cập đến ý tưởng kiến ​​trúc.

Vì nhiều người đã chỉ ra "thông điệp truyền qua" và "dựa trên sự kiện" không thực sự đủ tốt để tránh sự mơ hồ.

Các giá trị tương đối của hệ thống "truyền thông điệp" so với hệ thống "dựa trên sự kiện" là gì.

Thông qua

Tôi sẽ bắt đầu bằng cách đoán rằng khi bạn nói một hệ thống "tin nhắn đi qua", bạn đang nói về một hệ thống mà một đối tượng dành một tin nhắn cho một đối tượng cụ thể khác. Khi tôi nghĩ về một hệ thống dựa trên mô hình này, tôi thường nghĩ về một hệ thống trong đó một đối tượng phát hiện ra một cái gì đó biết ai cần được nói về điều gì đó. (Tôi không chỉ định làm thế nào nó biết, chỉ là nó biết.)

Kiểu kiến ​​trúc này rất tốt cho các hệ thống mà các nhà sản xuất và người tiêu dùng nổi tiếng. Nhà sản xuất tin nhắn biết ai phải nhận nó hoặc người tiêu dùng phải biết ai sẽ nhận được tin nhắn.

Nếu bạn đang viết một ứng dụng ngân hàng, người ta sẽ mong đợi bạn thực sự muốn biết bạn đang gửi giao dịch của mình cho ai và họ đến từ đâu.

Dựa trên sự kiện

Hệ thống khác mà tôi tin rằng bạn đang nghĩ đến khi bạn nói một hệ thống "dựa trên sự kiện" là một hệ thống mà một đối tượng đưa ra một "sự kiện" mà không biết ai (nếu có ai) sẽ phản hồi.

Kiểu kiến ​​trúc hướng sự kiện này rất tốt cho các hệ thống mà nhà sản xuất không quan tâm đến việc ai tiêu thụ sự kiện hoặc nơi người tiêu dùng không thực sự quan tâm đến ai đã tạo ra sự kiện.

Nói chung, các hệ thống này rất tuyệt vời khi bạn không biết mối quan hệ giữa người tiêu dùng và nhà sản xuất và nơi bạn mong đợi mối quan hệ sẽ năng động.

Một hệ thống tôi đã sử dụng hệ thống này là một hệ thống trong đó ứng dụng thực sự bao gồm các mô-đun (trình cắm) được cấu hình động được tải trong thời gian chạy. Khi một mô-đun được tải, nó sẽ đăng ký cho các sự kiện mà nó quan tâm. Kết quả là một hệ thống trong đó rất dễ dàng để mở rộng chức năng.

Chẳng hạn, giả sử điều kiện Một EA Sự kiện được nêu lên thường gây ra phản ứng RA. Đối tượng gây ra phản hồi RA chỉ cần đăng ký để nhận EA sự kiện và hành động theo nó khi nó đến. Bây giờ, giả sử chúng tôi muốn thêm một phản hồi mới cho EA, được gọi là RA_1. Để làm điều này, chúng tôi chỉ cần thêm một đối tượng mới tìm EA và tạo phản hồi RA_1.

Dưới đây là một vài ví dụ (sử dụng thuật ngữ của bạn):

• "Tin nhắn đi qua" : Sếp của bạn bảo bạn điền vào bảng chấm công của bạn.
• "hướng sự kiện" : Thư ký bộ phận gửi email cho mọi người nhắc nhở họ rằng bảng chấm công của họ là do ngày hôm nay.

Trong SOA bạn có khái niệm về Thông điệp lệnh và Thông báo sự kiện . Có một nhu cầu cho cả hai.

Tuy nhiên, các thông báo lệnh có khớp nối hành vi cao hơn với điểm cuối của người nhận vì nó rõ ràng yêu cầu điểm cuối thực hiện một số chức năng. Nó không cần phải được gắn với một điểm cuối cụ thể (điều này có thể được cấu hình hoặc xác định khi chạy).

Mặt khác, tin nhắn sự kiện không có khớp nối hành vi giữa người gửi / người nhận vì người gửi không biết người nhận sẽ làm gì với tin nhắn. Nó thậm chí không biết nếu có ai đăng ký vào sự kiện này.

Đối với một số nền tảng khác, bạn được chào đón để xem qua trang web xe buýt dịch vụ của tôi ở đây: http://www.servicebus.co.za

Theo kinh nghiệm của tôi, sự khác biệt lớn nhất giữa hai loại này là các tin nhắn trong một hệ thống truyền tin nhắn là các đối tượng hạng nhất, trong khi các sự kiện trong các hệ thống hướng sự kiện thì đơn giản hơn nhiều. Tin nhắn có xu hướng mang thông tin và thông tin đó có thể được chuyển đổi, lưu trữ, truy xuất và gửi lại. Các sự kiện có xu hướng mang các bit thông tin nhỏ hơn, tập trung hơn được tiêu thụ ngay lập tức và sau đó bị loại bỏ. Chúng có xu hướng được gửi trực tiếp từ một nguồn sự kiện đến một hoặc nhiều nhóm sự kiện, trong khi các tin nhắn thường được định tuyến giữa một số người nhận và có thể được chuyển đổi / dịch / bọc hoặc xử lý tại bất kỳ điểm nào trên tuyến. Họ sử dụng các công nghệ tương tự (xe buýt, hàng đợi, bộ lọc, v.v.) nhưng chúng thực sự là những con thú khác nhau.

Từ quan điểm thực tế, các thông điệp thường được triển khai dưới dạng một khối bộ nhớ được sao chép từ không gian địa chỉ của người gửi sang không gian địa chỉ của người nhận (hoặc được thực thi thành một đối tượng bất biến) để bạn có được sự an toàn của luồng ngay lập tức.

Trong một số trường hợp tin nhắn chuyển qua người gửi phải chỉ định người nhận, nhưng trong một số trường hợp khác, bạn chỉ có thể gửi tin nhắn đến hộp thư và bất kỳ ai cũng có thể nghe tin nhắn trong hộp thư đó, do đó, có thể linh hoạt trong việc ghép chúng chặt chẽ như thế nào. Tất nhiên, bạn có thể có một hộp thư trong đó hợp đồng là "Tôi sẽ đăng một tin nhắn đến hộp thư này khi sự kiện này xảy ra."

Trong trường hợp các sự kiện bạn đang đăng ký một đại biểu hoặc gọi lại với chủ sở hữu của sự kiện. Trong lập trình hướng đối tượng, điều này có nghĩa là chủ sở hữu sự kiện giữ một tham chiếu đến đối tượng đã đăng ký để nhận sự kiện. Điều này đôi khi có thể dẫn đến những cơn ác mộng sổ sách, cố gắng tìm ra đối tượng nào quên để hủy đăng ký xử lý sự kiện của họ. Điều đó có nghĩa là mục tiêu không thể được thu gom rác cho đến khi chủ sở hữu sự kiện là rác được thu thập, ngay cả khi mục tiêu không còn làm gì hữu ích.

Cá nhân tôi sẽ chọn tin nhắn chuyển qua các sự kiện, trừ trường hợp các sự kiện bắt buộc đối với bạn, chẳng hạn như lập trình GUI của Windows, v.v.