Что такое бизнес логика в java

В рамках приложений, построенных по технологии J2EE связь с базой данных и бизнес-логику, скрытую от пользователя, принято реализовывать с помощью компонентов Enterprise JavaBeans. На момент написания этой лекции последней версией технологии EJB является версия 2.1, в первой половине 2006 года должны появиться инструменты для работы с EJB 3.0 (в рамках J2EE 5.0).

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

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

Компонент Enterprise JavaBeans (EJB) является компонентом, представляющим в J2EEприложении элемент данных или внутренней, невидимой для пользователя логики приложения. Для компонентов EJB определен жизненный цикл в рамках рабочего процесса приложения — набор состояний, через которые проходит один экземпляр такого компонента.

Что такое бизнес-логика? (на примере Django)

Компоненты EJB работают внутри EJB-контейнера, являющегося для них компонентной средой. Функции EJBконтейнера следующие. • Управление набором имеющихся EJB-компонентов, например, поддержкой пула компонентов для обеспечения большей производительности, а также жизненным циклом каждого отдельного компонента, в частности, его инициализацией и уничтожением. • Передача вызовов между EJB-компонентами, а также их удаленных вызовов.

Несколько EJB-контейнеров, работающих на разных машинах, обеспечивают взаимодействие наборов компонентов, управляемых каждым из них. • Поддержка параллельной обработки запросов. • Поддержка связи между EJB-компонентами и базой данных приложения и синхронизация их данных. • Поддержка целостности данных приложения с помощью механизма транзакций. • Защита приложения с помощью механизма ролей: передача прав ролей при вызовах между компонентами и проверка допустимости обращения в рамках роли к методам компонентов. Для разработки набора компонентов EJB нужно, во-первых, для каждого компонента создать один или несколько классов и интерфейсов Java, обеспечивающих реализацию самой функциональности компонента и определение интерфейсов для удаленных обращений к нему, и, во-вторых, написать дескриптор развертывания — XML-файл, описывающий следующее. • Набор EJB-компонентов приложения. • Совокупность элементов кода на Java, образующих один компонент. • Связь свойств компонента с полями таблиц БД и связями между таблицами. • Набор ролей, правила доступа различных ролей к методам компонентов, правила передачи ролей при вызовах одними компонентами других. • Политику компонентов и их методов по отношению к транзакциям. • Набор ресурсов, которыми компоненты могут пользоваться в своей работе. Правила создания EJB компонента зависят от его вида. Различают три таких вида EJBкомпонентов. • Компоненты данных (сущностные, entity beans) . Представляют данные приложения и основные методы работы с ними. • Сеансовые компоненты (session beans) . Представляют независимую от пользовательского интерфейса и конкретных типов данных логику работы приложения, называемую иногда бизнес-логикой.

Что такое “бизнес логика”? И как начать ее понимать

• Компоненты, управляемые сообщениями (message driven beans) . Тоже предназначены тоже для реализации бизнес-логики. Но, если сеансовые компоненты предоставляют интерфейс для синхронных вызовов, компоненты, управляемые сообщениями, предоставляют асинхронный интерфейс. Клиент, вызывающий метод в сеансовом компоненте, ждет, пока вызванный компонент не завершит свою работу.

Компоненту же, управляемому сообщениями, можно отослать сообщение и продолжать работу сразу после окончания его передачи, не дожидаясь окончания его обработки. Далее описываются основные правила построения EJB компонентов разных видов. Более детальное описание этих правил можно найти в [1,2].

Компоненты данных и сеансовые компоненты

Компонент данных или сеансовый компонент могут состоять из следующих элементов: пара интерфейсов для работы с самим компонентом — удаленный интерфейс и локальный интерфейс ; пара интерфейсов для поиска и создания компонентов — удаленный исходный интерфейс и локальный исходный интерфейс ; класс компонента , реализующий методы работы с ним; и, для компонентов данных, — класс первичного ключа . Обязательно должен быть декларирован класс компонента и один из интерфейсов — удаленный или локальный. Для компонентов данных обязательно должен быть определен класс первичного ключа. • Удаленный интерфейс (remote interface) . Этот интерфейс декларирует методы компонента, к которым можно обращаться удаленно, т.е. из компонентов, работающих в рамках другого процесса или на другой машине.

Удаленный интерфейс должен наследовать интерфейс javax.ejb.EJBObject (в свою очередь, наследующий java.rmi.Remote ). Для компонента данных он определяет набор свойств (в смысле JavaBeans, т.е. пар методов Type getName() / void setName(Type) ), служащих для работы с отдельными полями данных или компонентами, связанными с этим компонентом по ссылкам. Это могут быть и часто используемые дополнительные операции, как-то выражающиеся через операции с отдельными полями данных, в том числе и вычислимые свойства.

