Зачем нужны EJB

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

Прежде всего отмечу, что EJB - это часть стандарта Java EE, отвечающая за организацию бизнес-логики и предоставляющая декларативное управление безопасностью, долговременным хранением данных, глобальными транзакциями, распределенными объектами, кластеризацией и подпиской на сообщения. Основная задача данного стандарта: освободить программиста от реализации низкоуровневых вещей.

Основной альтеративой EJB долгие годы является Spring Framework, который, однако, ни одну из вышеперечисленных задач не решает самостоятельно. Есть отвевления в проекте Spring Framework, отвечающие за модульность (Spring DM), безопасность (Spring Security), и т.д. но при этом нет реализации Single Sign-On (SSO), нет менеджера глобальных и распределенных транзакций, Spring Framework умеет только подключаться к существующим, предоставляемым как правило полноценными серверами приложений. Что касается кластеризации, то она в Spring Framework как таковая отсутствует, т.е. можно развернуть две копии приложения на каком-нибудь Tomcat, но за репликацию сессий, если таковые используются, будет отвечать сам контейнер сервлетов, а за вызов обеих копий по протоколу HTTP - какой-нибудь внешний балансировщик нагрузки, сам фреймворк при этом не причем. При использовании же EJB мы, во-первых, не привязаны к протоколу HTTP и внешнему балансировщику нагрузки: EJB-клиент является сам себе балансировщиком, да к тому же работает по более быстрому протоколу; во-вторых же, обеспечивается прозрачное для клиента восстановление после сбоев: если вы отметили метод сессионного компонента как идемпотентный, то в случае сбоя вызов от клиета (сервлета или RMI/IIOP-клиента) автоматически будет перенаправлен на экземпляр компонента, расположенный на другом сервере. Клиент тем самым даже не заметит проблемы.

Т.е. Spring Framework выступает топором в одноименной каше: он очень крут, но для решения задачи нужно сыпануть в варево порцию библиотек, перемешать и молиться, чтобы ничего не сбоило и не конфликтовало друг с другом. JAR-Hell. Так же носить с собой ворох библиотек в WEB-INF/lib - удовольствие ниже среднего.

Основными недостатками EJB считают многословность, трудоемкость для разработчика, большие XML-дескрипторы и т.д. Но это все давно в прошлом. Начиная с EJB 3.0, это уже практически новая технология, лаконичная, активно использующая аннотации как средство описания метаданных. Появившиеся в EJB 3.1 и Java EE 6 нововведения делают альтернативные средства, такие как Spring Framework, Google Guice, Tapestry IoC и т.д. ненужными. Да, когда-то они решали свою задачу: облегчать программисту доступ к низкоуровневым сервисам, минуя EJB, но теперь данная задача не актуальна. У нас в сервере приложений из коробки доступны: IoC-контейнер, менеджер глобальных и распределенных транзакций, декларативные настройки безопасности, огромное количество различных провайдеров безопасности (хранение данных пользователей хоть в LDAP, хоть в БД, хоть в специализированных решениях, авторизация хоть по паролю, хоть по сертификату, контроль сертификатов, цепочки отзыва, Single Sign-On (SSO), сквозная по всем приложениям авторизация и аутентификация, когда сервер приложений определяет, имеет ли право пользователь, вошедший по сертификату, писать в очередь A и читать данные из БД под пользователем B, гибкая система прав доступа, когда ровно в 18:00 администратор превращается в тыкву и т.д.), полноценная кластеризация, работа с очередями сообщений и внешними информационными системами. И EJB - самый простой с точки зрения программиста способ воспользоваться данным богатством, при этом ваш код будет по прежнему состоять из старых-добрых POJO, использовать JPA или JDBC и вызываться из любого веб-фреймворка, который вам нравится.

Вот мое мнение о том, зачем нужны EJB в современном мире разработки корпоративных приложений.

UPD: по мотивам статьи разгорелась интересная дискуссия.

UPD2: Сделал небольшой бенчмарк: EJB показывает на 10 - 15% лучшую производительность нежели Spring Framework.


Понравилось сообщение - подпишитесь на блог

Как подружить IDE Eclipse и WebSphere Liberty Profile

В шестой версии спецификации Java EE было введено понятие профилей. Как определено в спецификации, профиль - это набор технологий и API, предназначенный для создания соответствующего типа приложений. В Java EE 6 определены следующие профили:

• Full Platform - предназначен для разработчиков, которым нужен полный набор технологий Java EE для создания корпоративных приложений.
  
  
• Web Profile - обеспечивает поддержку веб-технологий и является подмножеством full platform. Предназначен для разработчиков, не нуждающихся в полном наборе технологий Java EE.

