2015-04-19 3 views
2

Я новичок в java EE и, имея некоторые проблемы с пониманием реализации java EE. Согласно ресурсам, которые я использовал, я понял, что JAVA EE - это всего лишь набор спецификаций, а сервер приложений - это реальная реализация этих спецификаций.Все ли в аннотациях Java EE?

Означает ли это, что архитекторы в oracle просто придумали дизайн (только скелет: интерфейсы, абстрактные классы, классы) и сервер приложений (Glassfish, WebLogic), реализованные в реальном коде?

Все ли в java EE только спецификации?

Как насчет JPA, JAX-RS? Означает ли это, что поставщики приложений не реализовали код для этих спецификаций? Если да, значит ли это также, что поставщики серверов приложений выбрали подмножество спецификации и внедрили его в реальном коде и оставили некоторые другие спецификации, которые будут реализованы другими поставщиками?

+0

в основном да, EE - только спецификация. но обычно (всегда?) они публикуют также так называемую ссылочную реализацию со спецификацией. и если другие поставщики хотят претендовать на жалобу EE, они должны пройти тесты, например. http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html – sodik

+0

Нет, он программно протестирован, прежде чем он будет документирован оракулом. То же самое для JAX-RS, JAX-WS, JPA и т. д. –

+0

Например, GlassFish является эталонной реализацией для большинства API JEE. – OrangeDog

ответ

2

В дополнение к приятным @JoD. ' s ответ, несколько мыслей:

JAVA EE это просто набор спецификаций, а также применение серверов реальное осуществление этих спецификаций.

Точно.

Означает ли это, что архитекторы в оракула, просто придумал дизайн ..

архитекторов на солнце, чтобы быть точным :)

Что о JPA, JAX-RS ? Означает ли это, что поставщики приложений-серверов не реализовали код для этих спецификаций?

No. Каждый сервер приложений должен реализовывать все спецификации, чтобы соответствовать требованиям Java EE. Как они будут реализованы, это зависит от поставщика. Например, реализация JPF в WildFly - Hibernate, но Glassfish использует EclipseLink. Оба они являются надмножеством JPA, поэтому, если вы придерживаетесь только классов, реализующих JPA, вы уверены, что ваше приложение может быть развернуто на разных серверах приложений без каких-либо дополнительных действий. Однако, если вы используете классы из, например, org.eclipse.persistence.*, тогда вы не сможете развернуть на WildFly, если вы не предоставите реализацию EclipseLink вместе с вашим приложением.

2

Аннотация Интерфейсы (API)

Абстрактные интерфейсы позволяют компилировать код в классе/банка/войну, не зная или необходимости точного осуществления на сервере развертывания в. Абстрактные интерфейсы обычно состоят из стандартного (JEE, JCP).

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

Использование зависимостей maven, это делается путем предоставления области provided, в результате чего библиотека будет исключена из упаковки (файл войны).

Интерфейсы обычно называются *-api, например java.faces-api-2.2.jar.

Реализация

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

Отделяя библиотеки от абстрактных интерфейсов (стандартных) от библиотек с конкретной реализацией, вы избегаете компиляции в отношении конкретных API-интерфейсов поставщиков.

Если реализация отсутствует, вы можете установить ее вручную на сервере (скопируйте банку в нужное место) или предоставив ее как зависимость от maven, используя область runtime. Maven в этом случае сделает библиотеки частью упаковки (войны), но никогда не скомпилируется против них. В этом случае вы по-прежнему будете использовать api, используя область provided.

+0

Вы имеете в виду, что банки, которые называются «-api.jar», не включают код реализации, а просто скелет? то откуда мы получаем код реализации – DesirePRG

+0

«-api.jar» обычно содержит скелетный код. Для частей, которые необходимо заполнить (реализация), вы покупаете лицензию или используете открытый исходный код. Обычно также используется эталонная реализация (иногда выбирается из открытого источника). Например, если вы используете JBoss, вы не будете беспокоиться о реализации jee и java faces, это просто. – YoYo

Смежные вопросы