Например, для книги в базе данных приложения хранится набор ссылок на данные об ее авторах, а число авторов может быть часто используемым свойством книги, вычисляемым по этому набору ссылок. Для сеансового компонента методы удаленного интерфейса служат для реализации некоторых операций бизнес-логики или предметной области, вовлекающих несколько компонентов данных. • Локальный интерфейс (local interface) . По назначению этот интерфейс полностью аналогичен удаленному, но декларирует методы компонента, которые можно вызывать только в рамках того же процесса.

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

Однако, при использовании локального интерфейс компонента нужно обеспечить развертывание этого компонента в рамках того же EJBконтейнера, что и вызывающий его компонент. Локальный интерфейс должен наследовать интерфейсу javax.ejb.EJBLocalObject . • Удаленный исходный интерфейс (remote home interface). Исходные интерфейсы служат для поиска и создания компонентов. Такой интерфейс может декларировать метод поиска компонента данных по значению его первичного ключа findByPrimaryKey(…) и метод создания такого компонента с указанным значением первичного ключа create(…) . Могут быть также определены методы, создающие компонент по набору его данных или возвращающие коллекцию компонентов, данные которых соответствуют аргументам такого метода. Например, метод, создающий компонент, который представляет книгу с данным названием, createByTitle(String title) , или метод, находящий все книги с данным набором авторов Collection

findByAuthors(Collection authors) . Удаленный исходный интерфейс предназначен для создания и поиска компонентов извне того процесса, в котором они работают. Его методы возвращают ссылку на удаленный интерфейс компонента или коллекцию таких ссылок.

Такой интерфейс должен наследовать интерфейсу javax.ejb.EJBHome (являющемуся наследником java.rmi.Remote ). • Локальный исходный интерфейс (local home interface) . Имеет то же общее назначение, что и удаленный исходный интерфейс, но служит для работы с компонентами в рамках одного процесса. Соответственно, его методы поиска или создания возвращают ссылку на локальный интерфейс компонента или коллекцию таких ссылок.

Должен наследовать интерфейсу javax.ejb.EJBLocalHome . • Класс компонента (bean class). Этот класс реализует методы удаленного и локального интерфейсов (но не должен реализовывать сами эти интерфейсы!). Он определяет основную функциональность компонента.

Для компонентов данных такой класс должен быть абстрактным классом, реализующим интерфейс javax.ejb.EntityBean . Свойства, соответствующие полям хранимых данных или ссылкам на другие компоненты данных, должны быть определены в виде абстрактных пар методов getName() / setName() . В этом случае EJB-контейнер может взять на себя управление синхронизацией их значений с базой данных. Вычислимые свойства, значения которых не хранятся в базе данных, реализуются в виде пар неабстрактных методов.

Для сеансовых компонентов класс компонента должен быть неабстрактным классом, реализующим интерфейс javax.ejb.SessionBean и все методы удаленного и локального интерфейсов. Кроме того, класс компонента может (а иногда и должен) реализовывать некоторые методы, которые вызываются EJB-контейнером при переходе между различными этапами жизненного цикла компонента.

Например, при инициализации экземпляра компонента всегда вызывается метод ejbCreate() . Для компонентов данных он принимает на вход и возвращает значение типа первичного ключа компонента. Если первичный ключ — составной, он должен принимать на вход значения отдельных его элементов.

Такой метод для компонента данных должен возвращать null и всегда должен быть реализован в классе компонента. Для сеансовых компонентов он имеет тип результата void , а на вход принимает какие-то параметры, служащие для инициализации экземпляра компонента.

Для каждого метода исходных интерфейсов с именем createSomeSuffix(…) в классе компонента должен быть реализован метод ejbCreateSomeSuffix(…) с теми же типами параметров. Для компонентов данных все такие методы возвращают значение типа первичного ключа, для сеансовых — void . Другие методы жизненного цикла компонента, которые можно перегружать в классе компонента, декларированы в базовых интерфейсах компонентов соответствующего вида ( javax.ejb.EntityBean или javax.ejb.SessionBean ). Это, например, ejbActivate() и ejbPassivate() , вызываемые при активизации и деактивизации экземпляра компонента; ejbRemove() , вызываемый перед удалением экземпляра компонента из памяти; для компонентов данных — ejbStore() и ejbLoad() , вызываемые при сохранении данных экземпляра в базу приложения или при их загрузке оттуда.

Схема жизненного цикла компонента данных показана на Рис. 75. Сеансовые компоненты могут поддерживать состояние сеанса, обеспечивая пользователю возможность получения результатов очередного запроса с учетом предшествовавших запросов в рамках данного сеанса, или не поддерживать. Во втором случае компонент реализует обработку запросов в виде чистых функций. Жизненный цикл сеансового компонента различается в зависимости от того, поддерживает ли компонент состояние сеанса или нет.

