9

設計上の決定を下す必要があります。私はあなたのアドバイスを必要とします。

要件：

  • サーバーとクライアント。クライアントは通常、携帯電話です。
  • インターネット経由で接続されています。
  • サーバーとクライアントは互いに話したいと思っています。
  • クライアントとサーバー間のテキスト、マルチメディアの交換。
  • テキストは標準的な形式です。それはあらかじめ決められています。
  • リアルタイム要件
  • 通常、セッションは 5 ～ 15 分間続きます。場合によっては1分以内。セッション期間として 5 分を想定します。
  • プロトコルは標準に準拠する必要があります。
  • 効率的でなければなりません。

オプション 1 アプリケーション用に設計したバイナリ プロトコル。

オプション 2 サーバーを HTTPServlet として実装します。クライアントは投稿リクエストを送信し、クエリは投稿メッセージで送信し、サーブレットはメッセージで応答を送信します。ただし、同じクライアントとセッションであっても、ポストリクエストごとに新しいスレッドが作成されるため、リアルタイムの対話ではこれは適切なオプションではないと思います。これの効率についてコメントしてください。

オプション 3 通常のサーブレットを使用します。上記と同じ問題に直面します。

オプション 4 SOAP を使用する

オプション 5 REST を使用する

オプション 6 Google Wave を使用する(仕様をまだ読んでいない)

オプション 7 他のプロトコルを提案する

現在、私は Web サービスの経験はありませんが、それがオプションである場合は、それに時間を費やすことを気にしません。

基本的に、標準的な方法でオプション 1 の速度と効率が必要です。

ありがとうございました

4

9 に答える 9

13

私には、HTTP プロトコルが最も適しているように思えます。オーバーヘッドが低く、すでに広く受け入れられています。[モバイル通信の要件である] TCP を使用し、セッション ネゴシエーションがあります [セッションの実際の状態ではなく、接続に関して]

ビデオとオーディオの共有には別のプロトコルを使用しますが、http で接続を設定します。

処理が必要なため、SOAP/Web サービスの使用は最適ではありません。個人的な経験から言えば、モバイル マシン上の Web サービス クライアントの方が簡単ですが、必要な処理は膨大であり、アプリケーションにボトルネックが生じる可能性があります。[モバイル マシンはスレッドをうまく処理できない]

また、ワイヤレスでデータを送信しているため、ガイドされていないメディアを扱う追加の問題についても説明する必要があります.

あなたの要件:

  • サーバーとクライアント。クライアントは通常、携帯電話です。：はい
  • インターネット経由で接続されています。: はい、デバイス ネットワークの設定方法によって異なります
  • サーバーとクライアントは互いに話したいと思っています。：はい
  • クライアントとサーバー間のテキスト、マルチメディアの交換。: HTTP はテキストと画像でうまく機能しますが、ビデオ用の UDP のような信頼性の低いものに切り替える必要があります。
  • テキストは標準的な形式です。それはあらかじめ決められています。：はい
  • リアルタイム要件 : これは不可能ですが、試みることはできます。
  • 通常、セッションは 5 ～ 15 分間続きます。場合によっては1分以内。セッション期間として 5 分を想定します。: セッションを開いたままにするためのヘッダーがあります。
  • プロトコルは標準に準拠する必要があります。: RFC 何か
  • 効率的でなければなりません。: 実行する必要がある処理は、Key: データの行ごとの解析のみです。

また、SOAP/Webservices は XML over HTTP であることを忘れていました。

于 2009-09-26T06:56:44.843 に答える
12

オプション 7 XMPPを使用しませんか?

  • それは標準です

  • 双方向のメッセージを許可します。

  • 既存の XMPP インフラストラクチャを使用することも (たとえば、クライアントは Google トーク アカウントを使用して接続することもできます)、オープン ソースの XMPP サーバーを使用して独自のインフラストラクチャを簡単に構築することもできます。

  • また、基本的にクライアントコードのみを記述するという事実も気に入っています（サーバーもXMPPクライアントであるため）-サーバーとクライアントの両方が同じ言語で記述されていると仮定すると、まったく同じコードを使用することさえできます.

  • ファイル転送がサポートされています。

  • ニーズに合わせて簡単に拡張可能

  • 賑やかです (Google Wave) ;)

