私が探しているものを理解するのに助けが必要です。基本的に、ServerXMLの束をストリームに（一定期間にわたって）ダンプし、ダンプが発生するたびにN多数のクライアントがダンプを読み取るサービスが必要です。
例1000：株の1つがセントずつ上がるたび5に、サービスはXMLをストリームにダンプします。接続しているアプリケーションは、ストリームから情報を取得します。
新しいデータのためにストリームを読み取る何かが必要なので、接続が閉じることはないと思います。
これはWCFREST標準に準拠する必要がありますが、私が探しているものはありますか？
結局のところ、それは単なるデータのノンストップストリームです。
更新：サービスはマルチパート/混合コンテンツタイプである必要があるようです。
私が取り組んでいるアプリケーションも同様のアーキテクチャを備えており、SignalRを使用して、ロングポーリング手法を使用して更新をクライアントにプッシュすることを計画しています。私はまだそれを実装していないので、それがあなたのために働くことを誓うことはできませんが、彼らのドキュメントは有望なようです：更新：私は今これを実装しました、そしてそれは非常にうまくいきます。
サーバーからクライアント（ブラウザクライアントだけでなく）にデータをプッシュすることは、常に困難な問題でした。SignalRはそれを非常に簡単にし、あなたのためにすべての重労働を処理します。
Scott Hanslemanは、このテーマに関する優れたブログを持っており、ここに有用な記事（WCF、REST、およびSignalRを含む）があります：http：//www.codeproject.com/Articles/324841/EventBroker
WCFを使用する代わりに、ASP.NET MVC WebAPIを調べましたか？
WebAPIでのPushStreamContentの使用の詳細については、Henrikのブログに例があります（「PushContent」という見出しの下）。
アーカイブされたAtomフィードを検討しましたか？それらは100％RESTful（ハイパーメディアコントロールおよびすべて）であり、最も重要なことに、それらは非常にスケーラブルです。
具体的には、アーカイブドキュメントは変更されないため、1年以上のキャッシュ有効期限を設定できます。サブスクリプションドキュメントは、すべての最新イベントが発生し、絶えず変化する場所ですが、適切なHTTPキャッシングヘッダーを使用して、各クライアント要求間で何も変更されていない場合に304NotModifiedを返すようにすることができます。また、サービスに自然な時間分解能がある場合は、それを利用するようにを設定できますmax-age。たとえば、データの解像度が20分の場合、サブスクリプションドキュメントの応答に次のヘッダーを含めることができます。
Cache-Control: max-age=1200
そうすれば、キャッシュにほとんどのヒービングリフティングを実行させることができ、クライアントは、サービスをひざまずくことなく、サブスクリプションドキュメントを好きなだけポーリングできます。