Не существует Class.newInstance() Object.finalize () setEntityContext() unsetEntityContext() В пуле ejbPassivate() ejbCreate() ejbPostCreate() ejbRemove() ejbActivate() Активен ejbLoad() обычные методы ejbStore() Рисунок 75. Жизненный цикл EJB компонента данных. Схема жизненного цикла сеансового компонента с состоянием показана на Рис. 76.

Читайте также: Что такое бизнес семинар

Отличие от жизненного цикла компонента данных единственное — метод ejbCreate() сразу переводит компонент в активное состояние. Не существует тайм-аут Class.newInstance() или исключение setSessionContext() ejbRemove() ejbCreate() ejbPassivate() Пассивен Активен ejbActivate() обычные методы Рисунок 76. Жизненный цикл сеансового компонента с состоянием. Жизненный цикл сеансового компонента без состояния гораздо проще.

Его схема представлена на Рис. 77. • Класс первичного ключа (primary key class). Декларируется только для компонентов данных, если в этом качестве нельзя использовать подходящий библиотечный класс. Определяет набор данных, которые образуют первичный ключ записи базы данных, соответствующей одному экземпляру компонента. Чаще всего это библиотечный класс, например, String или Integer . Пользовательский класс необходим, если первичный ключ составной, т.е. состоит из нескольких значений

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

Такой класс также должен реализовывать интерфейс java.io.Serializable . Не существует Class.newInstance() ejbRemove() setSessionContext() ejbCreate() Активен обычные методы Рисунок 77. Жизненный цикл сеансового компонента без состояния. Ниже приведены примеры декларации класса компонента и интерфейсов для компонентов данных, соответствующих простой схеме из двух таблиц, которая изображена на Рис. 78.

В рамках этой схемы, состоящей из таблиц, где хранятся данные книг и организацийиздателей, каждая книга связана с одним и только одним издателем, а каждый издатель может иметь ссылки на некоторое множество книг (возможно, пустое). Каждая таблица имеет поле ID , являющееся первичным ключом. Таблица Book имеет поле PublisherID , содержащее значение ключа записи об издателе данной книги.

Publisher ID : int Title : String
Book ID : int Title : String ISBN : String PublisherID : int
Рисунок 78. Пример схемы БД. Примеры кода удаленных интерфейсов для компонентов, представляющих данные о книгах и издателях в рамках EJB-приложения. package ru.msu.cmc.prtech.examples; import java.rmi.RemoteException; import java.util.Collection; import javax.ejb.EJBObject; public interface PublisherRemote extends EJBObject < public String getTitle () throws RemoteException; public void setTitle (String title) throws RemoteException; public Collection getBooks () throws RemoteException;

public void	setBooks (Collection books)
throws RemoteException;
public void addBook		(String title, String isbn)

throws RemoteException; public void removeBook (String title, String isbn) throws RemoteException; >
package ru.msu.cmc.prtech.examples; import java.rmi.RemoteException; import javax.ejb.EJBObject; public interface BookRemote extends EJBObject <

public String	getTitle ()	throws RemoteException;
public void	setTitle (String title) throws RemoteException;
public String	getISBN ()	throws RemoteException;
public void	setISBN (String isbn) throws RemoteException;

public PublisherRemote getPublisher () throws RemoteException; public void setPublisher (PublisherRemote publisher) throws RemoteException; > Примеры кода удаленных исходных интерфейсов. package ru.msu.cmc.prtech.examples; import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; import javax.ejb.FinderException; public interface PublisherHomeRemote extends EJBHome < public PublisherRemote create (Integer id) throws CreateException, RemoteException; public PublisherRemote findByPK (Integer id) throws FinderException, RemoteException; >package ru.msu.cmc.prtech.examples; import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; import javax.ejb.FinderException; public interface BookHomeRemote extends EJBHome < public BookRemote create (Integer id) throws CreateException, RemoteException; public BookRemote createBook (String title, String isbn) throws CreateException, RemoteException; public BookRemote findByPK (Integer id) throws FinderException, RemoteException; >Примеры кода классов компонентов. Показано, как реализовывать дополнительные, не поддерживаемые контейнером автоматически, методы работы со связями между данными об издателях и книгах и дополнительные методы создания компонентов. package ru.msu.cmc.prtech.examples; import java.util.Collection; import java.util.Iterator; 250
import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EntityBean; import javax.naming.InitialContext; import javax.naming.NamingException; public abstract class PublisherBean implements EntityBean < public Integer ejbCreate (Integer pk) < setId(pk); return null ; >public void ejbPostCreate (Integer pk) < >public abstract Integer getId ();

