問題タブ [stateless]

私は新しい実験的なWebアプリケーションフレームワークを開発しており、RESTfulに注意を向けることにしました。基本を読み終えて、RESTfulを概念としてかなりよく理解しているように感じます。

システムを稼働させ、URLを使用してシステム内の「名詞」を厳密に定義し、HTTPリクエストメソッドから「動詞」を取得しました。私はjavascriptajax呼び出しを使用して、HTMLフォームでは提供できないDELETEメソッドとPUTメソッドへのアクセスを提供しています。（これらの手段は厳密にはRESTfulである必要はありませんが、「UniformInterface」要件を満たしています）。

問題は、認証によるステートレス性とキャッシュ可能性にあります。Webサイトでのユーザー認証の標準モデルには、「ログイン」認証イベントが含まれます。その後、（成功した場合）ユーザーは永続的な安全なセッションで「壁の内側」にいて、認証されていないユーザーができない後続の要求を確認して実行できます。この認証の永続性は、RESTful性を損なうようです。認証されたユーザーには、認証されていないユーザーが同じリクエストに対して表示するHTMLとは異なるHTMLが表示される可能性があるため、キャッシュとステートレスは壊れているように見えます（たとえば、ログに記録されたユーザーのサイドバーにログインフォームがある場合があります。アウトユーザー）。

www-authenticate戦略を使用して、認証を必要とする要求に対してのみユーザーを認証することは、永続的な安全なセッションの概念を含まないため、正しい方向への一歩のようです。しかし、私たち全員がWebサイトに期待するようになったことに合わせて、エンドユーザーに「ログインした」外観をどのように表現するかという問題がまだあります。

それで、現在の考えでは、HTMLでログインした装飾を許可しながら、厳密にRESTfulな方法でWebページの認証と許可を処理するための好ましい方法は何ですか？

本当の単純な質問：Castle ActiveRecordはステートレスセッションを開くことができますか？もしそうなら、私はそれをどのように行いますか？そうでない場合は、それなしでステートレスセッションを開くにはどうすればよいですか？

Java EE 6 チュートリアルには次のように書かれています。

パフォーマンスを向上させるために、ステートレス セッション Bean が次の特性のいずれかを備えている場合は、その Bean を選択できます。

• Bean の状態には、特定のクライアントのデータがありません。
• 1 回のメソッド呼び出しで、Bean はすべてのクライアントに対して一般的なタスクを実行します。たとえば、ステートレス セッション Bean を使用して、オンライン注文を確認する電子メールを送信できます。
• Bean は Web サービスを実装します。

Singleton セッション Bean は、次の状況に適しています。

• 状態はアプリケーション全体で共有する必要があります。
• 1 つのエンタープライズ Bean に、複数のスレッドが同時にアクセスする必要があります。
• アプリケーションには、アプリケーションの起動時およびシャットダウン時にタスクを実行するエンタープライズ Bean が必要です。
• Bean は Web サービスを実装します。

しかし、次の場合は何を使用しますか:

• アプリケーション全体で状態を共有する必要はありません
• 単一のエンタープライズ Bean に複数のスレッドが同時にアクセスできる
• 起動時または停止時のタスクを実行する必要はありません

たとえば、次のインターフェイスを持つログイン サービスがあるとします。

@Singleton または @Stateless でアノテーションを付ける必要がありますか? 一方と他方の利点は何ですか？LoginService に (同時に使用される) EntityManager を注入する必要がある場合はどうなりますか?

追加:ステートレス シングルトンである Spring サービス Bean の Java EE 版について考えています。Java EE の対応物が @Stateless セッション Bean であり、@Singleton Bean が起動時のアプリケーションの構成またはシャットダウン時のクリーンアップ、またはアプリケーション全体のオブジェクトの保持に使用されることを正しく理解している場合。これは正しいです？

私のサイトのアーキテクチャには、ASP.Net と MySQL が含まれています。Amazon Cloud にデプロイする予定です。これは、EC2 インスタンスと RDS を意味します。私の質問はロギングに関するものです。

アプリケーションがステートレスであることを確認しているため、アプリケーション層へのログオンは除外されています。すべての状態/永続性は RDS に入ります。ロギングに関しては、RDS が適切な選択であるかどうかはわかりません (単なる憶測です)。これは新しく、データベースの例外もログに記録するため、RDS へのログインは正しくありません。私が自由に使える最良のオプションは SimpleDB だと思います。

ロギングの目的で RDS と SimpleDB のいずれかを選択するための推奨事項を探しています。

いくつかのレシピを一覧表示するテーブル ビューを想像してみてください。ユーザーがレシピをタップするたびに、レシピの材料を一覧表示する新しいテーブル ビューが読み込まれます。

情報を取得するために、次を使用して REST API を非同期呼び出ししています。

ユーザーがレシピをタップすると、レシピの材料を取得するために API が呼び出されます。ただし、新しいビュー (材料のリスト) に入ると、回答を受け取る前に、ユーザーは戻って新しいレシピを選択できます。

この場合、私は 2 つの答えを受け取ります。リクエストごとに 1 つ。問題は、この回答がどのリクエストに対するものなのかわからず、間違った回答から間違ったコンテンツで UI を更新することです。

この場合、どちらが正しいアプローチかわかりません。各リクエストパラメーターを回答に含めることを考えています。したがって、たとえば、API を使用して特定の用語を検索する場合、「foo」と言います。その用語も回答に含めます。次に例を示します。

