Именно здесь корпоративная часть Java EE встречается с реальным миром.
Предпосылка использования системы «Предприятие» в основном сосредоточена вокруг управления. В частности, передача решений и конфигурации контейнеру вместо того, чтобы полагаться на само приложение для управления этими ресурсами. Отделив создание ресурсов и управление ими от кода приложения и полагаясь на контейнер, системный администратор получает видимость и доступ к этим ресурсам и, таким образом, имеет возможность настраивать и контролировать приложения на более высоком уровне и обычным способом. , чем использовать для этого специальные механизмы приложения.
Итак, это среда, в которой мы находимся, и это часть того, что движет этими «правилами» спецификации Java EE о том, что вы можете и не можете (не должны) делать.
Теперь спецификация контейнера сервлета больше похожа на дикий запад. В нем нет всех этих функций управления «Enterprise» (имейте в виду, многие контейнеры предоставляют их, но в спецификации они не упоминаются). Например, обслуживание статических файлов — это основная функция веб-контейнера, поэтому вряд ли имеет смысл ограничивать доступ к этим файлам со стороны разработчика. Кроме того, спецификация сервлета предшествовала спецификации EJB и была привязана к среде, а не переделывалась в свете этой среды.
Это дает вам две «противоречивые» спецификации с точки зрения конкретных вещей (например, потоков).
Итак, да, спецификация сервлета «позволяет вам» управлять вашими собственными пулами потоков, даже в приложении Java EE, хотя эти пулы потоков, вероятно, будут в той же самой JVM (и, таким образом, «неуправляемо» потребляя ресурсы Java EE), что и приложение Java EE. Контейнер Java EE.
В конечном итоге это означает, что в реальном мире, да, если вы хотите, вы можете спулировать потоки и тому подобное в контейнере Java EE или в контейнере сервлетов. Ни один из популярных контейнеров не запрещает вам это делать (WebSphere может, я им не пользуюсь).
Но вы не должны. В Java EE (особенно в Java EE 6) есть механизмы и обручи, через которые вы можете переходить, чтобы делать что-то вместо использования пулов потоков. Такие вещи, как WorkManagers, очереди JMS, асинхронные сеансовые компоненты, задания таймера.
В приложении сервлета большинство этих механизмов не существует, поэтому вы не можете использовать их, и вместо этого вы используете «просто Java».
Последствия использования «Просто Java» в веб-приложении, развернутом с помощью приложения Java EE, — это видимость внутри контейнера. Вашему веб-приложению потребуется собственная переменная конфигурации, например, для настройки размера пула потоков, и оно не может полагаться на контейнер для управления этим.
В конце концов, это обычно не имеет большого значения. Большая часть сложности Java EE связана с возможностями управления, которые многие люди не используют. Что касается меня, я использую Java EE и редко использую простую WAR, мне нравится помещать в контейнер как можно больше — пусть он делает свою работу. Тем не менее, у меня есть настраиваемые серверы сокетов, работающие в WAR в контейнерах Java EE, нарушающие все мыслимые правила просто потому, что это было намного проще сделать. «Путь Java EE» не был достаточно гибким для того, что мы хотели сделать, поэтому мы выбрали «Просто Java» и влили код в WAR, чтобы мы могли играть на Диком, Диком Западе, где мужчины были мужчинами и управлял своими потоками.
person
Will Hartung
schedule
31.10.2012