public abstract void		setId (Integer pk);
public abstract String		getTitle ();
public abstract void		setTitle (String title);
public abstract	Collection getBooks ();
public abstract	void	setBooks (Collection books);

public void addBook (String title, String isbn) < try < InitialContext context = new InitialContext(); BookHomeRemote bookHome = (BookHomeRemote)context.lookup(«BookHomeRemote»); BookRemote book = bookHome.createBook(title, isbn); Collection books = getBooks(); books.add(book); >catch (NamingException e) < e.printStackTrace(); >catch (CreateException e) < e.printStackTrace(); >catch (RemoteException e) < e.printStackTrace(); >> public void removeBook (String title, String isbn) < Collection books = getBooks(); Iterator it = books.iterator(); try < while (it.hasNext()) < BookRemote book = (BookRemote)it.next(); if ( book.getTitle().equals(title) book.getISBN().equals(isbn) ) < it.remove(); break ; >> > catch (RemoteException e) < e.printStackTrace(); >> > 251

Источник: studfile.net

Джава EE: описание, особенности, история развития

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

Огромным спросом в последнее время начали пользоваться сетевые утилиты. Для их написания тоже можно использовать Java семейство. Пример – JavaScript. Но Джава – это более безопасный язык программирования.

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

Определение

Можно изучить Google по соответствующему запросу, но в нем полно информации, в которой легко запутаться. Согласно данным, полученным из поисковиков и сопутствующей специализированной литературы, JavaEE – это документация и набор спецификаций Java, которые описывают архитектуру платформы серверного типа. Используется все это для решения задач крупного и среднего бизнеса.

Java ЕЕ – специальная платформа, в основе которой лежит Java SE. Позволяет писать коды для приложений:

крупномасштабных;
многоуровневых;
масштабируемых;
надежных;
безопасных;
работающих с Сетью;
объемных.

Такие утилиты называются корпоративными. Но и небольшие студии тоже нередко задействуют соответствующую «среду» для некоторых задач.

Немного истории

Началось развитие Java EE, согласно информации Google, в 1998 году. Тогда начал работать проект под названием JPE Project. Через к декабрю следующего года вышел первый релиз рассматриваемой платформы. Она объединила в себе:

Так происходила постепенная доработка рассматриваемого набора инструментов. К выходу 5 версии, состоявшемуся в 2006 году по данным Google, проект переименовали. Он начал называться Java Enterprise Edition или просто JEE.

Это – начало стремительного развития платформы. В сентябре 2019 года вышла ее 8 версия. Это на данный момент последняя свежая разработка, активно применяемая на практике.

Важно: в 2017 году права на Java EE были переданы Eclipse. С тех пор проект носит название Jakarta EE.

Об архитектуре создаваемых утилит

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

Jakarta EE-приложения создаются с учетом наличия нескольких ключевых свойств:

наличие нескольких уровней;
вложенность – в них есть сервер приложений, который включает в себя контейнеры элементов.

Это – основные моменты, на которые необходимо обратить внимание во время работы с Jakarta и коддинге при помощи нее.

Несколько слов об уровнях

Многоуровневые утилиты, если посмотреть определения в Google – софт, разделенный по функциональным принципам на изолированные друг от друга модули. Они называются слоями или уровнями.

Корпоративные приложения (написанные на Java EE и не только) подразделяются по уровням на:

клиентские;
средние;
доступ к имеющейся информации.

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

Уровень «клиент»

Самый простой вариант веб-утилит по информации, полученной из Google. Представляет собой утилиту, которая запрашивает электронные материалы у Java EE server. Она направляет запрос на средний уровень.

Сервер при подобных обстоятельствах производит обработку полученной команды, после чего направляет клиенту итоговый результат. Примеры софта клиентского уровня – браузеры. Сюда также удается отнести самостоятельные программы серверного характера, лишенные графических интерфейсов.

Средний уровень

В Google включает в себя наличие веб-уровня или уровня бизнес-логики. В первом случае речь идет о компонентах, которые отвечают за обеспечение связи и взаимодействия между clients, а также уровнем бизнес-логики.

Java EE здесь применяет следующие технологии:

Далее идет уровень бизнес-логики. Он, если верить Google, состоит из компонентов, отвечающих за реализацию всей бизнес-логики проекта.

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

На соответствующем level применяются такие технологии:

EJB;
Message Service;
JAX-RS REST;
Java Persistence API.

Все это есть в Jakarta. Зная подобные особенности, удастся довольно легко создать программный код среднего уровня.

Доступ к информации – что следует запомнить перед коддингом

Google уверяет – это level корпоративных информационных систем (или EIS сокращенно). Состоит из:

серверов баз данных;
систем планирования ресурсов (ERP);
других источников информации, необходимой для работы компании.

