четверг, 11 декабря 2014 г.

Зачем нужны 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 в современном мире разработки корпоративных приложений.


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

среда, 3 декабря 2014 г.

Как подружить 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, о работе с которым я расскажу в данной статье.

четверг, 2 октября 2014 г.

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

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


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


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

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

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

вторник, 16 сентября 2014 г.

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-е сообщение в Блоге Сурового :)

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

воскресенье, 14 сентября 2014 г.

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

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

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

понедельник, 1 сентября 2014 г.

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

Вот и заканчивается жаркое лето 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.


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

суббота, 16 августа 2014 г.

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

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