Java EE - это просто пух или реальный материал?

Question

Я знаком со стеком LAMP и за эти годы успешно развернул несколько веб-сайтов на его основе. Я использовал все, от Apache + modPerl, PHP, Ruby и Rails. При правильном использовании кэширования мой Rails-сайт может выдерживать довольно хорошую нагрузку, но я не говорю о массовости.

Мне никогда не нравился Java как язык или XML в этом отношении, и я очень игнорировал всю сторону Java EE. Для тех, кто имел реальный и непосредственный опыт в обоих мирах: есть ли что-то супер классное в Java EE, которое мне не хватает, или это просто куча горячего воздуха? Чем оправдана высокая цена проприетарных серверов приложений?

Я не троллю здесь: я ищу конкретные примеры вещей, которые Java EE действительно обнаруживает, чего не хватает в современных платформах LAMP, если такие различия существуют. (Современный = Rails, Django и т. Д.). В качестве альтернативы вы можете использовать те вещи, которые LAMP действительно делает лучше (меньше XML работает на одну).

+++++ Обновление от 16 октября 2008 г.

Мне грустно сообщать, что большинство ответов здесь не являются полезными, и просто делятся на одну из двух категорий: «Это масштабируется, потому что здесь три примера больших веб-сайтов» и «Это масштабируется, потому что это действительно на самом деле намного лучше, чем стек LAMP ".

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

Полезное обсуждение

• http://www.subbu.org/blog/2007/10/large-scale-web-site-development
• http://highscalability.com/
• http://www.oreillynet.com/onlamp/blog/2004/07/php_scales.html
• http://www.schlossnagle.org/~george/blog/index.php?/archives/29-Why-PHP-Scales-A-Cranky,-Snarky-Answer.html
• http://blogs.law.harvard.edu/philg/2003/09/20/

Answer 1

Ключевые различия, которые Java EE предлагает для стека LAMP, можно свести к одному слову. Сделки.

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

Но:

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

Answer 5

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 без состояния, кто-то может просто JNDI, кто-то может использовать MESSAGE DRIVEN BEAN EJB).

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

Answer 6

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

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

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

Сервлеты, однако, фантастические. Это очень хорошая и проверенная технология.

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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

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

Answer 9

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