Именно к нему по Google уровень бизнес-логики будет обращаться, чтобы получить важные для дальнейшей обработки сведения.

Здесь Java EE применяет следующие технологии:

JTA;
JDBC;
Connector Architecture;
Persistence API.

Но это не все технологические возможности. Иной функционал при серверной разработке тоже применяется на практике.

Контейнеры и сервера – без чего немыслима Jakarta

Чтобы лучше понимать, как работает контент, созданный через Java EE, требуется изучить компоненты, сервера приложений и контейнеры. Уточнить, что это такое, получается при помощи поисковых систем – Google, Yandex и так далее.

Согласно полученной информации из поисковиков, Джава интерфейс не имеет функциональности. Он отвечает за контракт, который реализует оную. Интерфейс воплощают в жизнь другие классы. У одного и интерфейса могут присутствовать несколько реализаций с небольшими отличиями. Аналогичным образом ситуация обстоит и Джава ЕЕ.

Это просто некий набор спецификаций.

Серверы – определение и особенности

Соответствующие спецификации отвечают за реализацию Джава ЕЕ сервера. Он представлен приложением, использующим API-интерфейсы платформы. Данное серверное приложение предоставляет стандартные службы JavaEE.

Servers иногда носят название «сервер приложений». Информация оного способна включать в себя компоненты утилиты, каждая из которых соответствует тому или иному level в иерархии многоуровневого характера. Сервер отвечает за предоставление соответствующим элементам разнообразных сервисов, представленных контейнерной формой.

Полезности по контейнерам

Контейнер по определению Google – интерфейс между размещенными на них компонентами, а также низкоуровневыми платформо-независимыми функциональными возможностями, отвечающими за поддержку компонента.

Контейнер отвечает за предоставление компонентам, которые расположены внутри, доступа к тем или иным службам. Это — изолированное хранилище информации/программного кода. За счет контейнеризации утилита способна работать с максимальной безопасностью. Обеспечивают мобильность и сохраняют технические сложности от пользователей.

Java EE по Google имеет несколько типов контейнеров:

Апплетные. Обрабатываются основной массой интернет-обозревателей. Во время разработки апплетов удается больше времени уделять визуальной составляющей софта. Контейнер будет обеспечивать для реализации поставленной задачи безопасную среду.
ACC – клиентского приложения. Предусматривает некий набор Java классов, а также библиотек, баз данных и иных файлов, которые пригодятся в Джаве SE для внедрения, манипулирования безопасностью, функционирования служб именования.
Web-Container. Google уверяет, что он отвечает за предоставление базовых служб управления и исполнения веб-компонентов. Создает экземпляры, инициализирует и вызывает сервлеты, поддерживает протоколы HTTPS и HTTP. Успешно задействуется для того, чтобы передавать веб-странички к клиент-браузерам.
Java Enterprise Bean (или EJB). Если верить Google – контейнер, необходимый для управления и исполнения компонентов моделей EJB, имеющих уровень бизнес-логики соответствующего софта. Отвечает за непосредственное создание новых сущностей компонентов EJB, управление их жизненными циклами. Способен обеспечивать реализацию транзакций, безопасности, параллельного доступа, распределения, служб именования и асинхронный вызов.

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

Дела компонентные

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

Апплеты. Это софт из графического пользовательского интерфейса, который обрабатывается и выполняется непосредственно в браузере. Работают по Google с весьма мощным интерфейсом Swing API. Это необходимо, чтобы создавать уникальные пользовательские interfaces.
Приложения. Программы, работающие на клиентской стороне. Обычно относятся к графическому пользовательскому интерфейсу, задействуются для того, чтобы производить пакетную обработку информации.
Веб-утилиты. Включают в себя сервлеты и их фильтры, слушатели веб-событий, страничек JSP/JSF. Выполнение оных осуществляется в веб-контейнерах. Такой софт отвечает за HTTP-запросы от web-clients. Сервлеты тоже имеют поддержку конечных точек веб-служб (SOAP, RESTfull).
Корпоративные программы. Выполняются непосредственно в контейнере EJB. Компоненты такого типа – это возможность обработки транзакционной бизнес-логики. Доступ по Google может быть локальным и удаленным (при помощи протоколов RMI).

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

Выше представлен пример типичной архитектуры Java EE-софта.

Несколько слов о технологиях

Общее представление об архитектуре рассматриваемого типа контента должно сложиться. Если возникают трудности с пониманием данной темы, можно посмотреть обучающие уроки в Google в выбранном направлении.

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

Клиенты

На clients level применяются следующие варианты:

