Thông báo về đèn và đẩy

Question

Tôi đang tạo giao diện người dùng Silverlight 2 cho một công cụ từ xa. Có hai người dùng đồng thời tại các trang web khác nhau tương tác với công cụ (nhà điều hành tại công cụ và nhà khoa học từ xa) và bất kỳ người dùng quan sát nào không tương tác với nó, chỉ xem. Tuy nhiên, bất cứ khi nào một trong hai người dùng hoạt động thay đổi điều gì đó, những thay đổi này phải được phản ánh ngay lập tức trong giao diện người dùng của tất cả người dùng, ví dụ: xoay hoặc thu phóng hình ảnh hoặc chú thích hoặc chọn một phần của hình ảnh, thêm các mục vào bộ sưu tập được hiển thị trong hộp danh sách. Trong ứng dụng khách, tôi sử dụng các bộ sưu tập quan sát dễ dàng phản ánh các thay đổi do người dùng đó thực hiện, nhưng khó thấy các thay đổi do người dùng khác thực hiện. Tôi có thể thăm dò ý kiến ​​cho những thay đổi từ mỗi khách hàng nhưng một cái gì đó giống như thông báo đẩy sẽ tốt hơn. Tôi đã mở rộng các ví dụ cho Google nhưng không tìm thấy bất kỳ thứ gì hoàn toàn là những gì tôi cần. Có tất cả các loại vấn đề bảo mật với Silverlight tương tác với các dịch vụ WCF có nghĩa là nhiều ví dụ tiềm năng không hoạt động. Tôi về cơ bản đã hết thời gian cho dự án này và cần sự giúp đỡ nhanh chóng. Có ai có bất cứ đề nghị của một ví dụ đơn giản phù hợp mà minh họa làm thế nào để làm điều này? Tôi là một nhà phát triển có kinh nghiệm nhưng phải tự dạy cho mình các dịch vụ Silverlight và WCF và không có ai trong khu vực của tôi biết bất cứ điều gì về những điều này. Ngay cả tho 'Tôi đã thực hiện một số tiền hợp lý của công việc ASP.NET Tôi không phải là một web/Javascript guru. Cảm ơn.

Answer 1

Thông báo đẩy được hỗ trợ trong Silverlight 2 bằng cách sử dụng hỗ trợ WCF PollingDuplexHttpBinding mới. Có hai hội đồng được cài đặt với Silverlight SDK (one for Silverlight app one for WCF server).

Tôi có một số few blog posts and a full sample application minh họa cách 'đẩy' Cập nhật cổ phiếu từ máy chủ Ứng dụng bảng điều khiển tự lưu trữ dịch vụ WCF cho khách hàng được kết nối. Nó cũng cho thấy làm thế nào mỗi khách hàng có thể thêm ghi chú chống lại một cổ phiếu và có những ghi chú đồng bộ (đẩy từ máy chủ) cho tất cả các khách hàng kết nối khác.

Phiên bản mới nhất của mẫu (Phần 4) cho thấy làm thế nào để đồng bộ hóa cập nhật đẩy giữa hai Silverlight và WPF khách hàng sử dụng hai thiết bị đầu cuối máy chủ như sau:

using System; 
using System.ServiceModel; 
using System.ServiceModel.Description; 

namespace StockServer 
{ 
    public class StockServiceHost : ServiceHost 
    { 
     public StockServiceHost(object singletonInstance, params Uri[] baseAddresses) 
      : base(singletonInstance, baseAddresses) 
     { 
     } 

     public StockServiceHost(Type serviceType, params Uri[] baseAddresses) 
      : base(serviceType, baseAddresses) 
     { 
     } 

     protected override void InitializeRuntime() 
     { 
      this.AddServiceEndpoint(
       typeof(IPolicyProvider), 
       new WebHttpBinding(), 
       new Uri("http://localhost:10201/")).Behaviors.Add(new WebHttpBehavior()); 

      this.AddServiceEndpoint(
       typeof(IStockService), 
       new PollingDuplexHttpBinding(), 
       new Uri("http://localhost:10201/SilverlightStockService")); 

      this.AddServiceEndpoint(
       typeof(IStockService), 
       new WSDualHttpBinding(WSDualHttpSecurityMode.None), 
       new Uri("http://localhost:10201/WpfStockService")); 

      base.InitializeRuntime(); 
     } 
    } 
} 

WPF khách hàng kết nối với các thiết bị đầu cuối WSDualHttpBinding và khách hàng Silverlight kết nối với điểm cuối PollingDuplexHttpBinding của cùng một dịch vụ WCF. Ứng dụng này cũng cho thấy cách xử lý các yêu cầu chính sách truy cập máy khách Silverlight.

Khách hàng (Silverlight hoặc WPF) có thể thêm ghi chú vào một Cổ phiếu trong giao diện người dùng của họ và các ghi chú này truyền lại cho máy chủ được đẩy tới tất cả các ứng dụng khách khác. Điều này thể hiện thông tin liên lạc theo cả hai hướng và hy vọng thực hiện tất cả các giao tiếp cần thiết cần thiết cho ứng dụng của bạn.