Хорошая новость заключается в том, что сервер приложений IBM WebSphere Application Server обеспечивает поддержку обоих профилей. Если вам нужна вся мощь платформы Java EE, то вы можете воспользоваться IBM WebSphere Application Server Full Profile, если же вам нужна удобная среда для разработки и эксплуатации веб-приложений с дополнительными возможностями (EJB, MOM, Web-services, NoSQL-СУБД, интеграция с z/OS), то к вашим услугам IBM WebSphere Application Server Liberty Profile, о работе с которым я расскажу в данной статье.

Почему вы должны хотеть мейнфрейм zEnterprise EC12 и z/OS для работы ваших Java-приложений

Что такое мейнфрейм

Обычно когда люди слышат слово "мейнфрейм", им представляется нечто такое древнее, ужасное, занимающее целый машинный зал, а то и не один, связанное с тысячами устройств и управляемое с помощью старого-доброго терминала 3270. На самом деле конечно же все уже давно не так, современные мейнфреймы корпорации IBM представляют собой одно- (Business Class Model, BC12) или двустворчатый (Enterprise Class Model, EC12) шкаф, чуть выше человеческого роста, внешне похожий на этакий высокотехнологичный холодильник, набитый сверху-донизу различным оборудованием.

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

Возникает вполне закономерный вопрос: в принципе благодаря горизонтальной масштабируемости можно работать и на россыпи x86-серверов, так зачем чем же нужны мейнфреймы. Для ответа на него следует заметить, что с помощью информационных технологий мы решаем множество абсолютно непохожих друг на друга задач. Такие корпорации как Google, Facebook, ВКонтакте, часто рассматриваемые как эталон высоких нагрузок, обрабатывают миллионы запросов в секунду, но при этом имеют полное право не выполнить некоторые из них по причине аппаратного или программного сбоя. Ничего страшного не случится, в крайнем случае пользователь просто повторит действие. Аналогичным образом данные компании могут потерять часть данных, это хуже, но данные не являются критичными и легко восстанавливаются. Например, когда вы ставите "лайк" в Facebook, то это вовсе не значит, что он тут же становится видим всем пользователям данной социальной сети.

Абсолютно другое дело - приложения, обрабатывающие пользовательские транзакции. При переводе денег из банка в банк невозможно допустить ситуацию, когда они спишутся с одного счета, но не попадут на другой. Аналогично невозможно допустить потери даже части пользовательских данных о финансовых транзакциях. Требования к согласованности данных и надежности информационных систем для того же Google и, например, Федерального резерва абсолютно несопоставимы друг с другом. Данная статья призвана рассказать о том, каким же образом мейнфреймы IBM обеспечивают высочайшую надежность и производительность, и как воспользоваться данными уникальными механизмами из ваших программ на языке Java.

IBM JRE готова к планируемому переводу стрелок на час назад 26 октября

Двадцать шестого октября Россия вновь переводит время на час назад. Планируется, что данный переход на зимнее время будет окончательным и дальше мы будем жить по нему. Ну будущее покажет. Корпорация IBM готова к такому переходу с 12-го августа - с момента выхода последней версии утилиты IBM Time Zone Update Utility for Java. Данная версия содержит в себе корректировки в том числе и российских временных зон. Если вы используете IBM JRE на Microsoft Windows, Linux, AIX, Solaris, HP-UX и конечно же, самое главное, z/OS, то настоятельно рекомендую применить последнее обновление.

> java в данном случае - JRE конкурентов.

P.S. Юбилейное 200-е сообщение в Блоге Сурового :)

Понравилось сообщение - подпишитесь на блог

"Универсальный сервис", почему заказчики так часто его хотят и почему его делать не нужно

В очередной раз столкнувшись с предложением заказчика "а сделайте мне универсальный транспорт, в котором сообщения будут представлять собой обычные строки, содержащие XML, и который не будет осуществлять никакой валидации/обогащения/мониторинга, но зато я должен иметь возможность включать новые маршруты/преобразования правкой строчек в некоторой конфигурационной базе данных, а да, еще очень хочу чтобы это все было на Oracle Service Bus/IBM WebSphere ESB/IBM WebSphere Message Broker", Суровый решил написать вам о своем отношении к подобным решениям. Статья из серии "не могу молчать".

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

Как я провел лето

Вот и заканчивается жаркое лето 2014-го года. Сейчас, правда, в Москве зачастили дожди, а это значит, что за окном осень, первое сентября и по традиции пора писать сочинение о том, как ты провел лето. Суровому есть что написать, т.к. лето 2014-го воистину прошло под девизом "перемен, мы ждем перемен".

Во-первых, женился. Кое-что об этом уже рассказывал. У семейной жизни, как оказалось, есть свои преимущества :).

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

В-третьих же, поменял место работы. Я больше не работаю в компании AT Consulting. Я очень хочу поблагодарить всех моих коллег из AT за замечательные два с половиной года, которые вы мне подарили. К величайшей скорби, не все коллеги смогут услышать эти слова благодарности...