Что за технология	Принцип применения
Сервлеты	Java классы, обрабатывающие клиентские запросы динамическим путем. Отвечают за формирование ответов. Представлены чаще всего HTML страничек.
JSF	Фреймворк, предназначенный для веб-утилит с пользовательским интерфейсом. Дает включать на страницах компоненты пользовательских интерфейсов, валидировать и преобразовывать информационные компоненты, сохранить оные на сервере.
JSFFT	Подтип JSF, который использует XHTML-странички.
JSP	Обычный текстовый документ, преобразованный в сервлет. Отвечает за возможность добавления динамического компонента на статические странички.
JSTL	Теговая библиотека. В ней инкапсулирован основной функционал в контенте JSP-страничек.
Expression Language	Согласно Google – набор стандартных тегов, задействованных в JSP и Facelets страничках. Используется для того, чтобы получать доступ к компонентам Джава ЕЕ.
CDI	Сервисный набор, созданный через контейнеры Java EE. Необходим для того, чтобы осуществлять управление жизненными циклами компонентов. Помогает «подключать» новые элементы в клиентские объекты с высоким уровнем безопасности.
JBC	Объекты, выступающие как временные хранилища информации. Нужны для страниц созданного софта.

С клиентским level удалось разобраться. Далее стоит посмотреть на технологии иных уровней.

Бизнес-логика и ее возможности

В табличке представлены технологии, которые по Google реализовываются в бизнес-логике:

Технология	Описание
EJB	Компоненты, которые относятся к управляемому типу. Это – основной функционал утилиты.
JAX-RS RESULTfull	API, необходимые для веб-серверной разработки. Соответствуют стилю REST.
JAX-WS	API, которые применяются при создании и применении веб-сервисов SOAP.
JPA	API, обеспечивающие пользователям и разработчикам доступ к информации. Google говорит, что за счет этой технологии происходит преобразование информации в объекты языка программирования Джава. Обратный принцип действия тоже имеет место.
Managed Beans	Элементы, которые могут управляться. Представлены бизнес-логикой утилиты. Им не нужны транзакционные функции и функции безопасности EJB для работы.
JMS	Установленный стандарт обмена сообщениями. За счет него приложения Java EE могут создавать, получать, отправлять и читать «письма».

Но и это еще не все. Чтобы лучше понимать технологии рассматриваемых утилит, в Google можно отыскать специализированные бесплатные уроки. Там они разобраны более детально.

Доступ к данным и его технологии

А вот технологии, которые применяются на level «доступ к информации»:

Название	Характеристика
JDBC	API в Java EE низкого уровня. Обеспечивает хранение информации и доступ к ним из хранилищ.
Persistence API	API, отвечающая за доступ к информации в хранилище и переделывание оных в объекты языка программирования Джава. Обратный принцип тоже имеет место. Скрывает сложность.
Connector Architecture	Подключает иные корпоративные ресурсы. Пример – ERP и CRM.
JTA	API, необходимый для того, чтобы определять и управлять транзакциями.

Вся предложенная вниманию информация будет полезна и новичкам, и тем, кто давно практикуется в разработке. В Google удастся найти по этому направлению различные уроки. На первых порах поможет эта ссылка. А вот пример утилиты на Джава ЕЕ.

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

Источник: otus.ru

Введение в Java EE

Сегодня поговорим о том, что это такое — Java EE: из чего состоит, каковы особенности архитектуры Java EE приложений, и приведем описания различных технологий данной платформы. Тема обширная сама по себе, но на азах мы не остановимся. В конце проведем небольшое сравнение Java EE со Spring Framework и ответим на вопрос: “что лучше учить” (спойлер: конечно же, учить нужно всё =) ) Начнем с основ.

Java EE — что это?

Java EE — это платформа, построенная на основе Java SE, которая предоставляет API и среду времени выполнения для разработки и запуска крупномасштабных, многоуровневых, масштабируемых, надежных и безопасных сетевых приложений. Подобные приложения называют корпоративными (Enterprise applications), так как они решают проблемы, с которыми сталкиваются большие бизнесы. Однако использовать подобные приложения и преимущества, которые дает Java EE, могут не только крупные корпорации и правительственные структуры. Решения, которые предлагает платформа Java EE, полезны, а порой просто необходимы отдельным разработчикам и небольшим организациям.

Развитие Java EE

J2EE 1.2 (Декабрь 1999)
J2EE 1.3 (Сентябрь 2001)
J2EE 1.4 (Ноябрь 2003)
Java EE 5 (Май 2006)
Java EE 6 (Декабрь 2009)
Java EE 7 (Май)
Java EE 8 (Август 2017)
Jakarta EE 8 (Сентябрь 2019)

Архитектура Java EE приложений

во-первых, многоуровневость. Java EE приложения — многоуровневые, и об этом мы еще поговорим подробнее;
во-вторых, вложенность. Есть Java EE сервер (или сервер приложений), внутри него располагаются контейнеры компонентов. В данных контейнерах размещаются (бинго!) компоненты.

