Java EE - это чушь или настоящая ерунда?

Ключевое отличие Java EE от стека LAMP можно свести к одному слову. Сделки.

Большинство небольших систем просто полагаются на систему транзакций, предоставляемую базой данных, и для многих приложений это (очевидно) вполне удовлетворительно.

Но каждый сервер Java EE включает в себя распределенный диспетчер транзакций. Это позволяет безопасно и надежно выполнять более сложные задачи в различных системах.

Самым простым примером этого является простой сценарий получения записи из базы данных, помещения ее в очередь обмена сообщениями (JMS) и последующего удаления этой строки из базы данных. Этот простой случай включает две отдельные системы и не может быть надежно выполнен вне транзакции. Например, вы можете поместить строку в очередь сообщений, но (из-за сбоя системы) не удалять эту строку из базы данных. Вы можете увидеть, как наличие транзакции с поставщиком JMS и отдельной транзакции с базой данных на самом деле не решает проблему, поскольку транзакции не связаны друг с другом.

Очевидно, что этот простой сценарий можно обойти, разобраться и т. Д. Тем не менее, приятная вещь с Java EE заключается в том, что вам не нужно иметь дело с такого рода проблемами - контейнер решает их.

И, опять же, не для каждой проблемы требуется обработка транзакций на этом уровне. Но для тех, кто это делает, это бесценно. И как только вы привыкнете к ним, вы обнаружите, что управление транзакциями на сервере Java EE будет большим преимуществом.

Крупные веб-серверы Java EE (Jboss, WebSphere, WebLogic и т. Д.) И Windows Server / IIS / ASP.NET действительно находятся в другой лиге масштабируемости и производительности, чем ваш типичный стек ламп.

Моя команда отвечает за один из крупнейших сайтов телекоммуникационной коммерции в США, обрабатывающий миллионы обращений в день (одна из наших баз данных имеет размер более 1000 ТБ, чтобы дать вам некоторую перспективу).

Мы используем комбинацию ASP.NET и WebSphere, а также SAP ISA (которая также является решением Java EE) для разных разделов нашего сайта, нет абсолютно никакого способа, которым стек LAMP мог бы справиться с такой нагрузкой без масштабирования до огромных объемов. оборудования .... Раздел стека .NET обрабатывает большую часть нагрузки и работает только на 32 серверах.

Мы также не делаем ничего необычного, например, используем решение типа memcached или статическое HTTP-кеширование ... мы кешируем вызовы SOAP и вызовы базы данных на отдельных серверах приложений, но не используем базу данных в памяти и т. Д. наша платформа пока справляется с этим.

Так что да, это яблоки с апельсинами, если сравнивать такие вещи с LAMP.

С помощью Java EE можно создавать действительно огромные и масштабируемые приложения, и она широко используется в корпоративных вычислениях.

Но:

Мой опыт работы с Java EE был довольно плохим, потому что казалось, что 90% работы, которую делала моя команда, было шаблонным и сантехническим. Наша продуктивность в то время была намного, намного ниже, чем могла бы быть, если бы мы использовали другой стек технологий.

Почти во всех ответах упоминается, что нужно для создания веб- приложения Java EE. Позвольте мне упомянуть еще одно важное соображение. Большинство предприятий предъявляют значительные требования к бэк-офису, когда корпоративное приложение должно интегрироваться с другими приложениями. Это может варьироваться от подключения к какой-нибудь старенькой программе мэйнфрейма COBOL, к стеку LAMP и небольшому приложению Access, которое какой-то бухгалтер создал ночью, и т. Д. Обычно это означает, что вам понадобится какое-то решение для обмена сообщениями, чтобы получить 2 или больше приложений для совместной работы. По моему опыту, я обнаружил, что мир Java EE расширяет возможности для решения этих проблем интеграции больше, чем ваш типичный стек LAMP.

Amazon.com, ebay, google - все они используют подмножество Java EE, и они довольно успешны. Все они используют сервлеты и JSP

Если вы попытаетесь использовать EJB 1.1 или EJB 2.0, масштабируемость будет нарушена. Производительность разработчиков также снижается в результате усложнения модульного тестирования.

Благодаря EJB 3.0 производительность разработчиков и масштабируемость приложений улучшаются.

Итак, в зависимости от того, что нужно вашему приложению, используйте только те части Java EE, которые вам подходят. Сделайте образец POC (доказательство концепции), используя только те части, которые вы собираетесь использовать. Этот POC покажет, насколько хорошо приложение будет работать.

НОВИНКА серверам приложений Java EE не всегда требуется много XML. Они позволят вам использовать аннотации для внедрения зависимостей и сопоставления базы данных.

Более 50% всех корпоративных разработок происходит на Java EE (когда я говорю это, в основном используется подмножество стека Java EE. Кто-то может использовать EJB-компоненты SESSION bean без сохранения состояния, кто-то может просто JNDI, кто-то может использовать EJB-компонент MESSAGE DRIVEN BEAN) .

Надеюсь, поможет.

Ядро Java EE - это просто набор интерфейсов, реализация которых обеспечивается контейнером. Большинство приложений не используют все спецификации Java EE.

Есть два основных аспекта Java EE, о которых люди думают, когда обсуждают его: EJB-компоненты и сервлеты.