Но жизнь идет, и теперь я тружусь на должности Client Technical Professional в корпорации IBM, где буду применять все свои знания для помощи нашим клиентам.

На новом месте буду работать вот с такими "маленькими" системами.

На фотографии представлен мейнфрейм IBM zEnterprise EC12 ('z' means 'zero downtime'). Эта "крошка" имеет на борту 101 5.5 ГГц ядро (на самом деле ядер 120, просто часть используется для резервирования и организации канальной системы ввода-вывода), так же есть дополнительные процессоры для работы zLinux, информационных систем и Java. Машина снабжена 3 ТБ оперативной памяти. Все системы, включая даже сервисные ноутбуки, зарезервированы. При необходимости можно организовать кластер таких мейнфреймов, разнесенных географически по разным центрам обработки данных.

А на данной фотографии можно видеть Сурового челябинского программиста на фоне мэйнфрейма IBM zEnterprise BC12. Наверное предназначение данной фотографии - стать первым шагом моего творческого пути в корпорации. Думаю, мне здесь понравится.

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

UPD 01.12.2014: Вернулся из IBM Client Center, Montpellier, France, на фоне виден Green Data Center и zEnterprise EC12.

Понравилось сообщение - подпишитесь на блог

Опыт реального использования практически всех возможностей Java EE 6

Суровый конечно же понимает, что данная статья несколько запоздала, ей бы самое время появиться году так в 2010-м. Однако, я не привык писать о том, с чем не поработал сколь-либо плотно, а разработать приложение, опирающееся практически на весь стек Java EE 6 мне удалось только сейчас. В данной заметке собраны впечатления об использовании данных технологий, полученные за время ведения проекта разработки интеграционного приложения, обеспечивающего асинхронное взаимодействие нескольких информационных систем. Я не имею права подробно описывать архитектуру и принятые дизайнерские решения, поэтому изложение будет несколько лоскутным: задача, как решали, впечатления.

Under the Hood of J2EE Clustering

Давно хотел процитировать замечательную статью еще 2005-го года написания: Under the Hood of J2EE Clustering. Некоторые факты, особенно касающиеся деталей работы тех или иных серверов приложений, а так же кластеризации EJB и JMS, уже порядком устарели, но общие принципы, изложенные в статье, остались неизменными.

Введение

Важно понимать, что кластер должен обеспечивать две вещи:

• Балансировку нагрузки (Load Balancing). Между вызываемым объектом и вызывающим субъектом должен находиться компонент, балансировщик нагрузки, задача которого - перераспределять запросы между разными экземплярами вызываемого объекта. Высокая доступность и высокая производительность реализуются именно данным способом.
  
  
• Преодоление отказа (Failover). Если целевой объект (т.е. тот, к которому перенаправляются вызовы) становится недоступен, то система преодоления отказов должна зафиксировать данный факт и перенаправить последующие запросы на доступные объекты. Именно данным способом реализуется отказоустойчивость.
  

Чтобы понять кластеризацию нужно ответить на следующие вопросы:

• какие типы объектов могут быть кластеризованы?
  
  
• где осуществляется балансировка нагрузки и преодоление отказов в моем коде?
  

В реальности не каждый объект может быть кластеризован и не всегда в коде осуществляется балансировка нагрузки и
преодоление отказа.

Например, рассмотрим следующий код:

public class A {
    ...

    public void business() {
        B instance1 = new B();
        instance1.method1();
        instance2.method2();
        ...
    }
}

public class B {
    ...

    public void method1() {
    }

    public void method2() {
    }
}

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

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

О спорном паттерне DAO

В последние годы, после выхода спецификации Java EE 6, среди разработчиков и архитекторов информационных систем развернулась нешуточная дискуссия на тему паттерна DAO. Некоторые архитекторы и евангелисты уверены, что данный паттерн устарел и является избыточным решением в эпоху инъектируемого сразу в EJB- или CDI-компоненты JPA EntityManager'а. Другие же упорно настраивают на необходимости его применения.

@Stateless
public class MyDocumentService implements DocumentService {

    @PersistenceContext
    private EntityManager em;

    // ...
}

Давайте попробуем разобраться в данном вопросе.

Долгожданный релиз Oracle Fusion Middleware 12c!

Прямо неделя релизов какая-то. Сначала Eclipse Luna, теперь долгожданный релиз Oracle Fusion Middleware 12c. Скажем дружно: "Наконец-то!".

Итак, чем же нас порадовала корпорация Oracle в этот раз.

Во-первых, это конечно же новый Oracle WebLogic 12.1.3 с частичной поддержкой Java EE 7.

Во-вторых, вышло обновление основных компонентов:
- Oracle SOA Suite;
- Oracle BPM Suite;
- Oracle Service Bus;
- Oracle Event Processing.

