Слайд 2
Технологию EJB (Enterprise Java Beans)
можно рассматривать с двух
точек зрения: как фреймворк, и как компонент.
С точки зрения
компонента EJB - это всего-лишь надстройка над POJO-классом, описываемая с помощью аннотации(
POJO это просто класс Java, который:
1. Содержит только поля, без логики их обработки;
2. Доступ ко все полям только через get/set ).
Существует три типа компонентов EJB:
session beans - используется для описания бизнесс-логики приложения
message-driven beans - так же используется для бизнесс-логики
entities - используется для хранения данных
С точки зрения фреймворка EJB - это технология, предоставляющая множество готовых решений (управление транзакциями, безопасность, хранение информации и т.п.) для вашего приложения.
Слайд 3
Основные архитектуры EJB
Существует 2 основные архитектуры при
разработке enterprise-приложений:
традиционная слоистая архитектура (traditional layered architecture)
domain-driven design
(DDD)
Слайд 4
традиционная слоистая архитектура (traditional layered architecture) EJB
4
базовых слоя: слой презентации, слой бизнесс-логики, слой хранения данных
и непосредственно слой самой базы данных.
Обычно слой презентации реализуется через web-приложение (т.е. используя JSP, JSF, GWT и т.п.) или web-сервис.
Слой бизнесс-логики является основой для enterprise-приложения. В нем описываются бизнесс-процессы, производится поиск, авторизация и множество других вещей. Слой бизнесс-логики использует механизмы слоя хранения данных.
Чем отличается слой хранения данных и слой базы данных? Тем, что в первом описываются высокоуровневые объектно-ориентированные механизмы для работы с сущностями БД, в то время как второй - это и есть непосредственно база данных (Oracle, MySQL и т.п.)
Слайд 5
domain-driven design (DDD)
Архитектура DDD предпологает, что объекты
обладают бизнесс-логикой, а не являются простой репликацией объектов БД.
Многие программисты не любят наделять объекты логикой и создают отдельный слой, называемый service layer или application layer. Он похож на слой бизнесс-логики традиционной слоистой архитектуры за тем лишь отличием, что он намного тоньще.
Слайд 8
Сервер приложений j2ee состоит из двух основных элементов:
контейнер web-приложения (JSP, JSF и т.д.) и EJB-контейнер. Первый
служит для создания пользовательского интерфейса и слабо подходит для описания бизнес-логики приложения. Для этого используется вторая часть J2EE - EJB.
Слайд 11
Session bean
Session bean представляет собой EJB-компоненту, связанную
с одним клиентом. ``Бины'' этого типа, как правило, имеют
ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. В качестве примера session bean можно взять ``бин'', который живет в веб-сервере и динамически создает HTML-страницы клиенту, при этом следя за тем, какая именно страница загружена у клиента. Когда же пользователь покидает вэб-узел, или по истечении некоторого времени, session bean уничтожается. Несмотря на то, что в процессе своей работы, session bean мог сохранять некоторую информацию в базе данных, его предназачение заключается все-таки не в отображении состояния или в работе с ``вечными объектами'', а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.
Слайд 12
Session bean
В качестве session bean может выступать обычный
класс Java удовлетворяющий следующим условиям:
иметь как минимум один метод
не должен быть абстрактным
иметь конструктор по-умолчанию
методы не должны начинаться с "ejb" (например ejbCreate, ejbDoSomething)
Для stateful-бинов существует еще одно условие: свойства класса должны быть объявлены примитивами или реализовывать интерфейс Serializable.
Слайд 13
Особенности stateless и stateful бинов
Один bean может содержать
множество клиентских методов. Этот момент является важным для производительности,
так как контейнер помещает экземпляры stateless-бинов в общее хранилище и множество клиентов могут использовать один экземпляр бина.
В отличии от stateless stateful бины инстанцируются для каждого пользователя отдельно.
Слайд 14
Entity bean
Entity bean, наоборот, представляет собой компоненту,
работающую с постоянной (persistent) информацией, хранящейся, например, в базе
данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, ``выживая'', тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить ``бин'' из базы данных).
Слайд 16
EJB-компонента (The Enterprise JavaBeans component)
Отдельная EJB-компонента представляет цобой
компоненту в том же смысле что и традиоционный JavaBeans
``bean'' (``зерно''). Компоненты EJB выполняются внутри EJB-контейнера, который, в свою очередь, выполняется внутри EJB-сервера. Любой сервер, который в состоянии поддерживать EJB-контейнеры и предоставлять им необходимые сервисы, может быть EJB-сервером (то есть многие из существующих серверов могут быть просто расширены до поддержки Enterprise JavaBeans).
EJB-компонента представляет из себя Java-класс, который реализует некоторую бизнес-логику. Все остальные классы в EJB-системе либо реализуют поддержку клиент/сервер взаимодйествий между компонентами, либо реализуют некоторые сервисы для компонент.
Слайд 17
EJB-контейнер (The Enterprise JavaBeans container)
EJB-контейнер -- это
то место, где ``живет'' EJB-компонент. EJB-контейнер реализует для находящихся
в нем компонент такие сервисы как транзакции (transaction), управление ресурсами, управление версиями компонент, их мобильностью, настраиваемостью, мобильностью, жизненным циклом. Так как EJB-контейнер реализует все эти функции, то разработчик EJB-компонент может не реализовывать их самостоятельно, а просто вызывать соответсвующие методы у контейнера (правила вызова методов у контейнера описываются в спецификации). Как правило, в одном EJB-контейнере живет несколько однотипных EJB-компонент.
Слайд 18
EJB-объект (EJB-object) и удаленный интерфейс (remote interface)
Клиентские
приложения вызывают методы на удаленных EJB-компонентах через EJB-объект (EJB-object).
EJB-объект реализует ``удаленный интерфейс'' EJB-компоненты на сервере. Суть в том, что находящаяся на сервере EJB-компонента, помимо бизнес-функций, ради которых она была разработана, должна реализовывать также некоторые функции, определяемые спецификацией, которые служат для ``управления'' EJB-компонентой со стороны контейнера. EJB-объект реализует лишь бизнес-интерфейс для EJB-компоненты, являясь, в некотором смысле, ``промежуточным'' звеном между клиентом и EJB-компонентой.
Слайд 19
EJB-компонента выполняется на сервере, внутри EJB-контейнера и реализует
бизнес-логику, в то время как EJB-объект выполняется у клиента
и удаленно вызывает методы у EJB-компоненты.
Слайд 21
Итак, приложение-клиент соединяется с EJB-сервером и посылает ему
запрос на создание ``бина'' (Enterprise JavaBean) для обработки своих
запросов. Сервер отвечает на такой запрос созданием объекта на стороне сервера (экземпляр EJB-компоненты) и возвращает клиенту прокси-объект (EJB-объект), чей итерфейс совпадает с интерфейсом созданной EJB-компоненты и чьи методы перенаправляют вызовы собственно экземпляру компоненты. После этого приложение-клиент работает с EJB-объектом как с локальным объектом, даже и не подозревая, что всю работу выполняет не EJB-объект, а удаленная компонента на сервере. Необходимо заметить, что созданием и удалением EJB-компонент на сервере занимается EJB-контейнер.
Слайд 23
POJO, POJI,
annotations
Теперь рассмотрим реализацию этих сущностей. В
EJB3 мы используем POJO (Plain Old Java Objects), POJI
(Plain Old Java Interfaces) и аннотации.
Аннотация записывается так:
@<имя аннотации>(<список парамет-значение>)
Слайд 24
Какие аннотации могут быть?
Stateless - говорит контейнеру, что
класс будет stateless session bean. Для него контейнер обеспечит
безопасность потоков и менеджмент транзакций. Дополнительно, вы можете добавить другие свойства, например прозрачное управление безопасностью и перехватчики событий;
Local - относится к интерфейсу и говорит, что bean реализующий интерфейс доступен локально
Remote - относится к интерфейсу и говорит, что bean доступен через RMI (Remote Method Invocation)
EJB - применятеся в коде, где мы используем bean.
Stateful - говорит контейнеру, что класс будет stateful session bean.
Remove - опциональная аннотация, которая используется с stateful бинами. Метод, помеченный как Remove говорит контейнеру, что после его исполнения нет больше смысла хранить bean, т.е. его состояние сбрасывается. Это бывает критично для производительности.
Entity - говорит контейнеру, что класс будет сущностью БД
Table(name="...") - указывает таблицу для маппинга
Id, Column - параметры маппинга
WebService - говорит, что интерфейс или класс будет представлять вэб-сервис.
и много-много других...
Слайд 26
POJO, POJI,
annotations
У stateless и MDB бинов существует
2 события жизненного цикла, которые мы можем перехватить: создание
и удаление бина. Метод, который будет вызываться сразу после создании бина помечается аннотацией javax.annotation.PostConstruct, а перед его удалением - javax.annotation.PreDestroy. Stateful бины обладают помимо рассмотреных выше еще 2 событиями: при активации (javax.ejb.PostActivate) и при деактивации (javax.ejb.PrePassivate).
Слайд 27
import javax.ejb.Local;
@Local
public interface BookTestBeanLocal {
public void
test();
}
------------------------------------------------------
import javax.ejb.Remote;
@Remote
public interface BookTestBeanRemote {
public void test();
}
Слайд 32
Перехватчики(interceptors)
При создании enterprise-приложений часто возникает необходимость записывать лог
вызываемых методов (в целях отладки или для лога безопасности),
а так же контролировать доступ пользователей к отдельным частям приложения. Для этого используются перехватчики - объекты, методы которых вызываются автоматически при вызове метода EJB-бина.
Слайд 33
Перехватчики(interceptors)
Объект-перехватчик является POJO, за тем лишь исключением, что
метод, который должен вызываться автоматически аннотируется @AroundInvoke
Слайд 34
package com.sample;
import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
public class MyInterceptor {
@AroundInvoke
public Object
log(InvocationContext ctx) throws Exception
{
System.out.println("*** TracingInterceptor intercepting " +
ctx.getMethod().getName());
long start = System.currentTimeMillis();
String param = (String)ctx.getParameters()[0];
if (param == null)
ctx.setParameters(new String[]{"default"});
try
{
return ctx.proceed();
}
catch(Exception e)
{
throw e;
}
finally
{
long time = System.currentTimeMillis() - start;
String method = ctx.getClass().getName();
System.out.println("*** TracingInterceptor invocation of " + method + " took " + time + "ms");
}
}
}
Слайд 35
@Stateless(name="SampleEJB")
@RemoteBinding(jndiBinding="SampleEJB")
@Interceptors(value=com.sample.MyInterceptor.class)
public class SampleBean implements Sample {
public void doSomething(String
param) {
callWebService(param);
}
@AroundInvoke
public Object log(InvocationContext ctx) throws Exception
{
try
{
return ctx.proceed();
}
catch(Exception e)
{
throw e;
}
}
}