リクエスト：

http://domain.com/api/search?term=foo

答え

各回答に各リクエスト パラメータを含めるのは奇妙に思えますが、非同期で呼び出す準備ができたステートレス API を作成するために見つけた唯一の解決策です。

これを達成する他の方法はありますか?

(私は、回答が受信されたときに呼び出される各リクエストにオブジェクトを割り当てるデリゲート パターンを使用しています。問題は、レシピの例では、レシピの材料がリストされるたびに材料テーブル ビューが再利用されることです)。

3 層アーキテクチャを持ち、Web サービスを介して通信する、より複雑な CRUD アプリケーションを想像してみてください。クライアントはサーバーとの会話を開始し、ウィザードのようなものを実行します。ウィザードを処理するには、クライアントはサーバーからのフィードバックを必要とします。

このアプローチのステートフルまたはステートレス Web サービスについての議論を開始しました。私は自分の経験と組み合わせていくつかの調査を行いました。

次のプロパティを持つステートレス Web サービス (この場合):

しかし、最初の 2 つの点を消すことができます。このアプリケーションは、高いスケーラビリティと可用性を必要としません。

それでは、ステートフル Web サービスについて説明します。私はたくさんのブログやフォーラムの投稿を読みましたが、ステートフル Web サービスを実装する最も発明されたポイントは次のとおりです。

しかし、ほとんどすべての Web アプリケーションにこれらの欠点があるのではないでしょうか? Web アプリケーションは、Cookie、クエリ文字列、セッション ID、およびすべてのものを使用して、http のステートレス性を回避します。

では、なぜ Web サービスにとってそれほど悪いのでしょうか?

たくさんの AJAX コンポーネントを含むかなりステートフルなページがあります。これらのコンポーネントのほとんどには動作があり、AJAX 要求を呼び出すための JavaScript コードを Java コードにレンダリングします。ページはステートレスではないため、リクエストごとにページのシリアル化が発生します。ここまでは順調ですね。

ただし、これらの AJAX 要求の一部はページをまったく変更しないため、ページのシリアル化は必要ありません。たとえば、(自作の) datagrid コンポーネントのフォワード キャッシング データです。これらのリクエストは継続的に呼び出され、各リクエスト中のページのシリアル化により遅延が発生します。

wicket-statelessなど、ステートレス wicket コンポーネントのプロジェクトがいくつかありますが、別の状況を解決します。ステートレス コンポーネントのリクエストは、ステートレス ページの新しいインスタンスで処理されます。既存のステートフル ページ インスタンスでリクエストを処理したいが、シリアル化は行わない。

これを自分で実装しようとしましたが、常にページに触れており、リクエスト処理後にシリアル化が発生するRequestCycleProcessor.resolve()ため、requestParametersからページを検索することにハングしました。Session.getPage()

• Wicket でこれを実装するための例、アイデアはありますか?

それが理解できることを願っています:)

ステートレス セッションと次の HQL を使用します。

私の Address Class には多くの BankDetails がありますが、アクセスできません。通常のセッションを使用すると機能します。私に何ができる？

私はこのアドバイスを見てきました...

理想的には、Web は REST 原則に従い、完全にステートレスであるべきです。したがって、各ユーザーのナビゲーション履歴を保持する必要なく、1 つの URL で 1 つのリソースを識別する必要があります。

...そして、ウィキペディアのページhttp://en.wikipedia.org/wiki/RESTを読んだところ、本当に良さそうですが、実際に実装する方法がわかりません。私は MVC ではなく ASP .NET Webforms で作業しています。

たとえば、私が構築しようとしているアプリケーションでは、ユーザーに何かを許可する前にログインする必要があります。T と C を受け入れて、基本的な詳細が変更されていないことを確認するなど、多くの有用なことを実行できるようになる前に、ジャンプしなければならないいくつかのフープがあります。最後に、BuyAProduct のように本当にやりたいことができるようになります。

私には (私はリッチクライアントの非常にステートフルな世界から来ました) 彼らが何をしたかを記録し、そこから彼らが何をすることが許されているかを推測するために状態が必要だと思われます。BuyAProduct URI をブックマークすることを (たとえば) サポートする方法がわかりません。彼らがブックマークに到着したとき、彼らがログインしたかどうか、T と C に同意したかどうか、基本的な詳細を忠実にチェックしたかどうかをどのように知ることができますか?

アプリがステートレスであるというアイデアが気に入っています。理由の 1 つは、「ユーザーが [戻る] ボタンと [進む] ボタンをクリックすると、一体どうすればよいのか」という問題を完全に解決しているように見えるからです。どうすればそれを適切に機能させることができるのかわかりません。私はこれについて本当に基本的な何かが欠けていると感じています。

IHttpModule標準を使用してトランザクションを開くビューごとのトランザクションモデルについて考えてみISessionます。

今、私はいくつかのバッチ操作をしたいページを持っています。IStatelessSessionバッチ操作に適しているため：

1. 両方ISessionをIStatelessSession同時に開くことはできますか？安全ですか？
2. 1.はいの場合、同じものを使用できますITransactionか？
3. ISession2.いいえの場合、とそれに関連するものをコミットして閉じてから、新しいものをITransaction開く必要がありますか？IStatelessSessionITransaction
4. 3.はいの場合、注意すべき落とし穴はありますか？

どんなアイデアでも大歓迎です