2

ビジネス ロジックにリモート EJB を使用する Web ベースのアプリケーションがあります。これらの EJB の一部は、Web サービスとしても公開されています。後続の呼び出しが正しく機能できるようにするために、これらの呼び出しの一部について小さな状態を維持する必要があります。次のうちどれをお勧めしますか?

  • ステートフル EJB (これは Web サービスで動作しますか?)
  • 状態をクライアントに返します (クライアントが状態を変更できないようにしたい場合はどうすればよいでしょうか?)
  • 各メソッドで DB から状態をリロードします (オーバーヘッドについて心配する必要がありますか?)
4

2 に答える 2

2

提案された 3 つのソリューションはすべて動作させることができますが、最適なソリューションはアプリケーションの詳細によって異なります。

ステートフル セッション Bean (SFSB) はまったく使用しません。SFSB はセッション状態を維持するように設計されていますが、Web サービス経由で使用すると、セッションとは正確には何なのかという疑問が生じます。展開環境が複雑な場合、またはユーザーがアプリケーションの複数のインスタンスを使用している場合、これは脆弱なソリューションになる可能性があります。

状態を返す - 質問が示すように、サーバーがクライアントを信頼できると確信していない限り、セキュリティ上の問題が発生する可能性があります。暗号化技術を使用して、状態オブジェクトが変更されていないことを確認できますが、潜在的に敵対的なクライアントに機密データを提供しない方がはるかに安全です。これが役立つ可能性がある別の状況は、クライアントが状態を変更することを許可されている場合、またはクライアントが変更しても害がない場合です。システムへのクライアント アクセスが常に Web 層を介する場合、これはセッション状態を保存するのに適した場所です。Web 層とアプリケーション層は、状態オブジェクトを安全に交換できます。

データベースから状態をリロードすることは、おそらく最も一般的に適用可能なアプローチです。エンティティ Bean またはオブジェクト リレーショナル マッピング ライブラリを使用すると、サーバーはデータベース クエリの数を減らすことができるはずです。

于 2009-07-15T08:46:07.747 に答える
1

唯一のオプションは、特定の UserId に関連付けられた適切な情報を DB に保存することです。

Statefull Bean を Web サービスとして公開することはできません。

Bean を Web サービスとして公開する場合、ボディの変更を防ぐために SOAP ヘッダーを挿入することで、追加情報を送受信することができます。ただし、この場合、クライアントはそれを変更できます。

于 2009-07-19T13:00:13.603 に答える