Interceptors for Stateless Session Beans

Что за звери такие?

Суть в том, что перед вызовом бизнес-метода будет вызываться метод (или методы) определенных классов.
Все весьма и весьма просто.

1. Мы аннотируем бизнес-метод или бин вот так:

@Interceptors({LogDebugInterceptor.class, NotNullInterceptor.class})

2. В самом перехватчике должен быть метод (методы) а ля

@AroundInvoke
public Object methodName(InvocationContext inv) throws Exception

Они должны быть аннотированы и иметь указанную сигнатуру.

3. Очень интересен интерфейс

public interface InvocationContext {
public Object getTarget();
public Method getMethod();
public Object[] getParameters();
public void setParameters(Object[] params);
public java.util.Map getContextData();
public Object proceed() throws Exception;
}

с помощью него можно получить объект и метод, которые послужил причиной вызова перехватчика. А так же все параметры, переданные в бизнес-метод. Более того, параметры можно подменить с помощью метода setParameters.

4. Для успешного завершения необходимо венуть объект, возвращаемый функцией proceed()

return inv.proceed();

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

Суть схожа с механизмом фильтров в сервлетах. Для чего можно использовать перехватчики? для обработки входных параметров, их проверки, проверки каких-либо ограничений. Например бизнес-метод depositMoney(Customer customer) можно перехватывать для проверки прав клиента на перевод денег.

EJB programming restrictions

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

• Нельзя исползовать перезаписываемые static поля. Все static поля рекомендуется объявлять final. Поскольку контейнер может запускать бин на одной, а может на нескольких JVM.
• Нельзя синхронизировать по тем же соображениям.
• Нельзя использовать AWT-фукнциональность для ввода/вывода какой-либо информации, поскольку многие серверы приложений могут не поддерживать подобные приемы.
• Нельзя исползовать пакет java.io, рытаться получить доступ к файловой системе. Файловая система не совсем подходит для хранения данных бизнес-компонентов. Для доступа к ресурсам лучше использовать другие API, например JDBC.
• Нельзя слушать сокеты, акцептировать секетные соединения. Архитетура EJB позволяет быть сетевым клиентом, не нельзя быть сетевым сервером, поскольку такое поведение будет конфликтовать с основным предназначением enterprise бина - обслуживать EJB клиентов.
• Нельзя получать и использовать информацию о классах через reflection API из соображений безопасности.
• Нельзя создавать загрузчики классов (class loader), использовать текущий загрузчик, устанавливать контекстный загрузчик (set the context class loader), устанавливать менеджер безопасности, создавать новый, останавливать JVM, изменять потоки ввода, вывода и вывода ошибок (input, output, and error streams). Вся эта работа должна выполняться контенером. Попытка нарушить это правило может привести к проблемам с безопасностью, а так же может нарушить работу контейнера.
  
• Нельзя устанавливать фабрику сокетов, используемую ServerSocket, Socket или URL. По тем же соображениям.
• Из тех же соображений запрещены любые операции с потоками и группами потоков.
• Нельзя напрямую читать/писать дескриптор файлов.
• Нельзя пытаться получать security policy information, это может вызвать дыру в системе безопасности.
• Нельзя трогать security configuration objects (Policy, Security, Provider, Signer, and Identity).
• Нельзя использовать this в качестве аргумента или результата, вместо этого надо использовать функции SessionContext.getBusinessObject, Ses-
  sionContext.getEJBObject, SessionContext.getEJBLocalObject, Enti-
  tyContext.getEJBObject, or EntityContext.getEJBLocalObject instead.