Oracle SOA Suite, BPM Suite и OSB можно установить из одного архива. Oracle Data Integrator можно скачать по ссылке. Oracle Event Processing в свою очередь доступен по данному адресу.

Так же обновилась наша любимая среда разработки Oracle JDeveloper. Важно! Разработка для Oracle Service Bus и Oracle Event Processing теперь тоже ведется в данной среде.

Итак, что же стало лучше?

Общие изменения

1. Упростилась установка среды разработки. WebLogic, JDeveloper и компоненты Fusion Middleware устанавливаются из одного архива. Разработанные композиты могут запускаться на встроенном в JDeveloper экземпляре WebLogic'а аналогично старым-добрым сервлетам и EJB. В качестве СУБД для хранения схемы SOAINFRA используется JavaDB.

2. Добавлен отладчик композитов (и, вероятно, OSB-сервисов).

3. Добавлен встроенный тестер для SOA, теперь для запуска тестов не нужно обращаться к EM. Так же поддерживается CI (Maven/Hudson).

4. Добавлена поддержка REST.

5. Добавлены шаблоны компонентов при редактировании SOA-композитов. Можно разрабатывать свои компоненты.

6. Доработана оптимизация исполнения на Exalogic.

7. Переделана система авторизации в сторону большей гибкости.

8. Добавлен новый компонент - Enterprise Scheduler (ESS).

9. Улучшена консоль управления EM.

10. Улучшена обработка ошибок, т.н. Error Hospital.

11. Увеличена производительность платформы. Добавлена ленивая загрузка композитов и оптимизирована схема БД.

12. Улучшен SOA Composer.

13. Добавлен новый компонент - Managed File Transfer (MFT).

14. Добавлена поддержка мобильных каналов (Mobile Channel Enablement).

15. Добавлена поддержка облачных приложений.

16. Добавлены новые JCA-адаптеры (в частности LDAP-, Coherence-, MSMQ-адаптеры).

17. Улучшен компонент B2B.

BPEL

1. Добавлена поддержка встраиваемых и исполняемых отдельно (standalone) подпроцессов.

2. Добавлена поддержка шаблонов и разрабатываемых пользователем активностей.

Oracle Service Bus

1. Разработка для OSB теперь осуществляется в JDeveloper.

2. Добавлена поддержка переупорядочивания сообщений аналогично имеющейся в компоненте Mediator.

3. В EM добавлена консоль управления OSB.

4. Динамическая валидация содержимого сообщений во время исполнения, основанная на выражениях.

EDN

1. Переписан на использование JMS в качестве базовой реализации (раньше использовалась Oracle AQ). По-идее, теперь должна появиться возможность включать гарантированную доставку событий.

Так же существенно улучшен продукт Oracle Event Processing, но т.к. я не имею опыта его использования, то мне трудно разобраться в данных изменениях.

Много материала, описывающего нововведения, есть в блоге Niall Commiskey.

Long Live Oracle!

P.S. Конечно новая верстка сайта документации реальный вырвиглаз! Приходится скачивать в PDF и только потом читать, мартышка к старости слаба глазами стала...

Понравилось сообщение - подпишитесь на блог

Eclipse Luna

Очередной июньский релиз Eclpse SDK.

Сегодня вышла новая версия замечательной и фактически самой распространенной и известной среды разработки - Eclipse SDK. Скачать релиз можно с обновленной страницы загрузки.

Так же можно посетить отдельную страницу релиза.

Для разработчиков на Java самым важным компонентом среды является конечно же Java Development Tools (JDT). Из основных нововведений стоит отметить полную поддержку Java 8 из коробки (в Kepler нужно ставить патч на JDT). Люди из мира Linux, привыкшие пользоваться Vim и Emacs, оценят новую темную схему. Так же стоит отметить, что наконец-то коллеги доделали разделение экранов редактирования кода, теперь открыть одновременно два окна на одном экране можно всего-лишь нажатием комбинации клавиш, причем разделение можно сделать как по вертикали, так и по горизонтали. Ну и конечно нас всех ждет множество других улучшений косметического характера (в частности теперь можно скрывать строку кнопок навигации и поиска, если вы ею все равно не пользуетесь, это позволяет выиграть место по вертикали).

Традиционно вместе со средой разработки для Java обновляется большинство основных проектов: Spring Tool Suite, C/C++ Development Tools (CDT), Eclipse Communication Framework (ECF), JavaScript Development Tools (JSDT), Web Tools Platform (WTP), EGit, ну и конечно же "внутренности": реализация OSGi - Equinox, SWT и е4. Всего нам обещают обновление 76-ти проектов. Все проекты доступны в Eclipse Marketplace.

Позволю себе отметить два интереснейших проекта.

