httpを介して非同期ストリーミングを行うのに役立つフレームワークが必要です。それはSOAP WSまたは他の何かのように見えるかもしれません。私はそれが正しく名前を付けるかどうか分からないので、ここに私が必要なものがあります:非同期Webサービスストリーミング
ServerAはhttpを介してリモートServerBに要求したいです。要求には任意の情報が含まれています。その結果、同じタイプの複数のレコードが含まれます。それらのうちのいくつかはすぐに利用可能であり、他のものは後で利用可能である。 ServerAは、すべての結果が利用可能になるまで待つことなく、できるだけ早く利用可能な結果を得たいと考えています。実世界では、ServerBはさまざまなデータソースを検索しますが、そのうちのいくつかは他のデータソースよりも応答性があります。
3種類の解決策が考えられます。まず、サーバーAは、要求のランダムなIDを生成し、すぐに戻りますSOAPリクエスト
void ServerB.startSearch(id, request);
を行い、その後、定期的に
Result[] ServerB.areThereAnyNewResults(id);
を呼び出すので、サーバーAの世論調査では、新たなreasults FORE SERVERB。私はこのメソッドをポーリングと呼びます。それは
ServerA.acceptResults(String id, Result[] newResults);
と呼んのように、別の解決策は、サーバーA側の受信サービスを公開することであるAからBに設立され、複数の接続を必要とする
ので、サーバーBがServerA.acceptResultsに新しい結果をプッシュServerB.startSearch(id, request, serverAReceivingServiceEndpoindAddress);
()新しい結果が得られます。私はそれをプッシュと呼びます。 AからBへの1つの接続と、BからAへの複数の接続が確立されます。
別のオプションは、単一の応答内で同じHTTPチャネルで結果をストリーミングすることです。
Aはhttpコールを実行します(SOAPであれ他のものであれはわかりません)。Bが検索を開始し、新しい結果が利用可能になったらhttpストリームで送信してフラッシュしますすぐにA面で利用可能です。すべての結果が利用可能になるまで、http接続を閉じません。それはAからBへの単一の接続だけを必要とするので、なぜそれを使用するのが好きなのですか。私はそれをストリーミングと呼びます。私は、一部のプロキシが応答内容をバッファリングしている場合には動作しないことを理解しています。
私の仕事のほとんどを行うソリューションがあれば、私の質問があります。私がやりたいのは何サイド
Service s = new RemoteAsyncService("http://serverb.com/serviceEndpoint", RemoteAsyncService.STREAMING);
// or RemoteAsyncService.POLLING, or RemoteAsyncService.PUSHING
Request r = new Request(...);
Callback callback = new Callback(){
void newResults(Result[] result){...}
// e should be null if finished correctly
void requestFinished(RemoteException e){...}
}
s.search(request, callback);
に呼び出し、そのようなコードで、サーバーB側
public ServiceImpl implements Service{
void search(Request r, Callback c){
// perform search, call c.newResult() when new results are available
}
}
でそれを実装し、残りはそれがドロップされたときに、接続を再確立を含め、フレームワークによって処理され、バッファリングプロキシのためにストリーミングができない場合にポーリング/プッシュに落ちる、ServerBが作業を終了したときにcallback.requestFinished()を呼び出したり例外をスローしたりする。
したがって、可能な場合には、通信が行われる方法を抽象化し、ストリーミングの能力を発揮するソリューションはありますか?
もしそうでなければ、それをオープンソースとして実装することは有益でしょうか? :)
彗星の場合は、[桟橋]のようなサーブレットコンテナは、[1]の合理的なサポートを持っています。そして、はい、それは彗星がここで助けるかもしれないように聞こえます。 逆に、SOAPはおそらくそれほど有用ではありません。むしろ、CometやRESTishのWebサービスはより柔軟性があります。 [1]:http://www.mortbay.org/jetty/ – StaxMan
私は、ターンアラウンド期間が非常に長い場合、両端でリソースを使い果たすことができるため、彗星スタイルの通信は特殊なケースに限られると思います時間がたつにつれてオペレーションが盛り上がる。 SOAPは基本的には同期RPCなので、ほとんどの場合、「サーバ」によって公開されるSOAPサービスと、「クライアント」によって公開される返信/コールバックサービスを必要とし、返信先URIに沿って最初の呼び出しを「サーバー」にコールバックする場所を伝えます。私はこれがWCF Duplex契約が多かれ少なかれだと思います。 – Bob77