Laba4_WEB

Будет больно, но ради этого и живем

Уровень back-end должен быть основан на JavaEE (необходимо использовать EJB)
Уровень front-end должен быть построен на React + Redux (необходимо использовать ES6 и JSX) с использованием набора компонентов React Toolbox
Взаимодействие между уровнями back-end и front-end должно быть организовано посредством REST API

Приложение включает в себя две страницы: стартовую и основную. Обе страницы должны быть адаптированы для отображения в 3 режимах:

"Десктопный" - для устройств, ширина экрана которых равна или превышает 1169 пикселей
"Планшетный" - для устройств, ширина экрана которых равна или превышает 708, но меньше 1169 пикселей
"Мобильный" - для устройств, ширина экрана которых меньше 708 пикселей

Стартовая страница должна содержать следующие элементы:

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

Основная страница приложения должна содержать следующие элементы:

Дополнительные требования к приложению:

Все результаты проверки должны сохраняться в базе данных под управлением СУБД PostgreSQL
Для доступа к БД необходимо использовать JPA

Вопросы к защите лабораторной работы

1. Платформа Java EE. Спецификации и их реализации.

Java EE — это платформа, построенная на основе Java SE, которая предоставляет API и среду времени выполнения для разработки и запуска крупномасштабных, многоуровневых, масштабируемых, надежных и безопасных сетевых приложений.

Подобные приложения называют корпоративными (Enterprise applications), так как они решают проблемы, с которыми сталкиваются большие бизнесы.

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

Деление на платформы (Java SE, Java EE, Java Card ...) появилось в Java EE 6 и позволяет сделать более «лёгкими» приложения, которым не нужен полный стек технологий Java EE. Существует только 2 профиля — Full и Web. Сервер приложений может реализовывать спецификации не всей платформы, а конкретного профиля.

###Отличие Spring от JavaEE

Конкурентном 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 хорошо подходит для реализации масштабируемого монолитного кластерного приложения.

Пример Web profile: Tomcat

Пример Full profile: Glassfish

Основные концепции

Приложения строятся из компонентов, работающих под управлением контейнеров.
Используются следующие принципы:
- Inversion of Control (IoC) + Contexts & Dependency Injection (CDI).
- Location Transparency.

https://javarush.ru/groups/posts/2637-vvedenie-v-java-ee - классное объяснение

https://ru.photo-555.com/2403908-java-ee-interview-questions - вопросы с собеса

2. Принципы IoC, CDI и Location Transpanency. Компоненты и контейнеры.

Есть такая штука - JNDI - набор API, позволяющий доставать объекты из контейнера по их именам. По сути, это замена обращению по ссылкам, и благодаря этому легко реализуется Dependency Lookup и Dependency Injection. Хранение объектов в таком случае можно представить как Map, где ключи - это имена, а значения - нужные объекты (например, ссылки на них).

Два варианта использования JNDI:

CDI (аннотации) — работает только в managed компонентах.
Прямой вызов API — работает везде.

// Пример получения ссылки на JDBC datasource. DataSource dataSource = null;
public class JNDI { 

public void jndi() {
  try {
   // Инициализируем контекст по умолчанию. 
   Context context = new InitialContext(); 
   dataSource = (DataSource) context.lookup("Database"); 
  } catch (NamingException e) {
    // Ссылка не найдена
  }
}


}

IoC - Inversion of Control (применительно к Java EE):

Жизненным циклом компонента управляет контейнер (а не программист).
Объекты создает не программист (используя new), а контейнер IoC. Применяется далеко не ко всем объектам в приложении, а только к управляемым (в Spring это классы с аннотациями @Component, @Service и т.д., в EJB — бобы @Stateless, @Stateful, @MessageDriven).
За взаимодействие между компонентами отвечает тоже контейнер.

CDI — Contexts and Dependency Injection (позволяет снизить (или совсем убрать) зависимость компонента от контейнера):

как бы компонент и так зависит от контейнера, так как тот его порождает, но тут о другом: программист, когда пишет компонент, он не зависит от API, предоставляемых контейнером

