なぜWARはセッション情報を共有できないのですか？

複数の開発者がこの問題の解決策を探しているのを見てきました：異なるWARからのセッション情報へのアクセス（同じEAR内であっても）-ここにいくつかのサンプルがあります：Tomcatの異なるアプリケーション間でセッション状態を共有する方法はありますか？、別のWebアプリケーションのアクセスセッション、異なるWARファイル、共有リソース、Tomcat：2つのアプリケーション間でデータを共有する方法 、TomcatでcrossContext属性は何をしますか？セッション共有を有効にしますか？等々...

私が検索したすべてから、コンテナに応じていくつかの特定の解決策がありますが、それはどういうわけか「仕様に反しています」。また、答えを見つけることができずにJava EE仕様を調べました。

一部の開発者はWebアプリケーション間のカップリングについて話しますが、私は反対する傾向があります。カップリングしない場合、同じEAR内にWARを保持する理由は何ですか？たとえば、EJBはローカルにアクセスできます（同じEAR内の別のEJB JAR内にある場合でも）。

より具体的には、私のWARの1つが認証と許可を処理し、この情報を（同じEAR内の）他のWARと共有したいと思います。以前、WARをJARとしてパッケージ化し、それらを単一のWARプロジェクト（WEB-INF / lib）に入れることで、同様の問題を回避することができました。しかし、私はこのソリューションが好きではありません（サーブレットの命名などに多大な労力が必要です）。

そして、最初の（そして最も重要な）質問に答えるソリューションはありません：なぜWARはセッション情報を共有できないのですか？

EARを擬似仮想マシンのように扱う

EARは、通常はJARからの共通の構成とライブラリを共有するWARファイルのコレクションです。これにより、相互依存するサービスのコレクションをアプリケーションコンテナ内でより簡単に管理できます。したがって、EARをコンテナーにデプロイすると、EARは仮想マシンの単純な形式と考えることができます。

仮想マシン上の1つのプロセスが別のプロセスに影響を与えることができないのと同じ方法で、EARにも同じことが言えます。すべてのWARは、内部状態を保護するために分離されています。

スケーリング認証

一般に、Webアプリケーションは、適切に拡張するためにステートレスである必要があります。セッションに多くの情報があることは、これを防ぐアンチパターンです。これにより、HTTPのステートレスな性質と、迅速でカスタマイズされたユーザーエクスペリエンスを維持する必要性との間に矛盾が生じます。認証は古典的なユースケースであり、エンドユーザー機能を提供するために多くの認証されたリクエストを必要とするおしゃべりなAPIで一般的です。

シングルサインオンとシングルサインオフは、特に水平スケーリングが適切に行われている場合、正しく機能するために慎重なシグナリングが必要です（部分的なサインオフを考慮してください）。セッション状態を単に共有することはほとんど良い解決策ではなく、より良いアプローチは、クラスター内のすべてのノードがアクセスできるユーザー情報に単一の参照ポイントを使用することです。

関連情報への高速キャッシュアクセスに集中すると、複雑で脆弱なセッション共有ソリューションよりもはるかにスケーラブルな結果が得られます。

JEE EAR仕様の機能、つまりEAR内でバインドされた複数のWebアーカイブ間でWebセッションを共有する機能が欠けていると思います。

Weblogicなどのアプリケーションサーバーには、この機能の標準以外の実装があります。

まあ、AFAIKS、あなたがこれをしたい本当の理由はありません。WARは自己完結型のWebアプリケーションであり、独自の（Webアプリケーション固有の）スコープ（セッションスコープなど）を持ちます。複数のWAR間で機能（Javaコード、JSPページ、CSSファイル）を共有する必要がある場合は、それらをJARファイルとしてパッケージ化し、アプリケーションサーバーにデプロイするはるかに賢明なオプションがあります。WARパッケージはより複雑なパッケージ化ソリューションであり、単純な「共通のコード/機能」とは異なる何かをカプセル化するように設計されています。JARはより単純な形式であり、コードと機能をパッケージ化および共有するために設計されています。よりシンプルでより適したパッケージ形式が既に利用できるのに、より複雑で具体的には設計されていないパッケージを使用して何かを共有したいのはなぜですか。

これは、異なるWebアプリがお互いのセッション情報を誤って上書きするのを避けるために、意図的に行われたと思います。あなたの場合は便利かもしれませんが、一般に、ユーザーが同時に2つのWebアプリを使用しているという理由だけで、ユーザーにアプリをクラッシュさせたり特権を昇格させたりすることは望ましくありません。Webアプリ間で明示的に情報を共有することは必ずしも難しくありません。静的なHashMapでクラスを作成し、GUIDをキーとして使用し、URLまたはHTTPパラメーターの一部として転送します。