4

クライアント側で Smack API を使用して、Openfire XMPP サーバーを利用するチャット Web サイトを開発しています。Smack API を利用した Web プロジェクトは、Play! フレームワークを使用して RESTful にします。私はプレイを選びました！非同期プログラミング製品 (Comet Sockets/WebSockets) のためです。

基本的に、これまでのところ、私のアーキテクチャは次のようになっています。

Openfire <-> Web サーバー <-> ユーザー/ブラウザー。

Android デバイスもサポートし、コードの再利用を最大化するには、XMPP クライアント側のコードを Web サイトと Android クライアントの両方に共通の RESTful Web サービスとして実装する必要がありますか?

Openfire <-> ウェブサービス <-> ウェブサイト <-> ブラウザ/ユーザー。

Openfire <-> ウェブサービス <-> Android アプリ。

中間 Web サービスの導入により、スケーラビリティの問題が心配ですか? 複数のコンポーネントを通過する必要があるため、通信に遅延が発生することはありますか?

上記に関するアドバイスは役に立ちます。ありがとう。

4

2 に答える 2

4

スケーラビリティの鍵はデカップリングです。つまり、本質的には、「コンポーネントの 1 つが故障した場合、他のコンポーネントは正常に動作し続けるか?」という観点から問題を考えることができます。世界の終わりのシナリオを回避することに加えて、各コンポーネントを個別に水平方向にスケーリングすることもできます。

それを念頭に置いて、特定のユースケースに移りましょう。レイヤーのためのレイヤーは、いくつかの Java EE アーキテクチャーについていまだに悪夢を見させてくれます。不必要な遅延が発生するだけでなく、問題の特定が難しくなります。サービスが失敗した場合、失敗の原因は Web サーバー、Android アプリケーション、または Web サービスでしたか?

コードを再利用したい場合は、コンポーネントを複製する代わりにコードを再利用してください。それがライブラリの目的です。共通のコードを取り出してライブラリとして抽出し、Web サーバーと Android アプリケーションの両方で使用します。

于 2012-09-30T12:54:06.307 に答える
1

Web サービスがロードされると (他のアプリと同様に) ブラウザーから Web サービスを直接消費する軽い Web ページを作成するのが最善だと思います。

したがって、アプリと Web ページの唯一の違いは、ユーザーが Web ページにアクセスするたびにブラウザーによって Web ページが読み込まれることです。

于 2012-09-27T16:38:59.213 に答える