Не требуется реализации каких-либо интерфейсов.
Не нужны прямые вызовы API.
Реализуется через аннотации.

Пример CDI (JSF Managed Bean):

@ManagedBean(name="message")
@SessionScoped
public class MessageBean implements Serializable {
   //business logic and whatever methods
}


@ManagedBean
@SessionScoped
public class HelloBean implements Serializable {

   @ManagedProperty(value="#{message}") //ЭТО И ЕСТЬ CDI
   private MessageBean messageBean;

   //must povide the setter method
   public void setMessageBean(MessageBean messageBean) {
this.messageBean = messageBean; }
}

Еще одна интерпретация CDI

Вместо построения зависимостей в компоненте, где они нужны:

public class Something {
  private Dependency dependency = new Dependency();
}

Мы принимаем их извне, что избавляет компонент от необходимости управлять ими:

public class Something {
  private Dependency dependency;

  public Something (Dependency dependency) {
    this.dependency = dependency;
  }
}

Чтобы нам не пришлось вручную собирать все зависимости для создания компонентов, контейнер IoC предоставляет возможность внедрения инстанций в поля, помеченные специальной аннотацией:

public class SomethingDI {
  @Autowired private Dependency dependency; // Spring
  @EJB private EjbDependency ejbDependency; // EJB
}

Location Transparency - прозрачность местонахождения - это что-то вроде паттерна

Инфраструктура завязана на RMI (Java API, позволяющий вызывать методы удаленных объектов)

Благодаря CDI не важно, где физически расположен вызываемый компонент — за его вызов отвечает контейнер.

Клиент имеет прокси, обращается с ней как с нужным объектом. Прокси перенаправляет его вызовы куда следует: если нужный компонент находится локально, идёт к нему обращение по ссылке; если удалённо (в другой JVM) - необходима сериализация передаваемых данных.

Компоненты и контейнеры

Приложение состоит из компонентов и контейнера, управляющего жизненным циклом компонентов. Пример: Servlet - компонент, Glassfish - контейнер.

Голая 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, показал, что они применяются менее чем на 2% из 500 самых популярных Web-сайтов. Почему? Некоторые разработчики неверно оценили накладные расходы при интерпретации байт-кода в виртуальной машине Java. У других множество нареканий вызывает защита, основанная на принципе (sandbox), который не позволяет Java использовать в полной мере локальные и удаленные службы. Третьи отмечают различия между виртуальными машинами основных браузеров, имеющихся на рынке. Так или иначе по прошествии пяти лет апплеты не оправдали ожиданий, и Web-приложения на базе HTML не были вытеснены Web-приложениями с равным уровнем переносимости и мобильности, но функционально более мощным графическим пользовательским интерфейсом. "богатому графическому пользовательскому интерфейсу" не было визуальной среды разработки. А программировать графику вручную - задача рутинная для программиста и ненужная для дизайнера. %)

3. Управление жизненным циклом компонентов. Дескрипторы развёртывания.

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

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

Примеры дескрипторов развёртывания:

web.xml - дескриптор развёртывания веб-приложений (упаковываемых обычно в .war архивы)
ejb-jar.xml - дескриптор развёртывания EJB-приложения
application.xml - дескриптор развёртывания приложения, использующего несколько web.xml / ejb-jar.xml

4. Java EE API. Виды компонентов. Профили платформы Java EE.

Деление на платформы (Java SE, Java EE, Java Card ...) появилось в Java EE 6 и позволяет сделать более «лёгкими» приложения, которым не нужен полный стек технологий Java EE. Существует только 2 профиля — Full и Web. Сервер приложений может реализовывать спецификации не всей платформы, а конкретного профиля.

Пример Web profile: Tomcat Пример Full profile: Glassfish

Виды компонентов:

веб-компоненты (сервлеты, jsp, ...) - формируют содержимое представления
Java-бины (POJO, ManagedBean, EJB) - позволяют изменять данные и осуществлять их временное хранение, взаимодействовать с базами данных и веб-службами, а также отображать содержимое в ответ на запросы клиентов.

5. Компоненты EJB. Stateless & Stateful Session Beans. EJB Lite и EJB Full.

