понедельник, 26 января 2015 г.

Отметился в подкасте Разбор полетов

Коллега Виктор Гамов снова позвал в свой подкаст, на сей раз - Разбор полетов. Говорили про OSGi, основной посыл выпуска: "технология хорошая, но правильно готовить ее могут не только лишь все, мало кто может это делать". Говорил мало, т.к. участников подкаста много и каждому хочется что-то сказать, не всегда возможно вставить слово, чтобы никого не перебить.

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

З.Ы. На мой личный взгляд самыми лучшими продуктами, построенными на основе данной технологии, являются конечно же Eclipse SDK и WebSphere Liberty Profile.

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

вторник, 20 января 2015 г.

Кластер серверов приложений 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.


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

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

четверг, 15 января 2015 г.

Механизм ограничений на импорты в 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.

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

среда, 14 января 2015 г.

Новый мейнфрейм от IBM - z13

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


  • z13 является первой в мире системой, способной обрабатывать до 2.5 миллиардов "надежных, защищенных, прослеживаемых от начала до конца" транзакций в день (примерно 29 тыс. в секунду). Каждую транзакцию можно пропустить через механизм аналитики реального времени, что особенно важно в таких областях, как защита от мошенничества в финансовой и других сферах.

  • z13 имеет в три раза больше оперативной памяти на борту (до 10 ТБ), до 141 процессорного ядра, каждое из которых настраивается как CP, zIIP, ICF, IFL или SAP. Ядра, настроенные как zIIP или IFL, обеспечивают поддержку SMT (до двух потоков на ядро), которую можно включать и отключать на лету. В новые процессоры добавлена поддержка векторных операций (SIMD). В два раза увеличено количество каналов ввода-вывода.

  • Огромное количество ОЗУ на борту машины является драйвером построения на мейнфрейме in-Memory баз данных. В частности для обработки неструктурированных данных улучшена поддержка Hadoop.

  • Новая версия операционной системы z/OS 2.2.

  • Полная поддержка Linux и OpenStack.

  • Много усилий приложено для интеграции мейнфрейма и мира мобильных приложений.

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

Так же нельзя не отметить, что в первом квартале текущего года ожидается выход Java 8, в которой будет обеспечена поддержка новых инструкций процессора для векторных операций (в частности при обработке XML), массовый параллелизм с задействованием SMT, а так же использование новых аппаратных возможностей для криптографии и сжатия данных. Ожидается рост производительности Java-приложений на 50% по сравнению с Java 7 на zEC 12. Думаю, что это еще одна причина обратить внимание на мейнфрейм, как на платформу для работы ваших Java-приложений.

Заинтересовавшимся системой читателям предлагаю посмотреть интересный трейлер:


Само видео доступно по ссылке. Подробное описание новой модели.

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

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

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


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

среда, 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.