Уровни приложений

клиентский;
средний уровень;
уровень доступа к данным.

JavaServer Faces technology (JSF);
Java Server Pages (JSP);
Expression Language (EL);
Servlets;
Contexts and Dependency Injection for Java EE (CDI).

Enterprise JavaBeans (EJB);
JAX-RS RESTful web services;
Java Persistence API entities;
Java Message Service.

Java Database Connectivity API (JDBC);
Java Persistence API;
Java EE Connector Architecture;
Java Transaction API (JTA).

Сервера приложений, контейнеры, компоненты

Взглянем на определение Java EE из Википедии. Java EE — набор спецификаций и соответствующей документации для языка Java, описывающий архитектуру серверной платформы для задач средних и крупных предприятий. Чтобы лучше понять, что означает в данном контексте “набор спецификаций”, проведем аналогию с Java-интерфейсом. Сам по себе Java-интерфейс лишен функциональности. Он просто определяет некоторый контракт, согласно которому реализуется некоторая функциональность. А вот реализуют интерфейс уже другие классы. Причем у одного интерфейса допустимы несколько реализаций, каждая из которых может друг от друга отличаться некоторыми деталями. Со спецификацией все точно так же. Голая Java EE — это просто набор спецификаций. Данные спецификации реализуют различные Java EE сервера. Java EE сервер — это серверное приложение, которое реализует API-интерфейсы платформы Java EE и предоставляет стандартные службы Java EE. Серверы Java EE иногда называют серверами приложений. Данные сервера могут содержать в себе компоненты приложения, каждый из которых соответствует своему уровню в многоуровневой иерархии. Сервер Java EE предоставляет этим компонентам различные сервисы в форме контейнера. Контейнеры — это интерфейс между размещенными на них компонентами и низкоуровневыми платформо-независимыми функциональными возможностями, поддерживающими компонент. Контейнеры предоставляют размещенным на них компонентам определенные службы. Например, управление жизненным циклом разработки, внедрение зависимости, параллельный доступ и т. д. Контейнеры скрывают техническую сложность и повышают мобильность. В Java EE существует четыре различные типа контейнеров:

Контейнеры апплетов выполняются большинством браузеров. При разработке апплетов можно сконцентрироваться на визуальной стороне приложения, в то время как контейнер обеспечивает безопасную среду.
Контейнер клиентского приложения (ACC) включает набор Java-классов, библиотек и других файлов, необходимых для реализации в приложениях Java SE таких возможностей, как внедрение, управление безопасностью и служба именования.
Веб-контейнер предоставляет базовые службы для управления и исполнения веб-компонентов (сервлетов, компонентов EJB Lite, страниц JSP, фильтров, слушателей, страниц JSF и веб-служб). Он отвечает за создание экземпляров, инициализацию и вызов сервлетов, а также поддержку протоколов HTTP и HTTPS. Этот контейнер используется для подачи веб-страниц к клиент-браузерам.
EJB (Enterprise Java Bean) контейнер отвечает за управление и исполнение компонентов модели EJB, содержащих уровень бизнес-логики приложения. Он создает новые сущности компонентов EJB, управляет их жизненным циклом и обеспечивает реализацию таких сервисов, как транзакция, безопасность, параллельный доступ, распределение, служба именования либо возможность асинхронного вызова.

Также в Java EE выделяют четыре типа компонентов , которые должна поддерживать реализация Java EE спецификации:

Апплеты — это приложения из графического пользовательского интерфейса (GUI), выполняемые в браузере. Они задействуют насыщенный интерфейс Swing API для производства мощных пользовательских интерфейсов.
Приложениями называются программы, выполняемые на клиентской стороне. Как правило, они относятся к графическому пользовательскому интерфейсу (GUI) и применяются для пакетной обработки.
Веб-приложения (состоят из сервлетов и их фильтров, слушателей веб-событий, страниц JSP и JSF) — выполняются в веб-контейнере и отвечают на запросы HTTP от веб-клиентов. Сервлеты также поддерживают конечные точки веб-служб SOAP и RESTful.
Корпоративные приложения (созданные с помощью технологии Enterprise Java Beans, службы сообщений Java Message Service, интерфейса Java API для транзакций, асинхронных вызовов, службы времени) выполняются в контейнере EJB. Управляемые контейнером компоненты EJB служат для обработки транзакционной бизнес-логики. Доступ к ним может быть как локальным, так и удаленным по протоколу RMI (или HTTP для веб-служб SOAP и RESTful).

На диаграмме ниже представлена типичная архитектура Java EE приложения:

Технологии