EJB — технология разработки серверных компонентов, реализующих бизнес-логику.

Особенности EJB:

Возможность локального и удалённого доступа.
Возможность доступа через JNDI или Dependency Injection.
Поддержка распределённых транзакций (с помощью JTA).
Поддержка событий.
Жизненным циклом управляет EJB-контейнер (в составе сервера приложений).

Компонентная модель EJB:

EJB-компоненты инкапсулируются контейнером.
Контейнер предоставляет клиентам проксиобъекты (proxy objects) для доступа к EJB компонентам.
Прокси-объекты реализуют бизнес-интерфейсы (Business Interfaces).
Клиенты вызывают методы бизнесинтерфейсов.

Sessions Beans:

Предназначены для синхронной обработки вызовов.
Вызываются посредством обращения через API.
Могут вызываться локально или удалённо.
Могут быть endpoint'ами для веб-сервисов.
CDI — аннотация @EJB.
Не обладают свойством персистентности. (Персистентность в программировании означает способность состояния существовать дольше, чем процесс, создавший его)
Можно формировать пулы бинов (за исключением @Singleton).

Stateless Session Beans:

Не сохраняют состояние между последовательными обращениями клиента.
Нет привязки к конкретному клиенту.
Хорошо масштабируются.
Объявление — аннотация @Stateless.

package converter.ejb;
import java.math.BigDecimal;
import javax.ejb.*;
@Stateless
public class ConverterBean {
 private BigDecimal yenRate = new BigDecimal("83.0602");
 private BigDecimal euroRate = new BigDecimal("0.0093016");
 public BigDecimal dollarToYen(BigDecimal dollars) {
 BigDecimal result = dollars.multiply(yenRate);
 return result.setScale(2, BigDecimal.ROUND_UP);
 }
 public BigDecimal yenToEuro(BigDecimal yen) {
 BigDecimal result = yen.multiply(euroRate);
 return result.setScale(2, BigDecimal.ROUND_UP);
 }
}

Stateful Session Beans:

«Привязываются» к конкретному клиенту.
Можно сохранять контекст в полях класса.
Масштабируются хуже, чем @Stateless.
Объявление — аннотация @Stateful.

@Stateful
@StatefulTimeout(unit = TimeUnit.MINUTES, value = 20)
public class CartBean implements Cart {
@PersistenceContext(unitName = "pu", type = PersistenceContextType.EXTENDED)
private EntityManager entityManager;
private List products;

@PostConstruct
private void initializeBean(){
products = new ArrayList<>();
}

@Override
public void addProductToCart(Product product) {
products.add(product);
}

@Override
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void checkOut() {
for(Product product : products){
entityManager.persist(product);
}
products.clear();
}
}

Singleton Session Beans:

Контейнер гарантирует существование строго одного экземпляра такого бина.
Объявление — аннотация @Singleton.

Один корпоративный компонент должен быть доступен нескольким потокам одновременно.
Приложение нуждается в корпоративном Бобе для выполнения задач на запуск и завершение работы приложения.

Требования к классам Session Beans:

Должен быть public классом верхнего уровня.
Не должен быть final и/или abstract.
Должен иметь public конструктор без параметров.
Не должен переопределять метод finalize().
Должен реализовывать все методы бизнесинтерфейса(-ов).

В плюс к этому ещё есть пулы экземпляров бинов.

Так как клиенты обращаются к проксям, реализующим бизнес-интерфейс, а с реальными объектами бинов дел не имеют, с их жизненным циклом можно вытворять разные штуки. Вот что происходит для каждого из трёх видов сессионных бинов:

Stateful - у каждого клиента своя прокси, ведущая на свой и только свой экземпляр бина, потому что клиенту важно состояние его бина
Stateless - у каждого клиента один и тот же интерфейс, который каким-то образом уводит пользователя к одному из экземпляров бина из пула
Singleton - единый интерфейс и единый экземпляр заставят вас поразвлекаться с concurrency

Message driven beans выполняют метод в ответ на получение сообщения из определенной очереди JMS.

