Правильная платформа для Java EE приложения или как Линукс оказался в 3 раза медленее z/OS

Ваш покорный слуга написал еще одну статью на Хабрахабр - Правильная платформа для Java EE приложений: как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle.

Краткое резюме: очень быстро мигрировали Java EE приложение, использующее Hibernate, на мейнфрейм и провели сравнительное тестирование, с одной стороны данное приложение на zLinux + Oracle (2 LPAR), с другой - оно же на z/OS + DB2 (1 LPAR). Вариант на z/OS + DB2 работал быстрее в 3 раза. Конфигурация выбрана исходя из требований заказчика, для которого выполняли тестирование, но в принципе соответствует реальным практикам, почему-то именно так и разворачивают - на Linux стараются вынести каждую подсистему на свою виртуальную машину, на z/OS - весь стек разворачивается вместе, тем самым используются примущества операционной системы, в частности Cross-Memory Services - механизм, позволяющий из одного адресного пространства (WebSphere Application Server) обратиться к другому (DB2) с помощью нескольких машинных команд, минуя планировщик ОС. Преимущества подхода перед типичным кодом межпроцессной коммуникации (IPC), содержащем сотни, а то и тысячи машинных инструкций, да к тому же выполняющем обращения к ядру, очевидны любому инженеру, знакомому с операционными системами чуть глубже, нежели на уровне "интерфейс унылый/интерфейс неунылый".

Отдельно отмечу, что исключительно расчетная часть на Java под z/OS выполнялась быстрее на 25%, что является отдельным приветом сторонникам мнения "Java на мейнфрейме тормозит и вообще".

P.S. Очень распространенное заблуждение, что zLinux выполняется только на z/VM. В данном случае и z/OS и zLinux выполнялись на LPAR'ах, VM в тесте не участвовала.

UPD: Хабраэксперты не подкачали, адекватные комментарии и претензии затерялись в ворохе: "Мы веруем в Линуха святого, а вы говорите, что он в чем-то хуже? Вы все врети, вы - сурковскаяпропаганда!!!" Грамотность аудитории оставляет желать лучшего, но это - уже наша недоработка. Основная претензия - разнесение подсистем на линуксе по разным LPAR'ам, но кто виноват, что линуксоиды так деплоят. В целом интерес к теме прослеживается и это не может не радовать.

UPD2: С нетерпением жду реакции анонимных аналитиков с ЛОРа.

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

А как выглядит эта ваша z/OS?

Прежде всего стоит отметить, что настраивать панельки и приложения z/OS можно по-всякому, мейнфрейм - это штучная вещь и каждый системный программист может изменять настройки системы так, чтобы они максимально соответствовали бизнес-целям использующего его предприятия. Я расскажу о том, как выглядит одна из доступных мне систем. Думаю, читателям блога будет интересно увидеть, как же осуществляется взаимодействие с настоящим чудом инженерной мысли.

Для подключения к мейнфрейму с компьютера под управлением ОС семейства Microsoft Windows можно использовать утилиту IBM Personal Communications, эмулирующую терминал 3270. Работа с операционной системой z/OS производится в полноэкранном многофункциональном режиме, сильно отличающемся от dumb terminals с унылой черной командной строкой.

Для начала сеанса взаимодействия с z/OS нас попросят ввести имя приложения, с которым мы будем работать. Это может быть, например, Customer Information Control System (CICS) или Time Sharing Option (TSO). Я покажу как выполнять базовые операции в TSO.

Наиболее трудной для освоения особенностью терминала является восприятие факта, что клавише Enter соответствует правый Ctrl.

Производительный отказоустойчивый географически разнесенный кластер на базе мейнфрейма? Yes, rly!

Вторую половину октября и весь ноябрь Суровый провел в солнечной Франции неподалеку от Лазурного берега, в клиентском центре IBM, расположенном в замечательном городке Монпелье. Ну знаете, как это бывает: глухие стены, сенсорные панели, мейнфрейм за стеклом, французские коллеги, вкалывание с 9 и до 22-х, но самое главное - очень и очень интересная задача.

