2012-03-04 4 views
12

Tôi có một ứng dụng web được lưu trữ Azure hoạt động cùng với một số trường hợp của vai trò công nhân. Hiện tại, ứng dụng web chuyển công việc cho những người lao động này bằng cách đặt tin nhắn trong hàng đợi Azure để người lao động nhận. Các công nhân chuyển trạng thái và thông điệp tiến trình trở lại bằng cách đặt tin nhắn vào hàng đợi 'phản hồi'. Hiện tại, để thông báo cho khách hàng trình duyệt của tôi đang tiến triển, tôi thực hiện các cuộc gọi định kỳ dựa trên ajax trong trình duyệt tới phương thức điều khiển MVC, lần lượt đọc hàng đợi 'phản hồi' của Azure và trả về các thư này khi quay lại trình duyệt . Rõ ràng, SignalR trông giống như một lựa chọn rất hấp dẫn cho cách tiếp cận bỏ phiếu/xếp hàng vụng về này, nhưng tôi đã tìm thấy rất ít hướng dẫn về cách thực hiện điều này khi chúng ta nói về nhiều vai trò công nhân (trái với vai trò web).) cần gửi trạng thái cho từng cá nhân hoặc tất cả khách hàng.Sử dụng SignalR trong Vai trò Công nhân Azure

SignalR.WindowsAzureServiceBus by Clemens vasters trông tuyệt vời nhưng để lại một chút cao và khô ở cuối, tức là một giải pháp mẫu tốt là thiếu.

Added bình luận: Từ đọc sách của tôi cho đến nay dường như không trực tiếp thông tin liên lạc từ nhân vai trò (như trái ngược với web vai trò) để khách hàng duyệt thông qua cách tiếp cận SignalR là có thể. Có vẻ như các công nhân phải giao tiếp với vai trò web bằng cách sử dụng hàng đợi. Điều này lần lượt buộc một cách tiếp cận bỏ phiếu tức là hàng đợi phải được thăm dò cho các thông điệp từ vai trò công nhân - việc bỏ phiếu này phải bắt nguồn từ trình duyệt xuất hiện (vòng lặp bỏ phiếu được thiết lập như thế nào trong vai trò web?)

Tóm lại, SignalR, ngay cả với phương pháp tiếp cận của Signalm.WindowsAzureServiceBus trên quy mô của Clemens Vasters, không thể xử lý truyền trực tiếp từ vai trò của nhân viên đến trình duyệt.

Mọi nhận xét của các chuyên gia sẽ được đánh giá cao.

+0

Cách nhẹ nhất mà bạn có thể chuyển tiếp vai trò công nhân => webrole => trình duyệt của khách hàng là gì? – DeepSpace101

+0

Vì bacr đã trả lời. Tôi cũng đã có vai trò nhân công nhân với tư cách là khách hàng và webrole kiểm soát chúng. –

Trả lời

1

Chúng tôi sử dụng Hàng đợi xe buýt dịch vụ Azure để gửi dữ liệu đến các vai trò web SignalR của chúng tôi sau đó chuyển tiếp cho khách hàng. CAT pages có các ví dụ rất hay về cách thiết lập vòng lặp không đồng bộ và gửi.

+3

Cảm ơn @el_tone Dường như vai trò web phải thực hiện việc gửi tới trình duyệt của khách hàng bằng SignalR. Vấn đề của tôi là các tin nhắn phải được gửi ** có nguồn gốc từ _worker_ vai trò **. Làm thế nào để có được các thông báo như vậy từ vai trò của người lao động. Nếu họ đặt các thông báo này trong hàng đợi của Service Bus, có vẻ như bus dịch vụ sau đó sẽ cần được kiểm tra bởi vai trò web. Việc bỏ phiếu như vậy là điều mà người ta đang cố tránh bằng cách sử dụng SignalR ngay từ đầu! – t0rus

+0

@ t0rus: Hàng đợi Xe buýt dịch vụ có thể chạy trong chế độ chặn, tức là không có cuộc thăm dò ý kiến. Hàng đợi đọc trả về hoặc trên một thời gian chờ đã đặt (ví dụ 24 giờ) hoặc khi nhận được tin nhắn. Việc chặn một luồng IIS trên đây là không có, nhưng với Task, nó có vẻ như trên đầu * có thể * thấp. Tự hỏi liệu chi phí trên có thể thấp hơn ... – DeepSpace101

+0

Có vẻ như liên kết bị hỏng. –

6

Bạn có thể sử dụng vai trò công nhân của mình làm ứng dụng SignalR, vì vậy họ sẽ gửi tin nhắn tới vai trò web (đó là máy chủ SignalR) và vai trò web sẽ chuyển tiếp tin nhắn cho khách hàng.

+2

Bạn có ví dụ về cách thực hiện việc này không? –

+1

Down đã bỏ phiếu cho câu trả lời này bởi vì hiện tại nó không thêm bất kỳ giá trị nào. –

1

Hãy nhớ rằng kiến ​​thức của tôi về hai công nghệ này rất cơ bản, tôi mới bắt đầu. Và tôi có thể đã hiểu lầm câu hỏi của bạn, nhưng dường như khá rõ ràng đối với tôi:

Vai trò web có thể đăng ký với máy chủ xếp hàng nơi vai trò của nhân viên gửi tin nhắn ?. Nếu như vậy sẽ không có khách hàng "kéo", dịch vụ xếp hàng sẽ cung cấp mã phía máy chủ web với một tin nhắn mới, và thông qua SignalR bạn sẽ đẩy các thay đổi cho khách hàng mà không có yêu cầu của khách hàng liên quan. Giao tiếp giữa web và công nhân sẽ vẫn như cũ (theo ý kiến ​​của tôi, đó là cách thích hợp để làm điều đó).

0

Các sản phẩm bus thông báo thay thế như NServiceBus có thể đáng để điều tra. NServiceBus có khả năng truyền tải thông điệp một cách không đồng bộ trên các ranh giới quy trình mà không cần phải bỏ phiếu.

1

Nếu bạn đang sử dụng một trong các thiết bị backranes SignalR, bạn có thể yêu cầu nhân viên nói chuyện với khách hàng được kết nối thông qua ứng dụng web của bạn.

How to publish messages using the SignalR SqlMessageBus giải thích cách thực hiện việc này.

Nó cũng liên kết đến một cách hoàn toàn làm việc example, minh họa một cách để thực hiện việc này.