Аннотация @EJB служит для CDI и предоставляет клиентам не сам объект, а прокси, через который можно получить доступ к методам бизнес-интерфейсов. Может осуществляться доступ как к локальным, так и удаленным (в другой JVM) объектам.

Stateless or Singleton:

Я бы выбрал Stateless - сервер может генерировать множество экземпляров bean-компонента и обрабатывать входящие запросы параллельно.

Синглтон звучит как потенциальное узкое место - значение @Lock по умолчанию - @Lock (WRITE), но может быть изменено на @Lock (READ) для компонента или отдельных методов.

@Stateless позволит вам иметь несколько копий, готовых для обработки в JVM (столько, сколько позволяет память и размер пула), где, как @Singleton, в JVM есть только одна копия, даже если одна может поддерживать несколько параллельных потоков, работающих против нее.

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

С @Stateless бином доступ более недолговечный. Кроме того, в случае сбоя он просто возродится и попытается установить новое соединение с ресурсом. Если что-то подобное происходит с синглтоном, то синглтон должен обработать его, не требуя перезапуска приложения, потому что @PostConstruct вызывается только один раз для каждой JVM.

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

6. Работа с электронной почтой в Java EE. JavaMail API.

JavaMail API - фреймворк для работы с электронной почтой в Java с поддержкой протоколов SMTP, MIME, POP и некоторые другие. Предоставляется следующее API из пакета javax.mail: Session - класс, открывающий дверь в мир JavaMail Message - абстрактный класс (используются его наследники, например MimeMessage) Address - абстрактный класс Authenticator - абстрактный класс для защиты сообщений на сервере Transport Store Folder Пример кода:

	// Recipient's email ID needs to be mentioned.
      String to = "destinationemail@gmail.com";

      // Sender's email ID needs to be mentioned
      String from = "fromemail@gmail.com";
      final String username = "manishaspatil";//change accordingly
      final String password = "******";//change accordingly

      // Assuming you are sending email through relay.jangosmtp.net
      String host = "relay.jangosmtp.net";

      Properties props = new Properties();
      props.put("mail.smtp.auth", "true");
      props.put("mail.smtp.starttls.enable", "true");
      props.put("mail.smtp.host", host);
      props.put("mail.smtp.port", "25");

      // Get the Session object.
      Session session = Session.getInstance(props,
         new javax.mail.Authenticator() {
            protected PasswordAuthentication getPasswordAuthentication() {
               return new PasswordAuthentication(username, password);
	   }
         });

      try {
	   // Create a default MimeMessage object.
	   Message message = new MimeMessage(session);
	
	   // Set From: header field of the header.
	   message.setFrom(new InternetAddress(from));
	
	   // Set To: header field of the header.
	   message.setRecipients(Message.RecipientType.TO,
               InternetAddress.parse(to));
	
	   // Set Subject: header field
	   message.setSubject("Testing Subject");
	
	   // Now set the actual message
	   message.setText("Hello, this is sample for to check send " +
		"email using JavaMailAPI ");

	   // Send message
	   Transport.send(message);

	   System.out.println("Sent message successfully....");

      } catch (MessagingException e) {
         throw new RuntimeException(e);
      }

7. JMS. Реализация очередей сообщений. Способы доставки сообщений до клиента. Message-Driven Beans.

JMS

JMS, Java Message Service - это Java API (то есть набор интерфейсов и классов) для работы с Message-Oriented Middleware, изначально разработанная компанией Sun, чтобы предоставить разработчикам создавать гибкие и слабосвязанные приложения с использованием асинхронного обмена данными между приложениями (клиентами/серверами) через посредника. Асинхронность - это главная причина создания и использования JMS.

Данный набор определен в пакете javax.jms в дереве пакетов J2EE. JMS поддерживает две модели обмена сообщениями: point-to-point(точка - точка) и publish-subscribe(издатель-подписчик).

MOM

MOM, Message-Oriented Middleware (промежуточное программное обеспечение) - подпрограммное обеспечение промежуточного слоя, ориентированное на обмен сообщениями в распределённом окружении. Прежде всего предназначено для реализации отложенного обмена сообщениями, на основе которого и строится Messaging System.