人々が議論する可能性のある唯一のことは、その効率、または一般的な XML の効率です。でも問題ないと思います。

于 2009-10-09T11:44:50.160 に答える
3

リアルタイムの必要性 (文字通りに解釈する場合) は、多くの選択肢を削減します。HTTP プロトコルはリアルタイムではないため、それより上位のもの (SOAP や REST を含む) は同じ弱点を共有します。これが強い要件である場合は、RTP プロトコルまたは (少なくとも) ハンドシェイクを行わない他のものを検討する必要があります。

于 2009-10-08T23:10:52.797 に答える
2

オプション 1 を使用し、プロトコルとしてASN.1を使用してください! (バイナリ XML と呼ばれることもあります。) これにより、他の人が理解できる小さな構造化されたメッセージが生成されます。これは一般的な標準であり、このメッセージを読んでいるときは、それを使用したばかりです。:-)

ASN.1 は、いくつかのインターネット プロトコルの一部です。

于 2009-09-25T16:04:50.277 に答える
1

オプション 3をお勧めします。スレッド化の問題について心配する必要はありません。これをサーブレット コンテナーでホストしている場合、コンテナーはほぼ確実にスレッド プールを使用して、着信要求の処理を最適化し、アプリケーション内のスレッド数を制御します。

また、HTTP/1.1 はパイプラインをサポートし、後続のリクエストに対する接続の再利用をサポートします。これにより、接続のセットアップと切断に関するサーバーの負担が軽減されます。

于 2009-10-07T22:57:58.273 に答える
1

手始めに、クライアントを携帯電話に配置し、軽量なソリューションが必要な場合は、SOAP を避けてください。SOAP は、CPU と帯域幅を浪費する豚です。それは最も簡単な解決策でもありません。

クライアントをブラウザーに (javascript を使用して) 実装することを計画している場合、JSON ベースのソリューションが当然の道であり、それも単純です。それがどのようなものかについては、次の記事をお読みください。

json.org でその他のリソースを見つけることができます。

おそらく JAX-RS を単なる美化されたサーブレット実装として使用できます。(私たちの多くは、JAX-RS の JSR 311 は最初からサーブレット仕様がどうあるべきかのように見えると言っています... これはそれほど単純ではありませんが...)

「投稿ごとに1つのスレッド」について-言及するすべてのテクノロジーはほとんどのアプリケーションサーバー/サーブレットエンジンで同じように動作するため、これは問題ではありません-特定の時間に処理される各リクエストは独自のスレッドを使用します。

(ここではコメットについて話しているのではありません。アプリケーション サーバーの特別なパンがない限り、セッションごとにスレッドを使用する傾向がある技術です。)

于 2009-10-08T03:12:37.467 に答える
1

オプション 1は、目的に合わせて効率的にできる場合に適したオプションです。ただし、オプション 1 が必要ない限り、オプション 2 を使用したいと思います。 オプション 2は適切に実装されており、適切にサポートされています。HTTP 1.1 を使用している場合、毎回新しいスレッドを作成する必要はありません。

ただし、テキストのみを転送する必要がある場合は、オプション 1といくつかのテキスト圧縮を使用できます。テキストを解凍するためのオーバーヘッドは少しありますが、多すぎるはずです。ただし、モバイル デバイスの帯域幅使用量は減少します。

于 2009-10-08T03:33:39.407 に答える
1

Hessianは、http を介した軽量のバイナリ プロトコルです。多くの異なる Hessian 実装があるため、多数の異なるクライアントにサービスを提供できます。

効率が気になるので、ここでさまざまな Java リモーティング プロトコルに関するいくつかの指標を見つけることができます: http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/

于 2009-10-10T13:17:02.373 に答える
1

オプション 1 に進み、Google Protocol Buffers を使用して、プロトコル定義からコードを自動生成します (つまり、効率的でありながら、ある程度の一貫性/標準化が得られます)。

于 2009-09-25T15:29:36.967 に答える