У меня нет никакого опыта работы с EJB. Я использую Spring Framework, и поэтому он предоставляет весь "сантехнический и шаблонный" код, на который есть ссылки, как в Ben Ответ Коллинза. Он предоставляет все, что нам нужно для выполнения EJB-компонентов, а также некоторые (транзакции с доступом к базе данных - это то, для чего мы используем его специальные функции, хотя мы используем его контейнер IOC также и для части сервлета).

А сервлеты - это фантастика. Это очень хорошая и проверенная технология.

Ядро сервлета - это цикл запроса и ответа: пользователь что-то запрашивает, а сервер перехватывает запрос и предоставляет ответ на его основе. Цепочку запросов и ответов можно отслеживать с помощью сеанса для одного пользователя.

Что касается высокой цены на проприетарные серверы приложений, я понятия не имею, почему цена такая высокая, но Apache Tomcat - очень хороший контейнер сервлетов и бесплатный. Мы используем Tomcat для тестирования и WebSphere для развертывания (Websphere предоставляется нашим клиентом для использования в приложениях). К сожалению, это только Websphere 6 (обновление 11, как мы с тревогой выяснили, в котором нет исправления для обновления 13, которое позволяет функциям JSTL работать должным образом, когда они содержатся внутри тега JSP), поэтому мы вынуждены использовать Java 1.4x, а не Java 1.5+.

Также существует несколько фреймворков (см. Фреймворк Spring, на который ранее ссылались в качестве примера), которые позволяют легко разрабатывать сервлеты. Если вы используете это только для HTTP / HTML, существует большое количество фреймворков, которые легко помогут вам в этой разработке.

Помимо масштабируемости и прочего, вот одна простая вещь, о которой не упоминалось, что может быть преимуществом: это Java.

• Для Java доступно огромное количество сторонних библиотек, как проприетарных, так и открытых. Я уверен, что существуют огромные бесплатные библиотеки для Perl, Ruby, PHP и т. Д., Но когда дело доходит до коммерческих библиотек для более нишевых областей приложений, они не приближаются к Java (и .NET, и, возможно, C ++. ). Разумеется, нуждаться в каких-либо специальных сторонних библиотеках зависит исключительно от того, какое приложение вы создаете.
• Я думаю, что в мире больше Java-разработчиков, чем разработчиков для любой другой платформы. (Возможно, я ошибаюсь, но это то, что я иногда слышал.)

При выборе платформы в коммерческой среде любой может оказаться важным.

Что касается масштабируемости, Java EE дает вам огромный выбор, которого у вас нет со стеком LAMP или RUBY. Все варианты вращаются вокруг N-уровневых приложений, в то время как большинство приложений LAMP и ruby ​​являются двухуровневыми.

Я разрабатываю приложение и планирую предоставить людям доступ к API через сеть. Java EE позволит мне легко масштабировать средний уровень, не влияя на уровень пользовательского интерфейса. Добавляя интерфейсы в свое приложение, я могу очень легко масштабировать средний уровень. Стек LAMP не понимает этого, встроенный.

Поэтому мне нужны интерфейсы, веб-интерфейс и SOAP API. Теперь хочу API отдыха. Хорошо ... Создайте этот интерфейс, чтобы также попасть на средний уровень ... и добавить больше компьютеров в кластер ... или перейти на мультикластер, на самом деле не имеет значения. Этот средний уровень представляет собой полностью EJB, во многих отношениях более быстрый протокол, чем SOAP.

Теперь предположим, что я хочу добавить возможность отправлять SMS своим пользователям. Мне также нужно сделать это на основе того, что они установили, и это исходит из базы данных. Что касается масштабируемости, я хочу отключить фактическую отправку текста от реализации, которую приложения хотят отправить. Это кричит JMS. Я могу использовать Timer Bean, чтобы запускать каждые X промежутков времени и выяснять, какие сообщения нужно отправить, и помещать каждое сообщение в JMS. Теперь я могу управлять очередью, сколько процессоров над ней работает и т. Д. Я вижу, сколько текстов уходит. Я даже могу поместить приемники в другой ящик, что мало повлияет на производительность других моих серверов.

Что касается масштабирования, я могу видеть, какие из моих EJB-компонентов больше всего страдают, и добавлять к ним дополнительные ресурсы, удаляя ресурсы из других. Я могу сделать это с помощью очередей JMS и любой другой части стека технологий Java EE. Я не только получаю масштабируемость, но и получаю управление ресурсами своих серверов.

Поскольку у LAMP и Ruby еще нет JMS-очереди для асинхронной обработки или возможности легко разместить бизнес-логику на отдельном уровне, их сложнее масштабировать с помощью нескольких интерфейсов. Что вам нужно сделать, чтобы избавиться от логики и сделать ее доступной для другого интерфейса? Допустим, теперь вы предоставляете не только веб-интерфейс, но и пользовательский интерфейс рабочего стола, интерфейс IVR и интерфейс SOAP для своего веб-сайта?

С Java EE и другими языками программ следует обращаться так же, как с любым другим инструментом. Да, он использовался в корпоративной среде, и требуется хорошее мастерство, чтобы заставить эти инструменты работать «идеально» и знать, когда их использовать. В настоящее время я работаю над средой мэйнфрейма, и в какой-то степени используется Java EE. Если речь идет о высокоскоростной транзакции, моим последним выбором будет Java EE. Если требуется многоплатформенная совместимость, то более подходящими будут Java EE, XML и веб-службы.