Итак, с архитектурой разобрались. Общая структура должна быть ясна. В процессе описания компонентов архитектуры мы затронули некоторые технологии Java EE, такие как EJB, JSP и пр. Давайте поближе посмотрим на них. В таблице ниже приведены технологии, которые используются в основном на клиентском уровне:

Технология Назначение

Servlets	Java-классы, которые динамически обрабатывают клиентские запросы и формируют ответы (обычно HTML страницы).
Java Server Faces (JSF)	Фреймворк для построения веб приложений с пользовательским интерфейсом. Позволяет включать на страницу компоненты пользовательского интерфейса (например, поля и кнопки), преобразовывать и валидировать данные компоненты, а также сохранять эти данные в хранилищах на стороне сервера.
Java Server Faces Facelets technology	Представляет из себя подтип приложения JSF, в котором вместо JSP страниц используются XHTML страницы
Java Server Pages (JSP)	Текстовые документы, которые компилируются в сервлеты. Позволяет добавлять динамический контент на статические страницы (например, HTML-страницы)
Java Server Pages Standard Tag Library (JSTL)	Библиотека тегов, в которой инкапсулирована основная функциональность в контексте JSP страниц.
Expression Language	Набор стандартных тегов, которые используются в JSP и Facelets страницах для доступа к Java EE компонентам.
Contexts and Dependency Injection for Java EE (CDI)	Представляет собой набор сервисов, предоставляемых Java EE контейнерами, для управления жизненным циклом компонентов, а также внедрения компонентов в клиентские объекты безопасным способом.
Java Beans Components	Объекты, которые выступают в роли временного хранилища данных для страниц приложения.

В таблице ниже приведены технологии используемые на уровне бизнес-логики:

Технология Назначение

Enterprise Java Beans (enterprise bean) components	EJB — это управляемые компоненты, в которых заключена основная функциональность приложения.
JAX-RS RESTful web services	Представляет из себя API для разработки веб-сервисов, соответствующих архитектурному стилю REST.
JAX-WS web service endpoints	API для создания и использования веб-сервисов SOAP.
Java Persistence API (JPA) entities	API для доступа к данным в хранилищах данных и преобразования этих данных в объекты языка программирования Java и наоборот.
Java EE managed beans	Управляемые компоненты, которые предоставляют бизнес-логику приложения, но не требуют транзакционных функций или функций безопасности EJB.
Java Message Service	API службы сообщений Java (JMS) — это стандарт обмена сообщениями, который позволяет компонентам приложения Java EE создавать, отправлять, получать и читать сообщения. Что обеспечивает распределенную, надежную и асинхронную связь между компонентами.

В таблице ниже приведены технологии, используемые на уровне доступа к данным:

ERP (англ. Enterprise Resource Planning, система планирования ресурсов предприятия),
CRM (англ. Customer Relationship Management, система управления взаимоотношениями с клиентами).

Java EE vs Spring

Конкурентном Java EE считается Spring Framework. Если взглянуть на развитие двух данных платформ, выходит интересная картина. Первые версии Java EE были созданы при участии IBM. Они вышли крутыми, но неповоротливыми, тяжеловесными, неудобными в использовании.

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

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

Постепенно то, что раньше называлось Spring, сначала стало одним из проектов, а потом и вовсе слилось с несколькими другими проектами в Spring Core. Все это привело к неминуемому усложнению Spring по сравнению с тем, каким он был изначально. Со временем следить за всем клубком зависимостей спринга стало уж совсем сложно, и возникла потребность в отдельной библиотеке, которая стала бы загружать и запускать все сама (сейчас где-то икнул так горячо любимый Spring Boot).

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

В итоге по функционалу Spring и Java EE примерно разделяют паритет. Где-то что-то лучше, где-то что-то хуже, но если смотреть глобально, больших различий нет. То же самое касается сложности работы. И Spring, и Java EE являются превосходными инструментами. Пожалуй, лучшими из того, что сейчас есть, для построения корпоративных сетевых приложений на языке Java.

Однако, Java EE может работать в общем случае только в рамках Enterprise Application Server’a (Tomcat таковым не является), а приложение на Spring стеке может работать на чем угодно (на том же Tomcat), и даже вообще без сервера (так как запустит его внутри себя самостоятельно). Это делает Spring идеальным инструментом для разработки небольших приложений с GUI на Front-end или для микросервисной архитектуры.

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

Так сложилось исторически: в те времена, когда Java EE была излишне усложнена, Spring «набрал клиентскую базу». И тем не менее, однозначного ответа на вопрос что учить Spring или Java EE, нет. Новичку можно дать следующий совет. Познакомиться (хотя бы поверхностно) с обеими платформами. Написать небольшой домашний проект и на Java EE и на Spring.

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

Итоги

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

Источник: javarush.com