Занимались мы с коллегами тестированием реального банковского приложения - платежной системы - на нашей уникальной платформе IBM zEnterprise EC12. В качестве программного обеспечения промежуточного слоя использовалось стандартное ПО IBM: СУБД DB2 z/OS, менеджеры очередей WebSphere MQ, сервер приложений WebSphere Application Server for z/OS (еще раз было продемонстрировано, что вопреки популярному убеждению мейнфрейм идеально подходит для работы Java-приложений). Платежная система была развернута на кластере Parallel Sysplex, узлы которого работали в режиме Active-Active. Самое главное, что хотелось проверить, - как ведет себя платформа и приложение при изменении расстояния между узлами кластера вплоть до 70 км.

Результатами, касающимися масштабируемости и производительности, хотим поделиться с вами в статье: Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12. Автором статьи является ваш покорный слуга. Если будет зафиксирован интерес к теме, то напишу еще о результатах тестирования высокой доступности, обеспечиваемой нашей платформой.

Чтобы немного оживить заметку, фотография Сурового челябинского программиста на Чертовом мосту на фоне гор:

и да, мы тоже любим Linux и Тукса, но работать предпочитаем в z/OS.

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

Кластер серверов приложений Oracle WebLogic Server забивает сеть при возникновении проблем

Не все администраторы знают, что по-умолчанию экземпляры сервера приложений Oracle WebLogic Server ведут логи не только в своих каталогах DOMAIN_HOME/server/SERVER/logs, но и пересылают их по сети на сервер администрирования домена. Это сделано для облегчения работы людей: если у вас домен из нескольких десятков экземпляров сервера приложений, то очевидно, что иметь все логи доступными в одном месте очень удобно. Но за данное удобство приходится платить.

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

На небольших доменах (4 - 8 экземпляров) я отключал/отключаю пересылку логов на сервер администрирования. В консоли администратора необходимо в настройках каждого управляемого сервера выставить свойство Domain log broadcaster:, Severity level на странице Environment -> Servers -> SERVER -> Logging -> General, Advanced в значение Critical или даже более жесткое.

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

Для включения фильтрации необходимо создать один или несколько фильтров логов. Фильтры создаются для всего домена на странице DOMAIN -> Configuration -> Log Filters.

При создании нового фильтра достаточно задать его имя.

Если затем перейти в новый созданный фильтр, то с помощью кнопок на панели Expression можно сформировать условие фильтрации.

После редактирования условия нужно не забыть нажать кнопку Save. Отредактированный фильтр вместе с условием станет доступен на таблице Log Filters.

Теперь его можно назначить для свойства Domain log broadcaster:, Filter на странице Environment -> Servers -> SERVER -> Logging -> General, Advanced.

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

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

Механизм ограничений на импорты в Eclipse (Access restriction)

Возможно каждый использующий интегрированную среду разработки Eclipse SDK программист сталкивался с подобной ошибкой: Access restriction: The type JLabel is not accessible due to restriction on required library ..\lib\rt.jar

Механизм ограничений на импортируемые классы появился в Eclipse 3.1 и предназначен в первую очередь для разработчиков плагинов, чтобы бить по рукам за доступ ко внутренним API бандлов. Выглядят данные ограничения следующим образом: в (Project) Properties -> Java Build Path -> Libraries -> JRE определены Access Rules для всей JRE или для каждого jar'а внутри данной JRE. По-умолчанию проект создается в среде исполнения (Execution Environment) JavaSE-1.7, которая накладывает ограничения на rt.jar - запрещены все пакеты javax.* кроме 160+ базовых.

Проблема с классами из Swing может возникнуть, если в результате экспериментов разработчик выставит в качестве Execution Environment или JRE-1.1, или вообще какие-то CDC/OSGi-Minimum. При работе с классами Eclipse проблема может возникнуть при попытке использования неразрешенных классов.

Можно отказаться от использования Execution Environment и при создании проекта выбирать опции JRE - Use a project specific JRE или Use default JRE. Все советы вида "удалите из проекта System Library, а потом руками добавьте ее" основаны именно на этом - замените Execution Environment на просто JDK.

При необходимости можно изменить поведение Eclipse, для этого есть два пути:

Windows -> Preferences -> Java -> Compiler -> Errors/Warnings

(Project) Properties -> Java Compiler -> Errors/Warnings

Нужно поменять значение у опции Forbidden References на Warning (по-умолчанию - Error), но делать это нужно в самом крайнем случае.

Для получения более подробной информации можно посмотреть данный пост или этот вопрос на Stack Overflow.

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

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