Чому ВІЙНИ не можуть ділитися інформацією про сеанс?

Я бачив декількох розробників, які шукають рішення цієї проблеми: доступ до інформації про сеанси з іншої ВІЙНИ (навіть коли всередині одного і того ж EAR) - ось кілька прикладів: Будь-який спосіб поділити стан сеансу між різними програмами в tomcat? , Сеанс доступу до іншої веб-програми , різних файлів WAR, спільних ресурсів , Tomcat: Як ділитися даними між двома програмами? , Що робить атрибут crossContext у Tomcat? Чи це дозволяє обмін сеансом? і так далі...

З усього, що я шукав, є деякі конкретні рішення залежно від контейнера, але це якось " суперечить специфікації ". Я також переглянув специфікацію Java EE, не пощастивши знайти відповідь.

Деякі розробники говорять про з'єднання між веб-додатками, але я схильний не погоджуватися. З якої причини можна було б утримувати ВІЙНИ в одній і тій самій EAR, якщо б не з'єднання? Наприклад, до EJB можна отримати доступ локально (навіть якщо в іншому EAR є всередині іншого JAR JJB).

Більш конкретно, одна з моїх ВОЙН обробляє автентифікацію та авторизацію, і я хотів би поділитися цією інформацією з іншими ВІН (у тій самій ЗНО). Раніше мені вдалося подолати подібні проблеми, упакувавши WARs як JARs та ввівши їх у єдиний проект ВІЙНИ (WEB-INF / lib). Але мені це рішення не подобається (воно вимагає величезних зусиль щодо іменування сервлетів тощо).

І жодне рішення не дало відповіді на перше (і найважливіше) питання: Чому ВОЙНИ не можуть ділитися інформацією про сеанси?

Поводьтеся з EAR як з псевдо-віртуальною машиною

EAR - це просто набір файлів WAR, які мають спільну конфігурацію та бібліотеки, як правило, з JAR. Це дає змогу легше керувати колекцією взаємозалежних служб у контейнері додатків. Таким чином, ви можете розглядати EAR як просту форму віртуальної машини, як тільки вона буде розгорнута у свій контейнер.

Так само, як один процес на віртуальній машині не може впливати на інший, те саме стосується і EAR. Усі ВОЙНИ ізольовані для захисту свого внутрішнього стану.

Аутентифікація масштабування

В цілому веб-додатки повинні бути без стану, щоб добре масштабувати. Наявність великої кількості інформації в сеансі - це антидіаграма, яка перешкоджає цьому. Це призводить до конфлікту між бездротовим характером HTTP та необхідністю підтримувати швидкий, налаштований користувачем досвід. Автентифікація - це класичний випадок використання і є поширеним у балаканистих API, що потребують безлічі аутентифікованих запитів для забезпечення функціональності кінцевого користувача.

Одноразове ввімкнення та одновікове вимкнення потребують ретельної сигналізації для правильної роботи (врахуйте часткове вивільнення), особливо коли горизонтальне масштабування встановлено. Просто обмін станом сеансу майже ніколи не є хорошим рішенням, а кращим підходом є використання єдиної точки відліку для інформації користувача, до якої мають доступ усі вузли кластеру.

Концентрування на швидкому кешованому доступі до відповідної інформації дасть набагато більш масштабовані результати, ніж якесь складне, крихке рішення спільного використання сеансів.

Мені здається, це не вистачає функціональності в специфікації JEE EAR - можливість обміну веб-сесіями в декількох веб-архівах, пов'язаних в EAR.

Сервери додатків, такі як Weblogic, не мають std-реалізацій для цієї функції.

Ну, AFAIKS, немає реальної причини, чому ви хотіли б це зробити. ВІЙНА - це самостійна веб-програма, яка має власні (специфічні для веб-додатків) сфери застосування (наприклад, область сеансу). Якщо вам потрібно поділитися функціональністю (код Java, сторінки JSP, файли CSS), між кількома ВІН ви маєте набагато розумніший варіант упаковки їх у вигляді файлів JAR та розміщення їх на сервері додатків. Пакет WAR - це більш складне рішення для упаковки, яке призначене для інкапсуляції чогось іншого, ніж простий "загальний код / ​​функціональність". JAR - більш простий формат І призначений для упаковки та спільного використання коду та функціональності. Чому ви хочете використовувати більш складну та не конкретно розроблену для цього упаковку, щоб поділитися чимось, коли у вас вже є простіший і більш підходящий для цього формат пакету.

Я думаю, що це було зроблено спеціально, щоб уникнути випадкових перезаписів інформації про сеанси, коли різні веб-програми. У вашому випадку це може стати в нагоді, але в цілому ви не хочете, щоб користувачі збивали додаток або збільшували свої привілеї лише тому, що вони використовують два веб-додатки одночасно. Ділитися інформацією між веб-додатками не зовсім важко; просто складіть клас зі статичним HashMap, використовуйте GUID як ключі та передайте їх як частину параметра URL або HTTP.