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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

Так что да, его яблоки с апельсинами, чтобы сравнить этот материал с ЛАМП.

Ответ 3

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. Кто-то может использовать ESI-серверы без участия ASSE bean, кто-то может просто JNDI, кто-то может использовать MESSAGE DRIVEN bean EJB).

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

Ответ 4

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

Но:

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

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

Ответ 10

Что оправдывает высокую цену проприетарных серверов приложений

Ничего! Именно поэтому подавляющее большинство веб-приложений Java развернуто на Tomcat (что бесплатно). Хотя Tomcat не является полноценным сервером приложений Java EE, для большинства приложений он достаточно "достаточно". Если вам действительно нужен полноценный сервер приложений Java EE, Glassfish и JBoss оба превосходны и бесплатны.