Что такое Java EE?

Ответ 1

Почему библиотеки не могут работать вне среды сервера приложений?

Собственно, они могут. Большинство библиотек могут быть напрямую использованы автономно (в Java SE) или включены в .war(практически это почти всегда Tomcat). Некоторые части Java EE, такие как JPA, имеют явные разделы в своих соответствующих спецификациях, которые рассказывают, как они должны работать и использоваться в Java SE.

Во всяком случае, это не столько среда сервера приложений как таковая, которая здесь поставлена ​​на карту, а наличие всех других библиотек и код интеграции, который их объединяет.

Из-за этого аннотации будут проверяться только один раз для всех ваших классов, а не для каждой библиотеки (EJB, JPA и т.д.), выполняющих это сканирование снова и снова. Также из-за этого CDI-аннотации могут быть применены к EJB beans, и в них могут быть введены администраторы сущностей JPA.

Почему мне нужно что-то массивное, как JBoss, просто для компиляции простого кода для отправки электронной почты?

В этом вопросе есть несколько ошибок:

• Для компиляции вам нужен только банкомат API, который ниже 1 МБ для веб-профиля и чуть более 1 МБ для полного профиля.
• Для запуска вам, очевидно, нужна реализация, но "массивная" преувеличивает все. Например, OpenJDK составляет около 75 МБ, а TomEE (реализация веб-профиля, содержащая почтовую поддержку) составляет всего 25 МБ. Даже GlassFish (реализация полного профиля) составляет всего 53 МБ.
• Почта отлично работает с Java SE (и, следовательно, с Tomcat), используя автономные mail.jar и activation.jar.

Почему библиотеки Java EE не являются "стандартными" и включены в обычную загрузку JVM и/или SDK?

Java EE в какой-то мере была одной из первых попыток разделить уже массивный JDK на куски, которые проще управлять и загружать. Люди уже жалуются, что графические классы (AWT, Swing) и апплеты находятся внутри JRE, когда все, что они делают, запускают некоторые команды на безголовом сервере. И тогда вы также хотите включить все библиотеки Java EE в стандартный JDK?

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

Почему так много предложений Java EE, когда на самом деле есть только два основных варианта стандартной Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?

Существует не только два варианта Java SE. Существует, по крайней мере, IBM JDK, предыдущий BEA (JRocket, который объединяется в Oracle/Sun из-за приобретения), различные другие реализации с открытым исходным кодом и множество реализаций для встроенного использования.

Причиной того, что Java SE и EE является спецификацией, является то, что многие поставщики и организации могут ее реализовать и, таким образом, поощряют конкуренцию и уменьшают риск блокировки поставщика.

Это действительно ничем не отличается от компиляторов C и С++, где у вас много конкурирующих предложений, а также всех, придерживающихся стандарта С++.

Почему версия библиотеки Java EE не синхронизирована со стандартными версиями библиотеки Java (Java EE 6 и Java 7)

Java EE построена на Java SE, поэтому она отстает. Версии действительно соответствуют. Java EE 5 требует Java SE 5. Java EE 6 требует Java SE 6 и так далее. Именно так, в основном, когда Java SE X является текущим, Java EE X-1 является текущим.

Ответ 2

Вот несколько быстро составленных ответов на ваши вопросы...

• Почему библиотеки JavaEE не могут работать без сервера приложений? Услуги, предоставляемые JavaEE (транзакциями, управляемыми контейнерами, инжекцией зависимостей, управляемыми контейнерами, службой таймера и т.д.), По своей сути включают JavaEE-совместимые серверы приложений (например, GlassFish, JBoss, WebSphere и т.д.). Поэтому библиотеки JavaEE не имеют никакой цели без такого контейнера. "Почему мне нужно что-то столь же массивное, как JBoss, чтобы просто составить простой код для отправки электронной почты?" Вы этого не сделаете. Есть способы отправить электронную почту без JavaEE... Но если вы хотите сделать это JavaEE, вам нужен контейнер JavaEE.

• Почему библиотеки JavaEE не включены в загрузку JavaSE? По той же причине, что многие библиотеки не включены: это было бы излишним. Поскольку вы даже не можете использовать библиотеки JavaEE без сервера приложений, зачем их включать? JavaEE следует загружать, если и когда разработчик устанавливает сервер приложений и решает использовать JavaEE.

• Почему так много предложений JavaEE? Действительно ли "очень много" предложений JavaEE? Если да, перечислите некоторые из них. Точнее, я считаю, что существует несколько реализаций тех же API.

• Что можно сделать с JavaEE, с которым они не могут обойтись без стандартной Java? Много. Вы не можете полагаться на сервер приложений для управления транзакциями или контекстами персистентности без JavaEE. Вы не можете разрешить серверу приложений управлять инъекцией зависимостей EJB без JavaEE. Вы не можете использовать службу таймера, управляемую приложениями, без JavaEE. Ответ на этот вопрос должен сделать ответ на первый вопрос совершенно ясным... Большинство услуг, предоставляемых JavaEE, требуют контейнера JavaEE.

• Что вы можете сделать с JavaSE, что вы не можете сделать с JavaEE? Хм... я не знаю.