Eclipse Recommenders. Это воистину киллер-фича. База исходного кода анализируется с помощью байесовских сетей и строится модель использования. Соответствующий плагин к Eclipse при использовании автоподстановки (Ctrl + Space) предлагает элементы кода в зависимости от частоты их использования в проанализированной базе, например при автоподстановке после System.out. он предложит сначала print(), потом println() и т.д., а не будет перечислять методы по алфавиту как в других IDE. Аналогичные возможности реализованы при переопределении методов и в цепочках вызовов. Можно подключать свои модели + есть модели для популярных фреймворков, но их надо искать. В поставке идет модель для JDK и многих проектов Eclipse, в частности упрощается процесс разработки на SWT.

Новый расширяемый движок сниппетов (шаблонов кода) - SnipMatch. Иногда при использовании API мало вызвать метод, его в добавок нужно обернуть в try-with-resource или выполнить какую-то подготовительную работу. Теперь можно написать снипеты для своего фреймворка и выложить их куда-нибудь в Git-репозиторий. Eclipse может подключаться к таким репозиториям и предлагать шаблоны кода из них. В итоге разработка становится существенно быстрее. Естественно есть встроенный редактор шаблонов. Вместе со SnipMatch уже поставляется большое количество шаблонов + в сети есть репозитории для популярных фреймворков, например Vaadin.

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

Приятной вам разработки!

Понравилось сообщение - подпишитесь на блог

Новый пример - Message-Driven POJO на основе Spring Framework

Разбирался с хламом на диске и нашел старый пример чтения сообщений из JMS посредством кода на основе Spring Framework. В некоторых кругах данный подход называют Message-Driven POJO. Пример осуществляет чтение из очереди в несколько потоков, причем за управление потоками отвечает WorkManager. Оформил как Maven-проект и добавил к своей коллекции примеров на GitHub.

Проект основан на Spring 4, поэтому пришлось повозиться с зависимостями. Больше всего удивило, что в Maven-репозиториях теперь не так-то просто найти архив с интерфейсами JMS 1.1. Все так активно переходят на 2.0?

Возможно вам это будет интересно.

Понравилось сообщение - подпишитесь на блог

Суровый женился!

Сообщаю постфактум по возвращении из свадебного путешествия.

Седьмого июня произошло знаменательное событие: Суровый таки женился. В связи с этим принимаются поздравления. Несколько фотографий.

Суровый:

Красавица-жена:

Счастливая молодая семья:

Собственно подготовкой к свадьбе объясняется некоторое затишье в блоге, надеюсь, что семейная жизнь оставит мне немного времени на написание постов.

Понравилось сообщение - подпишитесь на блог

Hibernate: это должен помнить каждый - 3

В связи с выпиливанием из пакета org.springframework.orm.hibernate4 класса HibernateTemplate остро встал вопрос самостоятельного управления жизненным циклом сессии в наших приложениях. С этим возникают сложности. Давайте попробуем разобраться.

Как минимум, начиная с версии Hibernate 3.1, понятие "текущая сессия" привязано к границам текущей транзакции. Сессия открывается при первом вызове getCurrentSession() и закрывается при завершении транзакции. Так же содержимое сессии автоматически синхронизируется с БД (flush) перед коммитом транзакции. Вы можете вызывать метод getCurrentSession() в вашем коде столько раз, сколько нужно, но до тех пор пока транзакция не завершена.

Для включения данного режима необходимо выставить следующие настройки:

• hibernate.transaction.manager_lookup_class - указать стратегию, специфичную для вашего сервера приложений;
  
  
• hibernate.transaction.factory_class - в значение org.hibernate.transaction.JTATransactionFactory (org.hibernate.engine.transaction.internal.jta.JtaTransactionFactory для Hibernate 4)

Очень важно! Применение данных настроек не означает, что каждая сессия будет автоматически закрываться при завершении транзакции. Речь идет только о сессиях, полученных посредством getCurrentSession(). Если вы в своем коде используете openSession() и управляете сессией самостоятельно, то вам необходимо явно вызывать методы flush() и close().

При использовании управляемых контейнером транзакций (Container-Managed Transactions, CMT) - стандартной функциональности EJB - настройки несколько отличаются: значение свойства hibernate.transaction.factory_class нужно выставить в org.hibernate.transaction.CMTTransactionFactory (org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory для Hibernate 4).

Но что делать, если у нас нет сервера приложений?

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

Для включения данной стратегии необходимо выставить следующие настройки:

• hibernate.transaction.factory_class - в значение org.hibernate.transaction.JDBCTransactionFactory (org.hibernate.engine.transaction.internal.jdbc.JdbcTransactionFactory для Hibernate 4);
  
  
• hibernate.current_session_context_class - в значение thread.

Опять же, применение данных настроек не означает, что каждая сессия будет автоматически закрываться при завершении транзакции. Речь идет только о сессиях, полученных посредством getCurrentSession(). Если вы в своем коде используете openSession() и управляете сессией самостоятельно, то вам необходимо явно вызывать методы flush() и close().

