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) можно перехватывать для проверки прав клиента на перевод денег.

Industry best practices

The last methodology principle we were consider is the using industry best practices.
Understanding and applying best practices can improve the flexibility and extensibility of a software solution.
Design principles are guide line [...] about half software interact and combine to providing flexibility, extensibility and deep coupling across the system.
This principles provide rules from which software pattern arise.
An example is the separation of concern principles. This principle stays that different types of behavior should be separated into different components.
The result of this principle is the coming separation between UI, service and entity components.
This principle also leads that [...] of your controller pattern and DAO pattern.
Software pattern can be defined as "a repeatable solution to the required problem within a context".
Patterns describe expert solutions to everyday problems. Patterns appear in all levels of system development.
Architectural patterns affect hight-level structure of the system and usually support non-functionally requirements.
An example of architectural pattern is load-ballancing. This pattern increase the system [equality??]
and system throughput by adding additional servers to handle [...].
Design patterns affect medium level of structure and usual support functional requirement.
An example of design pattern is a strategy pattern. This pattern allows the runtime selection one variant from a set of possible other variants.
An example of this can be sorting. There are many sorting algorithms such as the bubble sort, merge sort and so on.
Each sorting algorithm has its own kinds. The strategy pattern would propose the user to dynamically select an appropriate sort technique at runtime.

According Martin Fowler refactoring is "the process of changing the software system in such way than it doesn't effort the external behavior of the code, but improve internal structure". Refactoring is done all the time doing software development and especially doing maintenance.
Refactoring is recognized as regiment and significant practice.
Programmer should be [..] to develop [..] refactoring. Find several books in title refactoring providing detail exploration of this topic.
Sun microsystem's published documents that print together best practices in wide [...] of technical areas including J2EE development,
cluster configuration and so on. http://www.sun.com/blueprints

Modeling principles

In the past three slides we talked a lot about the model that created during software development workflows.
Lets step back a minute and ask an important question. Why do we want to create any these models?
If the ultimate goal is to create software, why should I waste time creating models?
..... then he wrote: we build models we can better understand the system we are developing.

Then building a house you could just buy some lumber and start nailing board together and hope that all that walls fit together.
And then you have room ... a kitchen (м.б. украсить или выбрать кухню).
Such [анхак] approach to build a house is unlike little fail.
Instead you hiring an architect and designer [хелс].
The architect create some model of the [хелс] in his head, but he must share his vision with you, the client.
In the construction [крую], it takes order in a house to construction requeres unique view of the architecture.
You, as an owner need to see artistic renderings of the exterior and landscaping,
the builder need to see three-dimensional views of rooms, doors, stairs and so on.
The electrician needs a wiring view, the plummer needs the view of pipes and so on.

Software development also uses models to represent aspects of the system.
All software developers have a mental model of the system they are building.
You can draw your own diagrams to visualize those mentals models. You can also draw a diagram to capture a design of some existing system.

Communication is very important for success of any software project.
Models help communicate the design and decisions being made about the project.
These decisions must be share with stakeholders, so everyone is on the same page about stages and direction of the project.
In large teams each workflow may be performer by different workers. As the project transitions from one workflow to the next,
it is important that workers document and communicate decisions to the next workflow group.
Models help document those decisions.

Specific UML diagrams show different views of these models.
For example you can use a class diagram to show types ant entities of the system.
And you can use the sequence diagrams to show time order flow of messages between objects to accomplish some functional requirements.

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.
  

Java memory model in 500 words

Оригинальная статья

Что есть Java Memory Model? JMM объяснаяет почему дважды проверенный лдокинг не работает и как это исправить.

JMM отвечает на простой, казалось бы, вопрос: в какой момент можно будет прочесть значение 3 переменной myVariable после присвоения этого значения.

Правила такие:

• Правило упорядочивания программы. В пределах программы действия происходят в запрограммированном порядке.
• Monitor lock rule. Unlock on monitor происходит до следующего лока.
  
• Volatile variable rule. A write to a volatile happens-before every subsequent read of that volatile.
• Thread start rule. Thread.start happens-before actions in the Thread
• Thread termination rule. Actions in a thread happens-before other threads detect the thread's termination.
• Interruption rule. A thread calling interrupt on another thread happens before the interrupted thread detects the interrupt.
• Finalizer rule. End of object construction happens-before start of object finalization.
• Transitivity. If A happens-before B, and B happens-before C, then A happens-before C.

There you have it, the Java Memory Model in 500 words. This summary has been taken from Brian Goetz's Java Concurrency in Practice, which I can't recommend enough.

1. Используйте статические фабричные методы вместо конструкторо

Вместо конструктора можно использовать статические фабричные методы, как в классах-wrapper'ах, например Integer.valueOf(...)

Отметим, что static factory метод не тоже самое, что шаблон Factory, описываемый метод не имеет прямых аналогов в шаблонах проектирования.

Существует несколько преимуществ такого подхода по сравнению с использованием конструкторов.

Первое преимущество. Можно выбрать "говорящее" имя для static factory метода, что нельзя сделать для конструктора. Выбор имени может улучшить жизнь клиента, его код стоновится более читаемым. К тому же, возможет лишь один конструктор с фиксированным набором параметров, а методов может быть несколько.

Второе преимущество. Принципиальное преимущество заключается в том, что метод не обязан создавать новый экземпляр объекта, он может возвращать ссылку на уже созданный экземпляр, взяв его, например, из кэша. Это позволяет не дублировать экземпляры без необходимости. Такое поведение свойственно методу Boolean.valueOf(boolean). Классы, которые контролируют свои экземпляры подобным образом называют instance-controlled. Есть несколько причин написания instance-controlled классов. Это гарантирует что не существует двух эквивалентных объектов, что позволяет повысить производительность, клиенты могут использовать оператор == вместо equals. Все Enum-ы являются instance-controlled.

Третье преимущество - метод может возвращать экземпляр одного из субклассов, что дает большУю гибкость по сравнению с использование конструктора. Мы можем возврщать экземпляр без объявления класс публичным, т.е. полностью скрывать реализацию, что является ключевым моментом при проектировании компактного API. Интерфейсы не могут иметь статических методов, поэтому принято следующее соглашение. Если интерфейс называется Type, то статические фабричные методы, возвращающие реализации интерфейса, помещаются в класс с именем Types. Подобным образом организован Java Collections Framework. Т.е. все static factory методы сконцентрированы в одном классе и, кроме того, мы скрываем реилизации интерфейса.

Четвертое преимущество. Static factory методы уменьшают количество кода при использованиии generics.

Главный недостаток состоит в том, что нельзя создать субкласс к классу без public или protected конструктора.

Второй недостаток заключается в том, что их, в общем случае, невозможно отличить от других static методов. Обычно прибегают к специальному именованию таких методов:
• valueOf—возвращает объект, содержащий переданный аргумент.
• of—альтернатива valueOf, популярная в Enum-ах.
• getInstance—возвращает экземпляр, который описывается параметрами, но недльзя сказать что имеет тоже самое значение. В случае синглтона возвращает единственный экземпляр.
• newInstance—аналогичен getInstance, но гарантирует создание нового экземпляра.
• getType—аналогичен getInstance, но используется когда factory метод находится в другом классе. Type в данном случае заменяется, например getArrayList.
• newType—аналогичен newInstance.

Вообщем, static factory методы и публичные конструкторы имеют свои области применения.

Effective Java 2nd edition

I will read it in English...