В отличие от традиционных систем, в Messaging System приложения общаются не напрямую, а посредством MOM. Если один компонент системы хочет послать сообщение другому компоненту, он посылает данное сообщение MOM, а MOM затем пересылает его адресату.

Способы доставки сообщений до клиента

Существует 2 модели:

Модель Точка-Точка (Point-to-Point, P2P) - в этой модели место назначения, используемое для хранения сообщений, называется очередью. Объект Queue. В этой модели один клиент помещает сообщение в очередь, а другой получает сообщение. Как только получение сообщения подтверждено, поставщик сообщений удаляет его из очереди.
Модель Подписчик-Издатель (Publisher-Subscriber) - место назначения называется темой. Объект Topic. При использовании данной модели клиент публикует сообщение в теме и все абоненты этой темы получают сообщение.

https://jsehelper.blogspot.com/2016/12/jms.html

Java Message Service — стандарт для асинхронного распределенного взаимодействия программных компонентов (которые могут находиться на одном компьютере, в одной локальной сети, или быть связаны через Интернет) путем рассылки сообщений.

JMS поддерживает две модели коммуникации: point-to-point и publish-subscribe (pubsub).

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

В pubsub сообщения адресуются определенному topic'у, на которые подписываются клиенты. Каждое сообщение может быть получено несколькими клиентами или не получено вообще, если подписчиков на момент доставки не было.

Существует несколько реализаций JMS провайдеров (RabbitMQ, Open Message Queue, ...) - эти решения шире

Message-Driven Beans

MDB — это компоненты, логика которых является реакцией на события, происходящие в системе. Особенности MDB:

Реализуют интерфейс слушателя соответствующего типа сообщений (например, JMS).
Нет возможности вызова методов «напрямую».
Нет локальных и удалённых интерфейсов.
Контейнер может создавать пулы MDB.
При развёртывании MDB нужно регистрировать в качестве получателей сообщений.

Пример MDB

import javax.ejb.*;
import javax.jms.*;
@MessageDriven(mappedName = "jms/MyQueue",
    activationConfig = {
        @ActivationConfigProperty(propertyName =
            "acknowledgeMode", propertyValue =
            "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName =
            "destinationType", propertyValue =
            "javax.jms.Queue")
 })
public class SampleMDB implements MessageListener {
 public void onMessage(Message message) {
 // Do something
 }
}

8. Понятие транзакции. Управление транзакциями в Java EE. JTA.

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

Java Transaction API позволяет выполнять распределенные транзакции, т.е. транзакции, читающие и обновляющие данные на разных сетевых ресурсах (которыми могут быть различные серверы баз данных, JMS).

JTA предоставляет высокоуровневый интерфейс для управления транзакциями (begin, commit, rollback), избавляя от необходимости работы с каждым ресурсом по-своему (интерфейс транзакций в JDBC, например, немного отличается от интерфейса JMS).

Транзакция координируется transaction manager'ом. Взаимодействие с ресурсами осуществляется через resource manager'ы.

Транзакции могут быть объявлены:

декларативно — аннотацией @Transactional на отдельном методе или всем классе, при этом rollback происходит при необработанном RuntimeException
программно — вызывая begin, rollback, commit у UserTransaction

В дополнение (там немного, но важно): http://tomee.apache.org/jpa-concepts.htm

9. Веб-сервисы. Технологии JAX-RS и JAX-WS.

Позволяют организовать взаимодействие между сетевыми ресурсами по стандартизированному протоколу.
Ресурсы могут работать на любой платформе.
Данные «упаковываются» в XML и передаются по HTTP.
Основные стандарты — SOAP, WSDL и WS-I.
На платформе Java EE реализуются JAX-WS API и JAX-RS API.
Основа SOA (Service Oriented Architecture).

JAX-WS:

package example;
import javax.jws.*;
@WebService
public class SayHello {
 @WebMethod
 public String getGreeting(String name){
 return "Hello " + name;
 }
}

Пример JAX-RS (REST веб-сервис)

import javax.enterprise.ApplicationScoped;
import javax.ws.rs.*;