Следует учитывать, что данная стратегия применима в Java SE, при использовании Java EE (по сути - при использовании EJB) нужно подключать JTA и привязывать сессию к транзакции.

Понравилось сообщение - подпишитесь на блог

Зачем нужны сервера приложений, если есть Apache Tomcat и Spring Framework?

На форуме Javatalks задали вопрос: а зачем нужны сервера приложений, если есть связка Apache Tomcat и Spring Framework? Обычно в таких случаях первые мысли возникают про EJB и сопутствующие спецификации, но на самом деле промышленные сервера приложений предоставляют множество сервисов любой программе независимо от используемых технологий. Подробный ответ доступен в моей статье.

Понравилось сообщение - подпишитесь на блог

Рекомендуемые книги по программированию, проектированию и системной итеграции

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

Программирование

• Харольд Абельсон, Джеральд Джей Сассман - Структура и Интерпретация Компьютерных Программ. На мой взгляд лучшая книга, рассказывающая что такое программирование вообще и как оно делается. Авторы проводят читателя от начал функциональной декомпозиции - понятия того, что мы пишем программу, чтобы она делала нечто полезное и эти действия можно разделить на этапы, до моделирования сложных структур данных и понимания того, как же исполняется программа. Необычным для подавляющего большинства программистов будет то, что с оператором присваивания мы знакомимся только в третьей главе, после того как напишем довольно сложную полиморфную программу! Так же авторы показывают как осуществляется интерпретация программы, ее компиляция, а так же как работает абстрактное вычислительное устройство - регистровая машина. Впрочем данное вычислительное устройство не так уже и абстрактно, стоит вспомнить, что виртуальная машина Android построена именно по регистровой модели. Само понятие ООП не вводится, но интересно, что авторы при этом умудряются рассказать, что такое связь данных и обрабатывающего их кода, конструктор, как реализовать полиморфизм и т.д. Книга содержит огромный набор задач, в интернете даже есть специальные сайты, посвященные их разбору и решениям на разных языках программирования.
  
  
• Лавров С.С. - Программирование. Математические основы, средства, теория. Книга тяжелая и математичная, но демонстрирует базу нашей работы. Приводятся математические основы логики, формальных языков, объясняется теория вычислимости на примере языка Lisp. Автор объясняет основные понятия языков программирования, делает введение в ООП и ФП. Думаю, увлекающимся теорией будет интересно.
  
  
• Alan Carter, Colston Sanger - The Programmers' Stone (рус). Немного о мышлении программистов или почему одни разработчики на порядок продуктивнее других.
  
  
• Luca Cardelli, Peter Wegner - On Understanding Types, Data Abstraction, and Polymorphism. Это не книга, а скорее статья на 43 страницы, очень насыщенная математическим формализмом, в которой авторы рассказывают о том, что такое система типов. Кто занимается практическим программированием на таких языках как Java, тот по сути неявно, исходя из каких-то эмпирических закономерностей, строит программу как свою собственную систему типов. В данной работе же формально объясняется переход от нетипизированной вселенной к системе типов, в том числе и параметрических (можно понимать их как Generics). Так же есть главы, посвященные абстрактным типам данных, наследованию и полиморфизму.
  
  
• John Hughes - Why Functional Programming Matters. Небольшая статья на 23 страницы, являющаяся введением в функциональное программирование. Объясняется что такое функции высших порядков, как их комбинировать друг с другом. В заключение приводится пример решения задачи из, как выразился автор, "искусственного интеллекта" - разбор дерева игры с помощью ФП.
  
  
• Евгений Кирпичев - Элементы функциональных языков. Полезная статья для интересующихся ФП. Собраны сведения обо всех элементах и конструкциях функциональных языков, которые придают им такую мощь и выразительность: функции второго порядка, замыкания, сопоставление с образцом, хвостовая рекурсия, вывод типов, алгебраические типы данных, классы типов (не путать с классами в Java!) и т.д. Статья очень насыщенная и полезная, помогает иначе взглянуть на привычные вещи.
  

Собеседование Java-разработчиков. Шесть лет спустя

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

Прежде всего отмечу, что мы не используем всяческих анкет и списков вопросов. Несколько раз я сталкивался с компаниями, в которых техническое интервью построено следующим образом: специалист берет соответствующий вакансии список вопросов и задает их кандидату один за другим. Например, 5 вопросов по Java, 3 по Spring Framework, 4 по WebLogic, 5 по SOA и т.д. У нас такой подход не прижился, т.к. он обезличивает процесс. Нет ни собеседуемого, ни собеседующего, есть два механических робота, задача одного из которых прочитать список вопросов, а другого - максимально обще на них ответить. Никакой беседы при этом построить невозможно. "- Вы знаете WLST? - Да", вот и все собеседование.

