четверг, 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. Наверное предназначение данной фотографии - стать первым шагом моего творческого пути в корпорации. Думаю, мне здесь понравится.

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

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

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

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

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

вторник, 12 августа 2014 г.

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.

понедельник, 21 июля 2014 г.

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

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


@Stateless
public class MyDocumentService implements DocumentService {

    @PersistenceContext
    private EntityManager em;

    // ...
}

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