2012-01-26 25 views
7

Tôi đang phát triển một hệ thống để hỗ trợ nhận thông tin trạng thái từ nhiều loại phần cứng khác nhau. Mỗi phần cứng đều báo cáo cùng một thông tin trạng thái (Latitude, Longitude), nhưng mỗi loại phần cứng sử dụng một giao thức duy nhất để báo cáo thông tin này. Vì lý do này, tôi có nhiều dịch vụ, một cho mỗi loại thiết bị, mà lắng nghe và phân tích cú pháp giao thức của thiết bị đó. Tôi muốn cho mỗi người trong số các dịch vụ này để công bố các thông tin trạng thái sử dụng một thông điệp chung:Điểm cuối NServiceBus có thể đăng ký với nhiều nhà xuất bản cùng một thông điệp không?

public interface IPositionMessage : IMessage 
{ 
    string UnitName { get; set; } 
    double Latitude { get; set; } 
    double Longitude { get; set; } 
} 

Tôi không có lỗi khi thiết lập dịch vụ đầu tiên của tôi, nhưng bây giờ mà tôi đang thiết lập dịch vụ thứ hai của tôi Tôi thấy rằng người đăng ký của tôi không thể đăng ký cùng một tin nhắn từ nhiều nhà xuất bản.

Trong một question on the NServiceBus yahoo group tương tự, giải pháp được đề xuất là chuyển đổi thông báo chung thành lệnh và sử dụng Bus.Gửi chứ không phải Bus.Publish. Tôi không cảm thấy có ý nghĩa trong kịch bản này vì điều thực sự xảy ra là một sự kiện (đơn vị đã đến một vị trí và đang báo cáo vị trí mới). Nếu tôi chuyển đổi lệnh này thành lệnh, tôi sẽ cần phải biết trước tất cả những người đăng ký tiềm năng cho sự kiện này mà tôi không biết. Một giải pháp khác có thể là tạo ra một tập hợp/tái xuất bản mà mỗi dịch vụ sẽ Bus.Send to, và sau đó thông điệp sẽ được tái bản từ một nhà xuất bản duy nhất. Điều này có vẻ như một nút cổ chai không cần thiết.

Có phương pháp nào để cho phép người đăng ký đăng ký cùng một thông điệp từ nhiều nhà xuất bản không?

+0

AFAIK, thực tiễn không tốt để xuất bản từ nhiều nhà xuất bản LOGICAL. –

+0

Theo quan điểm của tôi, mỗi dịch vụ là một nút vật lý tham gia như là một phần của một nhà xuất bản hợp lý. Kịch bản của tôi sẽ không khác nếu tôi có một dịch vụ triển khai thực hiện và tôi cần phải mở rộng quy mô để cài đặt nó trên một máy thứ hai. – JadeMason

Trả lời

12

Đây là một trong những thứ "thành công" của SOA mà Udi cố gắng làm cho bạn khó có thể thoát khỏi.

Các tính hai mặt cơ bản là thế này:

  • lệnh phải được gửi bởi nhiều khách hàng và nhận được một nguồn có thẩm quyền duy nhất.
  • Sự kiện phải được xuất bản bởi một nguồn có thẩm quyền duy nhất và được nhiều khách hàng nhận.

Nhưng nguồn độc quyền duy nhất này là nguồn có thẩm quyền LOGICAL. Điểm quan trọng là nếu tôi quan tâm đến tất cả dữ liệu IPositionMessage, sẽ chỉ có một điểm lôgic (queuename @ servername), nơi tôi gửi yêu cầu đăng ký của mình.

Điều đó không có nghĩa là nhiều bộ xử lý vật lý trong cùng một dịch vụ logic không thể xuất bản cùng một loại sự kiện, miễn là chúng xuất bản là có thẩm quyền.

Điều quan trọng là tất cả bộ xử lý vật lý của bạn phải chia sẻ cùng một bộ nhớ đăng ký. Trong thực tế, bạn có thể muốn có một điểm cuối vật lý chỉ xử lý các yêu cầu đăng ký và không xử lý gì cả. Nó chỉ nhận được yêu cầu đăng ký (QueueX @ ServerY quan tâm đến IPositionMessage) và cập nhật bộ nhớ đăng ký.

Sau đó, mỗi bộ xử lý, được gắn với cùng một bộ nhớ đăng ký, sẽ xuất bản IPositionMessage và sẽ thấy rằng QueueX @ ServerY quan tâm và gửi bản sao của sự kiện đến vị trí đó.

Điều này sẽ hơi khó nuốt trong môi trường dev với tiểu sử NServiceBus.Lite đang chạy, vì bộ nhớ đăng ký trong bộ nhớ theo mặc định, vì vậy rõ ràng nó sẽ không được chia sẻ và sẽ không xuất hiện để chạy chính xác , vì vậy hãy sẵn sàng cho điều đó.

+0

Bạn đã đánh trực tiếp vào cuộc đấu tranh của tôi, đó là tôi hy vọng sẽ tìm cách cho mỗi nút vật lý để sử dụng hàng đợi đầu vào độc lập (để mỗi giao thức thực hiện có thể nhận được các lệnh cấu hình duy nhất) và cùng một lúc các nút này hoạt động như một nút vật lý của một nhà xuất bản hợp lý (mỗi nút là nhà xuất bản có thẩm quyền của sự kiện đó). Tôi đã tạo một "republisher" rất đơn giản để xử lý thông điệp được xuất bản và xuất bản nó cho tất cả các thuê bao. Lúc đầu đỏ mặt, nó vẫn cảm thấy như một hack, nhưng tôi có thể thấy làm thế nào điều này tách mối quan tâm và vẫn có thể quy mô. – JadeMason

+0

Có ví dụ về cách định cấu hình mọi thứ theo cách này không? Tôi là một chút bối rối như thế nào để đi về điều này. –

+0

Đừng bận tâm: p Khá thẳng về phía trước. Nó chỉ cần được thiết lập để tất cả các điểm cuối có liên quan đang xem xét cùng một cơ sở dữ liệu Raven DB. Tôi sẽ giả định rằng trong trường hợp lưu trữ MSMQ nó woul dneed để trỏ đến cùng một hàng đợi. –

1

Mặc dù có thể đăng ký nhiều nhà xuất bản (điều này có thể được định cấu hình trong <unicastBusConifg />), tôi đồng ý với nhóm người dùng rằng điều này sau đó sẽ trở thành gửi hợp lý thay vì xuất bản.

Tôi không biết lý do tại sao tôi nghĩ điều này.

Các vấn đề liên quan