Вместо этого предпочитаем строить собеседование как разговор равных, уважающих друг друга специалистов. Прежде всего стремимся побольше узнать о предыдущем опыте кандидата, а потом исходя из него задаем вопросы. Например, человек говорит, что разрабатывал что-то для банка на основе Spring Framework и созданная им программа работала на сервере приложений Oracle WebLogic. Здесь можно задать несколько вопросов по предметной области. Важно чтобы человек не просто механически кодировал, но хоть немного понимал что он делает и зачем. Так же можно спросить, а почему кандидат использовал Spring Framework, а не Java EE с EJB или CDI. Ответы бывают довольно интересными. Хотя, конечно, если человек претендует на позицию Junior'а, то он скажет, что данный выбор был сделан не им. Тогда можно продолжить разговор уже про сам Spring Framework и попросить рассказать какой компонент фреймворка отвечает за построение объектов. Общая идея такова: ответ на любой вопрос является источником следующего. Таким образом получается беседа, которая позволяет и кандидату немного расслабиться, и нам понять границы области его знаний.

При этом несмотря на выбранный нами стиль собеседования, есть ряд вопросов, которые мы пытаемся задать, встраивая их в ткань разговора. К таким базовым вопросам относятся следующие:

• Вопросы по теории программирования: вывод типов, статическая и динамическая типизация, алгоритмы, работа с памятью Разговор получается интересным, если человек владеет каким-нибудь скриптовым или функциональным языком программирования. Нам важно, чтобы кандидат имел определенную теоретическую подготовку, мог обосновать выбор того или иного подхода или языка программирования с точки зрения удобства разработки, производительности, предметной области. Уметь написать Hello World на Groovy или Scala еще не значит владеть функциональным программированием.
  
  
• ООП и, если знает, функциональное программирование. Про ООП просим рассказать как человек понимает суть парадигмы. Какие преимущества дает объединение данных и кода в объекты. Интересно, как кандидат понимает полиморфизм. Какие виды полиморфизма ему известны. Почему-то вызывает сложности вопрос о том, а можно ли обойтись без наследования. Если человек знаком с функциональным программированием, то интересуемся практическим опытом его применения. Здесь же просим спроектировать что-то несложное.
  
  
• Паттерн "Инверсия управления" (IoC), его разновидности и конкретные реализации. Сейчас трудно найти команду разработчиков, которая в своей работе не использовала бы какой-нибудь IoC-контейнер. В крайнем случае данный паттерн так или иначе переизобретается. Просим рассказать, зачем нужен данный паттерн, какие бывают его разновидности (речь идет о инъекции зависимостей/локаторе сервисов, но отвечать почему-то начинают про инъекцию через конструктор/инъекцию через сеттер). Если кандидат знаком с конкретными реализациями, то задаем вопросы по ним (обычно спрашиваем про квалификационные аннотации в CDI или фабрику бинов в Spring Framework).
  
  
• ORM-фреймворки, JPA, JDBC. Здесь есть где развернуться. Большинство современных корпоративных приложений служат в основном для манипуляции данными в той или иной БД, поэтому владеть соответствующими инструментами необходимо. Мы используем как различные ORM, так и JDBC, причем работаем и с голым JDBC, и со Spring-JDBC. Обычно задаем вопрос: что такое ленивая загрузка и какие проблемы она создает. Здесь можно поговорить и о решении данных проблем. Вскрывается, что человек Hibernate использовал и мэпинги писал, но что такое сессия, транзакция, соединение с БД, как они связаны, разницу между присоединенными и отсоединенными от сессии объектами не понимает. Если же человек действительно понимает, как работают ORM-фреймворки, то можно поговорить о более высокоуровневых вещах, таких как прозрачное хранение, незащищенная модель предметной области (Exposed Domain Model), плюсы и минусы незащищенной модели перед сокрытием бизнес-логики за фасадом из POJO или EJB.
  
  
• JavaEE и сервера приложений. Речь идет прежде всего о том, какие задачи решают сервера приложений. Хорошо, если кандидат имеет опыт работы с конкретными промышленными серверами приложений, знает их сильные и слабые стороны. Может быть знает о проблемах в реализации той или иной технологии на конкретном сервере (например JPA на сервере приложений IBM WebSphere 7.0). Если человек говорит, что знает EJB и/или CDI, то задаем вопросы по этим технологиям. Веб-часть практически не трогаем.
  
  
• Интеграционные механизмы, веб-сервисы и JMS. Данные вопросы обусловлены уже конкретикой нашей работы. Мы готовы обучать человека разработке на сервисных шинах предприятия, если он обладает хотя бы базовым пониманием интеграционных механизмов. Спрашиваем в основном о SOAP, WSDL, MDB, просим написать несложный XPath-запрос.
  
  
• Вопросы по базам данных. Нам приходится обрабатывать большие объемы данных и решать проблемы с высокой нагрузкой на слой хранения. В идеале хочется, чтобы кандидат мог оптимизировать SQL-запросы, писать хранимые процедуры на PL/SQL, знал что такое индексы и какие они бывают, а так же как работают. Для меня было бы огромным плюсом, если человек осилил книгу Тома Кайта Oracle для профессионалов.

