リモート機器へのSilverlight2ユーザーインターフェイスを作成しています。異なるサイトで2人の同時ユーザーが機器と対話し（機器のオペレーターとリモートサイエンティスト）、任意の数のオブザーバーユーザーが機器と対話せずに見ているだけです。ただし、2人のアクティブユーザーのいずれかが何かを変更するたびに、これらの変更をすべてのユーザーのUIにすぐに反映する必要があります。たとえば、画像のパンやズーム、画像の一部の注釈や選択、リストボックスに表示されるコレクションへのアイテムの追加などです。クライアント内では、そのユーザーによって行われた変更を簡単に反映する監視可能なコレクションを使用しますが、別のユーザーによって行われた変更を確認するのは困難です。各クライアントからの変更をポーリングできますが、プッシュ通知のようなものの方が良いでしょう。私は例のために広範囲にグーグルで検索しましたが、私が必要としているものは何も見つかりませんでした。SilverlightがWCFサービスと対話することには、あらゆる種類のセキュリティ問題があります。これは、多くの潜在的な例が機能しないことを意味します。私は本質的にこのプロジェクトの時間を使い果たしており、迅速な支援が必要です。誰かがこれを行う方法を説明する適切な簡単な例の提案がありますか？私は経験豊富な開発者ですが、SilverlightとWCFのサービスを自分で学ばなければならず、私の地域にはこれらについて何も知らない人は誰もいません。かなりの量のASP.NET作業を行ったとしても、私はWeb/Javascriptの第一人者ではありません。ありがとう。私は本質的にこのプロジェクトの時間を使い果たしており、迅速な支援が必要です。誰かがこれを行う方法を説明する適切な簡単な例の提案がありますか？私は経験豊富な開発者ですが、SilverlightとWCFのサービスを自分で学ばなければならず、私の地域にはこれらについて何も知らない人は誰もいません。かなりの量のASP.NET作業を行ったとしても、私はWeb/Javascriptの第一人者ではありません。ありがとう。私は本質的にこのプロジェクトの時間を使い果たしており、迅速な支援が必要です。誰かがこれを行う方法を説明する適切な簡単な例の提案がありますか？私は経験豊富な開発者ですが、SilverlightとWCFのサービスを自分で学ばなければならず、私の地域にはこれらについて何も知らない人は誰もいません。かなりの量のASP.NET作業を行ったとしても、私はWeb/Javascriptの第一人者ではありません。ありがとう。
8 に答える
プッシュ通知は、新しい WCF PollingDuplexHttpBinding サポートを使用して、Silverlight 2 でサポートされています。Silverlight SDK には 2 つのアセンブリがインストールされています ( Silverlight アプリ用に 1 つ、WCF サーバー用に 1 つ)。
WCF サービスを自己ホストするコンソール アプリケーション サーバーから、接続されたクライアントに Stock の更新を「プッシュ」する方法を示すいくつかのブログ投稿と完全なサンプル アプリケーションがあります。また、各クライアントが株式に対してメモを追加し、それらのメモを他のすべての接続クライアントに同期 (サーバーからプッシュ) する方法も示します。
サンプルの最新バージョン (パート 4) は、次のように、2 つのサーバー エンドポイントを使用して、Silverlight と WPF クライアントの両方の間でプッシュされた更新を同期する方法を示しています。
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 クライアントは WSDualHttpBinding エンドポイントに接続し、Silverlight クライアントは同じ WCF サービスの PollingDuplexHttpBinding エンドポイントに接続します。アプリは、Silverlight クライアント アクセス ポリシー要件を処理する方法も示します。
クライアント (Silverlight または WPF) は、UI で Stock に対してメモを追加できます。これらのメモはサーバーに伝播され、他のすべてのクライアントにプッシュされます。これは双方向の通信を示しており、アプリに必要なすべての通信が実行されることを願っています。
ここで実行中のデモ アプリケーションのスクリーンショットを確認できます。
Flex をファンボーイ風に推進しているわけではありませんが、実際のところ、これは Flex ベースのすべてのアプリケーションに日常的に組み込まれている種類のアーキテクチャです。Flex で行っていることは次のとおりです。Silverlight に適切に変換できることは間違いありません。
この機能を実現するために、次の 3 つの要素を組み合わせて統合します。
- コメット パターン (サーバー プッシュ通知を行う HTTP 互換の方法 - 詳細についてはウィキペディアを参照してください)
- JMS メッセージングのトピック (パブリッシュ/サブスクライバー キュー)
- Adobe BlazeDS サーブレット
後者の項目は、Comet パターンを実装し、AMF オブジェクト マーシャリング (Adobe の ActionScript3 オブジェクトのバイナリ シリアル化形式) をサポートし、JMS キューまたはトピックにブリッジします。トピックにブリッジする場合、ブラウザーで実行されている複数の Flex クライアントを JMS トピックのサブスクライバーとしてプロキシできます。したがって、いずれかのクライアントがメッセージをパブリッシュする (またはサーバー側のコードがトピックにパブリッシュする) 場合、すべてのクライアント サブスクライバーは、BlazeDS および Comet パターンの実装を介してメッセージをプッシュします。
BlazeDS が行うことを実行するコンポーネントを効率的に見つけるか、作成する必要があります。このサーバー側コンポーネントの Comet パターンと対話するクライアント コードを実装する必要がある場合もあります。
WCF は Comet パターンと双方向メッセージングをサポートしていますか? 特に、HTTP および SSL のポート 80 またはポート 443 に準拠している場合。すでに調べたようですが、双方向メッセージングについては何も見つかりませんでした。そのため、袖をまくり上げてコーディングを行う必要がある場合があります。
Web アプリへのサーバー プッシュを行う際の注意事項:
BlazeDS は、Comet パターンを実装するための 2 つの主要なモードをサポートしています (実際には 3 番目のポーリング オプションがありますが、無視しています)。
- ロングポーリング
- HTTP ストリーミング
ロング ポーリングは、ほとんどの Web ブラウザーでより普遍的にサポートされていることがわかるはずです。したがって、最初はそれをサポートするだけに合理化することができます。または、時間をかけてクライアント コードで最初に HTTP ストリーミングを試行し、必要に応じてロング ポーリングに切り替えることもできます。
パブリッシュ/サブスクライブ機能を提供できるメッセージ ブローカーに関しては、ActiveMQ JMS の使用を検討してください。これはオープン ソースであり、アクティブなコミュニティ サポートを無料で提供しています (サポートを購入することもできます)。さらに、NMS を使用して .NET クライアントとして統合できます。
中間層にメッセージ ブローカーを配置することは、メッセージを安全に配置する場所になるため、実際には重要です。クライアントがロング ポーリングを実行している場合、実際に接続されていない間に新しいメッセージを見逃すことは望ましくありません。
トラフィック量の多いシナリオ (インターネット上の Web サイトなど、数百または数千のクライアント) で考慮すべきもう 1 つの点は、スケーラブルなコメット パターンへのアプローチが必要なことです。
Flex/Java の世界では、BlazeDS サーブレット (オープン ソース) が非同期モデルで動作するように変更されています。Java では、ソケット リスナーを構築して、NIO チャネルと Java Concurrency Executor スレッド プールを使用できます。Tomcat Web サーバーには NIO リスナーがあり、非同期の Servlet 3.0 イベントをサポートしています。ただし、特に BlazeDS は、Jetty Web サーバーで動作するように変更されています。要するに、この非同期アプローチのスケーラビリティは、単一の物理 Web サーバーを拡張して、最大約 20,000 のコメット スタイルのクライアント接続を同時にサポートできることを意味します。
本格的な .NET プログラミングを行ってからしばらく経ちましたが、io 機能に慣れていたのは、非同期結果ハンドラー機能を除いて Java 1.1 によく似ていました。ただし、これは、Java NIO チャネルを介して非同期ソケット リスナーを作成することと同じではありません。NIO チャネルの実装は、比較的小さなスレッド プールで数百から数千のソケット接続をサポートできます。しかし、C# と .NET は 2 つか 3 つの大幅な改訂を経ています。おそらく、NIO チャネルに匹敵する新しい io 機能が追加されています。
PollingDuplexHttpBindingは、その名前（ポーリング）を明らかにするように、「真の」プッシュ通知を実装していないことを明確にしたかっただけです。msdnドキュメントから：
このバインディングを使用して構成すると、Silverlightクライアントはネットワーク層でサービスを定期的にポーリングし、サービスがコールバックチャネルで送信する新しいメッセージをチェックします。サービスは、クライアントのコールバックチャネルで送信されたすべてのメッセージをキューに入れ、クライアントがサービスをポーリングするときにそれらをクライアントに配信します。
ただし、Webサービスをポーリングする従来の方法よりも効率的です。これは、各ポーリング後、サーバーが一定時間（たとえば、1分間）チャネルを開いたままにし、その時間内にメッセージが到着すると、直接プッシュするためです。 'クライアントへのメッセージ。クライアントは接続を繰り返し更新する必要があります。つまり、サービスをポーリングします。
Silverlightを使用して実際のプッシュ通知を実装する場合は、ソケットを使用する必要があると思います。このテーマに関するDanWahlinのブログ投稿を読むことをお勧めします。
あるいは、
プロキシ、ブリッジ、または Web サーバーが関与しないネイティブの Silverlight API が必要な場合は、my-Channels の Nirvana をメッセージング ミドルウェアとして使用できます。my-Channels とそのショーケース サイトから Nirvana をチェックしてください。(申し訳ありませんが、私は新しいユーザーであり、リンクを送信できません):
アレックス
PollingDuplexHttpBinding は、おそらく最も洗練された方法です。
あまり関与しない代替手段の 1 つは、Silverlight クライアントから TCP ソケットを使用することです。Silverlight クライアントの 1 つに更新をプッシュする必要がある場合はいつでも、呼び出す必要がある WCF サービスの名前またはその他の軽量の情報を含む TCP メッセージをクライアントに送信できます。
私はこのアプローチをアプリケーションに使用していますが、うまく機能します。
サイトhttp://www.udaparts.com/document/Tutorial/slpush.htmの 1 つのはるかにシンプルで強力なソリューション