Что такое Java EE на самом деле? [закрытый]

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

• почему библиотеки 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? Лучший вопрос. Я не буду притворяться, что знаю, как на него ответить... Но я бы предположил, что ответ: "потому что они не синхронизированы".

с высоты птичьего полета 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": ничего. Тем не менее, использование существующих библиотек может сэкономить много усилий, если вы решаете типичные проблемы предприятия и используете стандартизированный API может предотвратить поставщика.

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

ничего, так как Java EE включает Java SE.

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

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

Что такое Java EE?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

покорять интернет. Это действительно трудно сделать с Java SE апплеты и сокеты:)

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

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

когда разработчик решает, что им" нужна " Java Ээ?

когда им нужна сила Java EE. Все, о чем говорилось выше.

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

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

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

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

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

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