@ApplicationScoped
@Path("/")
public class Rest {
  @GET
  @Path("echo")
  public String echo(@QueryParam("q") String original) {
    return original;
  }
}

Difference between JAX-WS и JAX-RS:

JAX-WS - это Java API для веб-служб на основе XML - стандартный способ разработки веб-служб в нотации SOAP (Simple Object Access Protocol).

Вызов веб-служб осуществляется посредством удаленных вызовов процедур. Для обмена информацией между клиентом и веб-сервисом используется протокол SOAP. Обмен сообщениями между клиентом и сервером осуществляется через сообщения SOAP на основе XML .

Клиентам веб-службы JAX-WS необходим файл WSDL для создания исполняемого кода, который клиенты могут использовать для вызова веб-службы.

JAX-RS - Java API для веб-служб RESTful. Веб-службы RESTful представлены как ресурсы и могут быть идентифицированы с помощью унифицированных идентификаторов ресурсов ( URI ). Вызов удаленной процедуры в данном случае представляет собой HTTP- запрос, а необходимые данные передаются в качестве параметров запроса. Веб-службы RESTful - более гибкие, могут использовать несколько разных MIME- типов. Обычно используется для обмена данными XML или обмена данными JSON (JavaScript Object Notation) ...

10. Платформа Spring. Сходства и отличия с Java EE.

Платформа Spring

Что такое Spring?

Несмотря на то, что Spring не обеспечивал какую-либо конкретную модель программирования, он стал широко распространённым в Java-сообществе главным образом как альтернатива и замена модели Enterprise JavaBeans. Spring предоставляет бо́льшую свободу Java-разработчикам в проектировании; кроме того, он предоставляет хорошо документированные и лёгкие в использовании средства решения проблем, возникающих при создании приложений корпоративного масштаба.

Между тем, особенности ядра Spring применимы в любом Java-приложении, и существует множество расширений и усовершенствований для построения веб-приложений на Java Enterprise платформе. По этим причинам Spring приобрёл большую популярность и признаётся разработчиками как стратегически важный фреймворк.

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

Во-первых, Spring можно применять для построения любого приложения на языке Java (например, автономных, веб-приложений или приложений Java Enterprise Edition (JEE)) в отличие от многих других платформ (таких как Apache Struts, которая ограничена созданием только веб-приложений).

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

Обратите внимание, что речь идет только о ядре Spring - многие дополнительные компоненты Spring, такие как доступ к данным, требуют более тесной привязки к Spring Framework. Однако польза от такой привязки вполне очевидна.

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

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

Преимущества:

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

Относительная легкость в изучении и применении фреймворка в разработке и поддержке приложения.
Внедрение зависимостей (DI) и инверсия управления (IoC) позволяют писать независимые друг от друга компоненты, что дает преимущества в командной разработке, переносимости модулей и т.д..
Spring IoC контейнер управляет жизненным циклом Spring Bean и настраивается наподобие JNDI lookup (поиска).
Проект Spring содержит в себе множество подпроектов, которые затрагивают важные части создания софта, такие как вебсервисы, веб программирование, работа с базами данных, загрузка файлов, обработка ошибок и многое другое. Всё это настраивается в едином формате и упрощает поддержку приложения.

Все про Spring:

Важные заметки для себя:

Аспектно-ориентированное программирование (АОП) — это парадигма программирования являющейся дальнейшим развитием процедурного и объектно-ориентированного программирования (ООП). Идея АОП заключается в выделении так называемой сквозной функциональности. Т.е. есть функциональность которая затрагивает несколько модулей, но она не имеет прямого отношения к бизнес коду, и ее хорошо бы вынести в отдельное место, это и показано на рисунке выше.
Prototype scope creates a new instance every time getBean method is invoked on the ApplicationContext. Where as for request scope, only one instance is created for an HttpRequest

Отличие Spring от JavaEE

Проще говоря, Java EE — для легко масштабируемого монолитного приложения, Spring — для совсем маленьких приложений с GUI на Front-end или для микросервисной архитектуры.

https://dou.ua/lenta/articles/javaee-vs-spring/