Конкретные вопросы зависят от заявленного опыта и уровня кандидата. Если человек не знает EJB, то и задавать соответствующие вопросы не за чем.

И еще момент. Даже если собеседуется матерый ведущий разработчик, есть смысл спросить что-то очень базовое и простое. Например, "что такое монитор". Странно выглядит ведущий разработчик с солидным стажем программирования на Java, не знающий базовых понятий многопоточности.

Специфика нашей работы требует людей, владеющих широким спектром технологий, т.к. заказчиков много и проекты весьма разные. Соответственно, важно определить не только текущий уровень знаний, но и потенциал кандидата. Для выявления потенциала мы спрашиваем у человека чему он научился за последний год, а так же какую последнюю книгу по программированию (или шире - IT) он прочитал. Результат надо сказать довольно удручающий: большинство из приходящих на собеседование книг не читают вообще, предпочитая Habrahabr. Чтож, это их выбор.

Да, мы задаем вопрос "кем вы видите себя через 5 лет". Нам это действительно важно.

А как вы собеседуете специалистов и на что в первую очередь обращаете внимание?

UPD: Иногда мы просим описать решение какой-нибудь практической задачи. Например, мы разрабатываем приложение на Java EE и нам нужно сделать следующее: пользователь заполняет форму и ее содержимое отправляется на почту. Здесь можно немного поговорить о юзабилити - а что если SMTP-сервер сильно нагружен или с ним плохая связь и письмо будет отправляться очень долго. Как правило становится понятно, что письмо нужно отправлять в другом потоке, нежели обрабатывается страница, ну или использовать асинхронные сервлеты, хотя на мой взгляд это избыточно. Далее можно поговорить и о многопоточности в целом, и об ограничениях при использовании потоков на сервере приложений (как минимум полезно спросить, понимает ли кандидат, почему не рекомендуется использовать new Thread() в управляемой среде). Если человек понимает, что здесь можно применить JMS или задействовать Work Manager'ы, то это просто замечательно. Как минимум на middle я бы его точно взял.

Понравилось сообщение - подпишитесь на блог

А давайте перепишем DAO с использованием возможностей Java 8

В последние годы складывается следующая тенденция развития объектно-ориентированных языков программирования: к ним добавляют все больше и больше элементов, взятых из мира функционального программирования. C# обзавелся поддержкой анонимных функций несколько лет назад, настала пора и Java-разработчикам приобщиться к прекрасному. Поддержка анонимных функций и основанный на их широком использовании новый API Collection Framework'а ждет нас в Java 8. Интернет уже запестрил статьями вида "Как написать свой Hello World на Java 8". Но писать Hello World не интересно, давайте лучше рассмотрим, как можно использовать новые возможности для решения конкретных задач в нашем суровом "Ынтырпрайз" мире.

DAO на голом JDBC без использования Spring Framework и AOP. Хотите немного функциональной магии?

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

Используем паттерн QueryObject

В интеграционном проекте приходится решать две основные задачи: извлекать коллекции объектов из одного хранилища, например базы данных, и записывать их в другое. Соответственно, концептуально мы имеем две операции: load и save. При этом типов объектов и алгоритмов их загрузки/извлечения может быть очень много. Для организации DAO можно описать все операции в виде методов в одном классе. Получится класс, состоящий из N*2 методов, где N - количество типов объектов. Данный класс будет очень большим и сложным, по сути у нас получится просто некоторое кладбище SQL-запросов, которое будет чрезвычайно трудоемко как сопровождать, так и тестировать.

Можно разделить передаваемые типы данных на группы по функциональному признаку и создать не один класс DAO, а несколько. Однако опыт подсказывает, что при интеграции как правило выделяется одна функциональная область, число типов данных в которой значительно превышает все остальные. Речь идет о нормативно-справочной информации (НСИ). Создание нескольких классов по два-три метода и одного с двадцатью методами не является решением проблемы. Антипаттерн "волшебный объект" все еще остается в системе.

Пойдем другим путем. Воспользуемся паттерном QueryObject. При использовании данного паттерна мы инкапсулируем логику загрузки каждого типа объекта в свой класс. Аналогично поступаем с логикой сохранения данных. Таким образом у нас получается N*2 маленьких классов, состоящих из одного бизнес-метода. Данные классы легко сопровождать и тестировать. В случае необходимости очень просто сделать заглушку (mock) - необходимо подменить всего один метод. Вероятность конфликтов при работе с системой контроля версий так же уменьшается.