Bạn có thể xem ảnh chụp màn hình của demo application running here.

Answer 2

Không phải là đang đẩy Flex trong thời trang cậu bé fan hâm mộ, nhưng vấn đề của thực tế đây là loại kiến ​​trúc chúng tôi xây dựng vào tất cả các ứng dụng Flex dựa trên thường xuyên. Dưới đây là những gì chúng ta làm trên Flex - không có nghi ngờ nó có thể được dịch phù hợp để Silverlight:

Chúng tôi mất ba thành phần và tích hợp chúng lại với nhau để thực hiện khả năng này:

1. Comet mẫu (HTTP cách tương thích để làm thông báo máy chủ push - nhìn trên Wikipedia để biết thêm)
2. JMS chủ đề tin nhắn (xuất bản/hàng đợi thuê bao)
3. Adobe BlazeDS servlet

Mục sau thực hiện mẫu Comet, hỗ trợ marshaling đối tượng AMF (định dạng tuần tự nhị phân của Adobe cho các đối tượng ActionScript3) và các cầu nối đến một hàng đợi hoặc chủ đề JMS. Khi chuyển tiếp đến một chủ đề, khi đó nhiều máy khách Flex đang chạy trong một trình duyệt có thể được ủy nhiệm làm người đăng ký cho một chủ đề JMS. Vì vậy, nếu bất kỳ khách hàng nào xuất bản một thông báo (hoặc mã phía máy chủ xuất bản vào chủ đề), tất cả các thuê bao của khách hàng sẽ có thông điệp được đẩy tới họ thông qua BlazeDS và triển khai Thực hiện mẫu Comet.

Có hiệu quả bạn cần xác định vị trí hoặc viết thành phần hoàn thành những gì BlazeDS thực hiện. Bạn cũng có thể cần phải triển khai một số mã máy khách tương tác với mẫu Comet của thành phần phía máy chủ này.

WCF có hỗ trợ Mẫu Comet và nhắn tin hai chiều không? Đặc biệt là nơi tuân thủ HTTP và cổng 80 hoặc cổng 443 cho SSL. Có vẻ như bạn đã xem xét điều đó và không tìm thấy bất kỳ điều gì cho nhắn tin hai chiều. Vì vậy, bạn có thể cần phải cuộn tay áo của bạn lên và làm một số mã hóa.

Một số điều cần lưu ý về làm máy chủ push to một ứng dụng web:

BlazeDS hỗ trợ hai chế độ chính thực hiện mô hình Comet (có thực sự là một lựa chọn bỏ phiếu thứ 3 nhưng tôi bỏ qua nó):

1. dài bỏ phiếu
2. HTTP luồng

một dài polling bạn nên tìm được phổ supportable hơn đối với hầu hết các trình duyệt web. Vì vậy, bạn có thể sắp xếp để chỉ hỗ trợ ban đầu. Hoặc bạn có thể dành thời gian để làm cho mã khách hàng của bạn thử HTTP streaming đầu tiên và chuyển sang bỏ phiếu dài nếu cần.

Đối với người môi giới thư có thể cung cấp khả năng xuất bản/suscribe, bạn có thể xem xét sử dụng ActiveMQ JMS. Đây là nguồn mở và miễn phí với sự hỗ trợ cộng đồng tích cực (bạn cũng có thể mua hỗ trợ). Ngoài ra, bạn có thể sử dụng NMS để tích hợp với tư cách máy khách .NET.

Có nhà môi giới thư nằm ở tầng giữa thực sự quan trọng vì đó sẽ là nơi để thư được đặt an toàn. Nếu khách hàng của bạn đang thực hiện bỏ phiếu dài, bạn sẽ không muốn họ bỏ lỡ bất kỳ tin nhắn mới nào trong một khoảng thời gian khi họ không thực sự kết nối.

Một điều cần xem xét trong kịch bản khối lượng lưu lượng truy cập cao (hàng trăm hoặc hàng nghìn khách hàng, chẳng hạn như trang web trên Internet), bạn cần có cách tiếp cận mẫu Comet có thể mở rộng.

Trong thế giới Flex/Java, BlazeDS servlet (là mã nguồn mở) đã được sửa đổi để hoạt động với mô hình không đồng bộ. Trong Java, một bộ lắng nghe socket có thể được xây dựng để sử dụng các kênh NIO và các nhóm luồng của trình điều hành Java Concurrency Executor. Máy chủ web Tomcat có trình nghe NIO và hỗ trợ cho các sự kiện Servlet 3.0 không đồng bộ. Tuy nhiên, BlazeDS đã được sửa đổi, để làm việc với máy chủ web Jetty. Điểm mấu chốt là khả năng mở rộng của cách tiếp cận không đồng bộ này có nghĩa là một máy chủ web vật lý đơn lẻ có thể được tăng cường để hỗ trợ lên tới 20.000 kết nối máy khách kiểu Comet đồng thời.