• Когда разработчик решил, что им нужен JavaEE? Этот вопрос полностью субъективен... Но если вам нужны какие-либо услуги, предоставляемые JavaEE, вы начинаете думать об этом. Если вы не знаете, что такое JavaEE, вы, вероятно, не нуждаетесь в нем.

• Когда разработчик решает, что им не нужен JavaEE? См. Предыдущий ответ.

• Почему версия библиотеки JavaEE не синхронизирована с версией JavaSE? Хороший вопрос. Я не буду притворяться, что знаю, как ответить на него... Но я бы догадался, что ответ: "потому что они не синхронизированы".

Ответ 3

При взгляде на птичий глаз Java EE - это платформа, то есть что-то, на что мы можем опираться.

Принимая более техническую перспективу, стандарт Java Enterprise Edition определяет набор API, обычно используемых для создания корпоративных приложений. Эти API-интерфейсы реализованы серверами приложений - и да, разные серверы приложений могут использовать различные реализации API Java EE.

Однако библиотека java ee не будет работать или компилироваться, если только ваш код не запускается или не имеет доступа к серверу приложений Java EE (например, JBoss, GlassFish, Tomcat и т.д.).

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

Почему мне нужно что-то массовое, чтобы JBoss просто компилировать простой код для отправки электронной почты?

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

Почему библиотеки Java EE не являются "стандартными" и включены в обычную загрузку JVM и/или SDK?

Потому что стандартизированы только API, а не реализации.

Почему так много предложений Java EE

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

Что можно сделать с Java EE, которое они не могут сделать со стандартной Java?

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

Что можно делать со стандартной Java, которую они не могут выполнять с Java EE?

Ничего, поскольку Java EE включает Java SE.

Когда разработчик решает, что они "нуждаются" в Java EE? Когда разработчик решил, что им не нужен Java EE?

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

Ответ 4

Что такое Java EE?

Давайте начнем с определения каноничности в wiki:

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

Главное, что Java EE представляет собой платформу, предоставляет API, а не некоторую конкретную библиотеку.

Что нужно для Java EE?

Основной объем Java EE - это сетевые приложения, в отличие от Java SE, ориентированные на разработку настольных приложений с простой поддержкой сети. Это главное отличие между ними. Масштабируемость, обмен сообщениями, транзакционные транзакции, поддержка БД для каждого приложения... потребность во всем этом увеличилась с развитием сети. Конечно, многие готовые решения, которые предоставляет Java SE, полезны для развития сети, поэтому Java EE расширяет Java SE.

Зачем нам нужны серверы приложений для запуска нашего кода?

Зачем нам нужны операционные системы? Потому что есть много мучительной работы с оборудованием, которое нам нужно сделать, чтобы сделать даже самое простое приложение. И без ОС вам нужно делать это снова и снова. Oversimplified OS - это просто программный контейнер, который предоставляет нам глобальный контекст для запуска наших приложений.

И это серверы приложений. Они позволяют нам запускать наши приложения в их контексте и предоставлять нам много функциональных возможностей высокого уровня, которые необходимы для корпоративных высокопроизводительных сетевых приложений. И мы не хотим писать собственные велосипеды для решения этих проблем, мы хотим написать код, который удовлетворит наши бизнес-потребности.

Другим примером может быть JVM для Java.

Почему Java EE не содержит встроенный сервер приложений?

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

Почему JVM не включает Java EE?

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

Почему так много предложений Java EE?

Поскольку Java EE описывает только поведение. Все могут реализовать его.

Что можно сделать с Java EE, что они не могут сделать с Java SE?

Чтобы покорить Интернет. Это очень сложно сделать с Java-апплетами и сокетами:)

Что можно сделать с Java SE, что они не могут сделать с Java EE?

Как упоминалось выше, Java EE расширяет Java SE, поэтому с Java EE вы сможете делать все, что доступно для Java SE.

Когда разработчик решает, что они "нуждаются" в Java EE?

Когда им нужна мощь Java EE. Все, что упоминалось выше.

Когда разработчик решил, что им не нужен Java EE?

Когда они пишут обычное консольное или настольное приложение.

Почему версии Java SE и Java EE не синхронизированы?

У Java всегда были проблемы с технологией именования и управления версиями. Поэтому эта ситуация не является исключением.

Ответ 5

Java EE - все о концепции контейнера.
Контейнер - это контекст исполнения, в котором будет запускаться ваше приложение и которое предоставляет этот последний набор сервисов. Каждый вид сервиса определяется спецификацией JSR. Например, JSR 907, JTA (java-транзакция Api), которые предоставляют стандартный способ управления распределенной транзакцией в отношении разных ресурсов.
Существует как правило много разных реализаций для данного JSR, реализация, которую вы будете использовать, зависит от поставщика контейнера, но вы действительно не возражаете об этом, так как вы уверены, что поведение соответствует предопределенному контракту: API JSR.
Чтобы воспользоваться преимуществами Java EE, вам нужно запустить приложение внутри контейнера. Двумя основными являются EJB и контейнер сервлетов, которые присутствуют на любом сервере приложений, сертифицированном на Java EE.

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