Đã lâu rồi kể từ khi tôi thực hiện lập trình .NET nghiêm túc nhưng được sử dụng cho các khả năng io giống Java 1.1 ngoại trừ khả năng xử lý kết quả không đồng bộ. Điều này, mặc dù, không phải là điều tương tự như việc tạo các bộ nghe socket không đồng bộ thông qua các kênh Java NIO. Việc triển khai kênh NIO có thể hỗ trợ hàng trăm nghìn kết nối socket với một nhóm luồng tương đối nhỏ. Nhưng C# và .NET đã trải qua hai hoặc ba vòng quay đáng kể - có lẽ đã có thêm các khả năng io mới có thể so sánh với các kênh NIO.

Answer 3

PollingDuplexHttpBinding có lẽ là cách thanh lịch nhất để làm điều đó.

Một tùy chọn ít có liên quan đến sở hữu là sử dụng ổ cắm TCP từ ứng dụng Silverlight của bạn. Bất cứ khi nào một trong những khách hàng Silverlight cần có một bản cập nhật được đẩy, bạn có thể gửi cho nó một thông điệp TCP có chứa tên của dịch vụ WCF cần gọi hoặc một số thông tin trọng lượng nhẹ khác.

Tôi sử dụng phương pháp này cho một ứng dụng và nó hoạt động tốt.

Answer 4

Tổ chức của tôi nhận thấy triển khai đẩy Silverlight 2.0/WCF là một chút "chưa sẵn sàng cho thời gian chính", ít nhất là cho những gì chúng tôi dự định sử dụng.

Chúng tôi đã kết thúc với XMPP/Jabber, bởi vì nó là một con thú tốt hơn, và bạn có thể thực hiện nó khá dễ dàng trong Silverlight, bằng cách lấy một số tài nguyên ra khỏi internet.

Tôi tin rằng Silverlight 3.0 sẽ triển khai thực hiện đẩy mới hơn/tốt hơn, từ những gì tôi có thể biết từ thông tin công khai.

Answer 5

Ngoài ra,

nếu bạn muốn có một API Silverlight mẹ đẻ không có proxy, cầu hoặc máy chủ web có liên quan bạn có thể sử dụng Niết Bàn từ my-kênh như middleware tin nhắn của bạn. Xem Nirvana từ kênh của tôi và trang giới thiệu của họ. (Xin lỗi tôi là một người dùng mới và không thể gửi liên kết):

Alex

Answer 6

Một đơn giản hơn nhiều và mạnh hơn giải pháp tại khu vực này http://www.udaparts.com/document/Tutorial/slpush.htm

Answer 7

EDIT: nó thực sự làm việc tốt. Tôi đã xấu cắn bởi "biến ẩn" trong một đóng cửa :(

tôi đã sử dụng PollingDuplex cho SL2 và tôi nghĩ rằng nó chưa sẵn sàng phục vụ sản xuất được nêu ra.

vấn đề chính của tôi là một thực tế rằng nó doesn' t phân biệt đối xử trên các máy khách trên cùng một máy. Nếu tôi chạy 2 máy khách thì một trong số chúng sẽ không thể thăm dò máy chủ được nữa và sẽ chết vì hết thời gian chờ. Tương tự như vậy, nếu tôi giết một khách hàng và sau đó tạo một khách hàng mới sau đó khách hàng mới sẽ nhận được các bản cập nhật đẩy từ khách hàng trước đó trong một thời gian dài.

Có ai gặp phải sự cố tương tự hoặc chúng được khắc phục trong SL3 không?

Thực ra tôi đã chạy một số mã demo khác và nhận ra rằng vì lý do nào đó bạn phải chỉ định InstanceContextMode và InstanceMode sao cho dịch vụ dựa trên phiên và không phải là singleton (theo như tôi có thể biết). Có các vấn đề hiệu suất rõ ràng trong mã demo đơn giản mà tôi đã kéo.

Hoàn toàn không may là hành vi này không được ghi lại.

Answer 8

Tôi chỉ muốn làm rõ rằng PollingDuplexHttpBinding không thực hiện thông báo đẩy 'đúng', như tiết lộ tên của nó (bỏ phiếu). Từ số msdn documentation:

Khi được định cấu hình với ràng buộc này, khách hàng Silverlight sẽ thăm dò định kỳ dịch vụ trên lớp mạng và kiểm tra bất kỳ tin nhắn mới nào dịch vụ muốn gửi trên kênh gọi lại. Dịch vụ xếp hàng tất cả các tin nhắn được gửi trên kênh gọi lại của khách hàng và cung cấp chúng cho khách hàng khi khách hàng thăm dò dịch vụ.

Tuy nhiên nó hiệu quả hơn cách truyền thống bỏ phiếu dịch vụ web, vì sau mỗi cuộc thăm dò, máy chủ sẽ giữ kênh mở trong một thời gian nhất định (nói 1 phút) và nếu thư đến trong đó thời gian nó sẽ trực tiếp 'đẩy' tin nhắn cho khách hàng. Khách hàng phải liên tục gia hạn kết nối của nó, nó như vậy để nói các cuộc thăm dò dịch vụ.

Nếu bạn muốn triển khai các thông báo đẩy thực với đèn chiếu, tôi tin rằng bạn cần làm việc với ổ cắm và tôi khuyên bạn nên đọc một số bài đăng trên blog của Dan Wahlin về chủ đề này.