Just One More Article About SOA and BPM.

Что такое SOA?
Это небо
Плачущее небо
Под ногами

Давеча посетил Oracle Tech Forum 2007 с целью посмотреть на текущую ситуацию с SOA и BPM с точки зрения Oracle. Было много интересных (и не очень ;-) докладов, особенно заинтересовали описания реальных проектов.
В связи с этим возникло желание немного рассказать о Service-Oriented Architecture (SOA) и Business Process Management (BPM) тем, кто с такого рода решениями не сталкивался, но интересуется современными трендами в IT. Так же назревает некоторая необходимость прояснить терминологию.
Базовую информацию можно найти в википедии: SOA и BPM.

SOA

Текущие реалии и история
Чтобы современному разработчику понять, откуда такой интерес к SOA и BPM, необходимо представлять, какие основные свойства присущи современным КИС (корпоративным информационным системам). Буквально недавно наблюдалась эпоха ERP - эдаких информационных Голиафов, очень крупных систем, в рамках которых пытались автоматизировать деятельность всего предприятия. Помимо этого, штатные программисты компании писали свои программы для автоматизации, так как оказалось, что купленная ERP все-таки не так хороша; при поглощениях/слияниях наследовался парк ПО купленной компании. Так что рано или поздно к идее, что всю деятельность можно автоматизировать средствами одной системы, возникли серьезные претензии ;-)
Компания рано или поздно вставала перед фактом: в её IT-среде наблюдается зоопарк различных систем, от корпоративных ERP до мини-утилиток. Все это написано разными людьми в разное время, при этом интеграция этих систем реализована по принципу "одна с несколькими", а интерфейсы этих систем и механизм их взаимодействия крайне плохо документирован. В дальнейшем так и будем называть эту сложившуюся ситуацию зоопарком систем.

Рис. 1

Для компаний, оказавшихся в такой ситуации с унаследованными (legacy) системами, стало очевидно, что сегодня мы живем в постмодернистском IT-мире - новых систем в парке компаний становится сравнительно немного, а большая часть усилий уходит на интеграцию существующих. Сплошная эклектика ;-) Задача современного разработчика чаще всего не писать, а объединять...
Так же надо учитывать недовольство IT-менеджеров сегодняшними ERP-системами. Дело в том, что эти ERP - попытка создать универсальную ИС предприятия. При этом видение бизнеса, по сути, бизнесмену навязывается вендором ERP-системы. Это может ударить по одному из важнейших рыночных преимуществ компании - уникальности.
Этот тезис позаимствован из очень интересной и спорной книги Блеск и нищета информационных технологий. Почему ИТ не являются конкурентным преимуществом, но, несмотря на всю спорность, доля здравого смысла здесь есть.
Так же универсальность ERP зачастую идет рука об руку с закостенелостью, невозможностью быстрого изменения в соответствии с требованиями ситуации. Гибкость (agility), открытость изменениям - одно из важнейших требований современного бизнеса.

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

• Повысить гибкость КИС, а, следовательно, и бизнеса
• Снизить затраты на поддержку КИС
• Сделать основные концепции КИС понятными менеджменту, сблизить менеджмент и IT
  

Концепции SOA
Для решения поставленных задач как раз и подходит SOA:

SOA определяется как программная архитектура, основанная на хорошо структурированной типологии интерфейсов, их применении, а также на тех задачах, которые эти интерфейсы решают.
Gartner Group, 1996

У SOA довольно много определений, в том числе и приведенное, но все эти определения объединяет общая идея: изначальная ориентация не на структуру ИС, а на функциональность, при этом она должна быть четко описана и заменяема. Здесь-то и всплывают сервисы - заменяемые функциональные единицы с четко описанными интерфейсами.

Не стоит путать это понятие сервисов с веб-сервисами. Сервис может быть реализован различными путями, в т.ч. и как веб-сервис.
Изначальная ориентация на сервисы, помимо повышения гибкости ИС предприятия, так же позволяет отказаться от дублирования бизнес-логики и данных, как зачастую бывает в "зоопарке" систем - теперь весь необходимый функционал или данные инкапсулированы в одном сервисе.
К тому же концепция сервисов, оперирующая терминами бизнес-логики, а не внутренними структурами данных ERP- или самописных систем, гораздо проще для понимания менеджментом компании.
Таким образом, основные концепции SOA, отраженные в базовых определениях, способствуют решению задач, поставленных перед этой парадигмой.

Реализация SOA
Мы познакомились с базовым определением SOA, и важно понимать, что когда говорят о SOA сегодня, то чаще всего подразумевают именно реализацию. Как же технологически реализовать идею о легкозаменямых взаимодействующих сервисах с четко описанными интерфейсами?
Технологий, позволяющих реализовать концепции SOA, достаточно много. Это различные варианты технологий удаленных вызовов (включая RPC/DCOM, RMI, CORBA, web-services и др.) и технологий обмена сообщениями (MQSeries, MSMQ, JMS). Но наибольшую популярность при реализации SOA-решений сегодня завоевали веб-сервисы. Так что сегодня, говоря SOA, чаще всего подразумеваем web-services ;-)

Рассуждения о том, почему именно они, несколько выходят за рамки данной статьи.
Но реализовать ИС компании как набор веб-сервисов и/или "обернуть" существующие системы ими - это только пол-дела. Остается нерешенной проблема сложности их взаимодействия. Ведь они получаются у нас связаны по принципу "многие ко многим", и с увеличением количества сервисов количество связей между ними растет лавинообразно, что серьезно усложняет систему. К тому же надо учитывать, что при взаимодействии сервисов надо будет трансформировать данные из формата одного сервиса в формат другого. И этих трансформеров понадобится по числу связей.

Рис. 2

Какой же выход из этой ситуации? Выход в централизации сервисов. Соответственно, у нас появится некоторая среда, которая будет хабом, объединяющим сервисы. Эту среду принято называть корпоративной сервисной шиной - Enterprise Service Bus (ESB).
При использовании ESB:

1. Уменьшается количество связей
2. Упрощается замена, добавление и удаление сервисов
3. Для каждого сервиса можно написать только один трансформер данных - в стандартный формат шины
4. Упрощается администрирование сервисов в работе
5. Упрощается мониторинг сервисов
   

Рис. 3

Для управления этой инфраструктурой информационной системы вводится спечиальная роль - администратор ESB. Так же ESB инкапсулирует реестр сервисов.
Что касается механизмов подключения сервисов в шину, то это, скорее всего, будут технологии веб-сервисов (сервисы афишируются как веб-сервисы - их взаимодействие с шиной осуществляется по SOAP, интерфейсы описаны на WSDL, реестр сервисов реализован как UDDI-реестр).
Но есть и альтернативные способы интеграции сервисов и шины. Здесь все зависит от возможностей и технологической реализации шины. В силу специфики блога мы будем рассматривать шины, реализованные на платформе j2ee (но при этом стоит помнить, что существуют ESB, реализованные на других платформах). Если сервисом выступает внешняя КИС, то её можно интегрировать в шину посредством технологии J2CA - коннекторов (адаптеров), так же для интеграции java-based сервисов часто используется технология JMS. В случае, если сервисом выступает СУБД, для интеграции может использоваться JDBC.
В функционал шин зачастую так же входит замечательная возможность автоматизированного оборачивания внешних систем (сервисов) веб-сервисами. Это делается практически без кодирования администратором шины. Таким образом, например, включение СУБД в шину может занять крайне малое время при отсутствии кодирования, с использованием только административной консоли шины.

Резюме
Архитектура SOA позволяет строить гибкие решения и снизить стоимость их поддержки. SOA позовляет сблизить бизнес и IT, решая так же проблему унаследованных систем. Решением проблемы "или приобретать, или разрабатывать" становится "и приобретать, и разрабатывать".
В подавляющем большинстве случаев, когда говорят "SOA", подразумевают ESB и веб-сервисы.

BPM

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

Рис. 4

Как в этом случае происходит оценка эффективности бизнеса? Чаще всего применяется агрегирующий подход - Key Performance Indicators (KPI). KPI рассчитываются за какой-либо период времени (месяц, квартал, год) и показывают эффективность подразделения (количество продаж, степень удовлетворенности клиентов и прочие, специфические для конкретного подразделения или работника). По этим показателям принимаются управляющие решения - от раздачи бонусов до увольнения.
Чем же грешит этот наиболее распространенный подход? Своей агрегативной природой. То есть бизнес мониторится пост-фактум, нет мониторинга в динамике, нет деталей. KPI показывают, что все хорошо, но не понятно, что можно улучшить; KPI показывают, что все плохо, но непонятно, где именно. А самое главное - KPI не позволяют радикально переработать ни бизнес в целом, ни конкретные структуры. В качестве примера приведу иллюстрацию одного из докладчиков на Oracle Tech Forum: зачастую 80% работы делается за 20% времени. Не правда ли, знакомо? ;-) И бизнес чувствует себя отлично, хотя есть еще огромное пространство для повышения эффективности.

Соответственно, требуется методология организации бизнеса, позволяющая оптимизировать его работу и непрерывный мониторинг, плюс максимальная автоматизация. Этим требованиям удовлетворяет процессный подход - BPM.
Итак, мы определились с основными задачами процессного подхода:

• возможность непрерывной оптимизации бизнеса
• непрерывный мониторинг
• максимальная автоматизация

Часто для обозначения бизнес-процессов так же применяется термин workflows.

Оптимизация процессов в BPM
Для реализации поставленных задач необходимо акцентировать внимание не на структуре компании, а на процессах, протекающих в ней.

Рис. 5

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

Автоматизация процессов в BPM
В современном бизнесе значительная часть работы подвергается автоматизации и большая часть информации циркулирует в электронной форме. Это позволяет автоматизировать бизнес-процессы.
Для этого необходимо иметь среду выполнения бизнес-процессов, куда загружаются (deploy) их описания. После этого работники могут запускать экземпляры процессов, передав начальные данные.

Из наиболее известных j2ee-based сред выполнения процессов можно отметить:

• BEA WebLogic Integration и AquaLogic
• IBM BusinessProcess Server
• Oracle BPEL Server
• BPEL Engine в Glassfish
• JBoss jBPM

Говоря про современные стандарты описания и выполнения процессов, следует отметить, что их достаточно много. Подавляющая часть из них - открытые, и лидером по популярности является BPEL (Business Processes Execution Language), читается "бипль".

Следует учитывать, что бизнес-аналитик при моделировании процессов и разработчик - это разные роли, и они могут пользоваться разными нотациями при описании процессов. Это, соответственно, стандарты описания (modeling) и реализации (aka выполнения, execution) процессов.
А что касается наиболее популярных стандартов обеих групп, вот некоторые из них:

• WSFL
• XLANG
• Семейство BPEL
  
• JPD
• JPDL
  

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

Зачастую среды выполнения процессов взаимодействуют с внешними системами посредством технологического API веб-сервисов. Т.е. внешние системы афишируется как веб-сервисы, и в этом случае бизнес-процесс будет синхронно или асинхронно их вызывать. Именно так работает популярнейший стандарт BPEL4WS.
Разработчику теперь необходимо описать процессы в нотации (process integration), принимаемой данной средой выполнения и определить трансформации данных для их приема из внешней системы или для передачи (data integration).
Вместо:

Рис. 6

при применении автоматизированных BPM-решений мы имеем:

Рис. 7

Рис. 8

Как упоминалось, в аспект data integration входят:

• обеспечение технологического взаимодействия внешней системы и среды выполнения процесса (технологические API)
• трансформация данных при передачи в/из внешней системы

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

Мониторинг процессов в BPM
Автоматизированные среды выполнения бизнес-процессов предлагают крайне продвинутые возможности мониторинга. Конкретные возможности продуктов выходят за рамки данной статьи, но здесь важно понять принципиальную вещь: мониторятся не технологические аспекты, а бизнес. Т.е. не uptime сервера или загрузка CPU, а сколько по времени занимает весь или конкретный участок бизнес-процесса, состояния (данные) процессов, и пр. При этом мониторинг ведется в реальном времени.
Благодаря такой детализации появляется возможность дать бесценную информацию аналитикам для дальнейшей оптимизации процессов.

Резюме
Современные автоматизированные BPM-решения вполне успешно решают проблемы, присущие функциональному подходу организации бизнеса:

• возможность непрерывной оптимизации бизнеса
• непрерывный мониторинг
• максимальная автоматизация

SOA и BPM

Терминологическое отступление
Вообще-то SOA и BPM - разные подходы, т.е. это не одно и то же. Но они настолько удачно сочетаются, что, зачастую, говоря SOA, подразумевают её в связке с BPM и наоборот.

SOA + BPM = Love ;-)
Действительно, инфраструктурная гибкость SOA и процессный подход BPM крайне эффективны вместе.

Рис. 9

Здесь под SOA понимается сегодняшнее определение - с использованием ESB.

Выводы
По оценкам Gartner, ни одна технология не завоевывала такую популярность так быстро, как BPM. А преимущества SOA позволяет связке SOA+BPM стать доминирующей архитектурой разработки КИС уже сегодня.

Влияние исследований на технологию промежуточного программного обеспечения

Наткнулся на чудесную статью с названием, вынесенным в заголовок.
Настоятельно рекомендую всем тем, кто считает себя продвинутыми j2ee-девелоперами и архитекторами. Она отлично развивает кругозор и заставляет вспомнить академические будни )))

Subj, собственно, здесь: http://www.citforum.ru/SE/middleware/history

Доступ к внешним системам и механизм глобальных транзакций на платформе J2EE: часть 2

Disclaimer
Это продолжение статьи, первую часть Вы можете найти здесь.

Понятие транзакции
Транзакция - группа операций над данными, которая выполняются или вся, или не выполняется вообще. Более подробно о понятиях и базовых свойствах транзакций можно почитать, например, в википедии. Основная задача транзакции - обеспечить целостность данных. В практически любой, даже самой простой информационной системе, можно встретить использование разработчиками локальных транзакций на источнике данных.
Еще один важный момент, который стоит напомнить, - транзакция имеет границы (boundaries), т.е. начало и завершение. Завершиться транзакция может подтверждением (commit) или откатом (rollback).

Локальные транзакции
Локальная транзакция - это транзакция на одном источнике данных.

В качестве хранилища данных в большинстве случаев мы будем рассматривать СУБД, но следует помнить, что это может быть так же и внешняя корпоративная система (EIS), и JMS-ресурс.
Следует обратить внимание на ключевое слово - локальная. Для разработчика это значит, что он может ограничивать транзакцию (определять transaction boundaries) в бизнес-логике, когда в ней происходят чтение/модификация данных из одного источника.
Что же такое источник данных? На бытовом уровне вроде понятно - это СУБД или JMS destination или EIS. Но потребуется существенное уточнение, когда мы перейдем к конкретному API. Ведь мы можем получить несколько соединений с одной СУБД через JDBC API? Что в этом случае понимать под источником данных? СУБД или соединение? К тому же, в большинстве случаев будет использоваться пул соединений, и что тогда считать источником данных: DataSource, пул или само соединение?
Для ответа на этот вопрос следует вспомнить рис. 5. Из его анализа вытекает первый тезис : источник данных - это Resource Manager. Разработчик не работает с внутренней структурой RM, он работает из бизнес-логики j2ee-приложений с соединениями (connections). Так что можно утвердить второй тезис: для разработчика интерфейсом к источнику данных является соединение. В зависимости от типа RM это может быть JDBC connection, JMS connection или J2CA Connection.
Так же уместно взгянуть на рис. 6 для того, чтобы вспомнить, откуда разработчик получает эти соединения. Получение соединений происходит из фабрик соединений нужного типа.

Здесь следует отметить лингвистический нюанс - в общем случае фабрики так и именуются: JMS Connection Factory, J2CA Connection Factory. Особняком стоит JDBC API, где фабрика называется DataSource. Дословный перевод - "источник данных" - означает немного не то, что под этим термином подразумевается в статье (весь RM). Поэтому в статье я темин DataSource буду употреблять, не переводя.
После того, интерфейс к источнику данных - соединение - получено, разработчик может пользоваться управлять локальными транзакциями. Соответственно, чтобы разработчик мог воспользоваться этим транзакционным функционалом, выбранная технология должна предоставить его в своем API. Так что и JDBC, и JMS, и J2CA предоставляют набор методов для работы с локальными транзакциями.
Вроде, все чудесно ;-) У нас есть API локальных транзакций источника, разработчик теперь может в своей бизнес-логике им пользоваться, тем самым обеспечивая целостность данных. Но с ростом сложности информационных систем возникает проблема - источников данных становится несколько, причем, зачастую, разных типов. В качестве примера можно рассмотреть работу гипотетической ИС по приему нового работника в штат компании: нужно данные о нем прописать во внутренней БД по учету персонала, во внешней БД головной компании, в PeopleSoft и 1С:Бухгалтерии (внешние КИС). При этом все изменения во всех хранилищах должны пройти целостно, т.е. если где-то в одном из них случилась ошибка, то нигде в остальных информация не должна появиться.
Вот пример глобальной транзакции - налицо все свойства локальной, но эта глобальная транзакция охватывает изменения на нескольких источниках данных.

Глобальные транзакции, 2PC
Теперь следует немного подняться с уровня API на уровень алгоритмов и задуматься, как технически реализовать идею глобальных транзакций. Что у нас есть, так это инструмент локальных транзакций, отлаженный, работающий, реализованный в большинстве RM.
Основная идея, используемая для реализации глобальных транзакций - это 2PC, 2 Phase Commit Protocol - протокол двухфазного подтверждения транзакций. Эта идея довольно проста: глобальная транзакция состоит из двух этапов (фаз): подготовка и завершение.
Давайте рассмотрим 2PC на примере чуть попозже, а пока рассмотрим простейшее решение. Итак, нам надо в рамках одной транзакции изменить данные в двух различных СУБД. Все, что у нас есть - это инструмент локальных транзакций каждой из них. Напрашивается то самое решение в лоб:

1. начало локальной транзакции на первом источнике (Тр1)
   
2. обновление данных на первом источнике
   
3. завершение Тр1
   
4. начало локальной транзакции на втором источнике (Тр2)
   
5. обновление данных на втором источнике
   
6. завершение Тр2

Так вот - это неправильное решение. Дело в том, что локальные Тр1 и Тр2 сами по себе целостны, но в совокупности целостности не обеспечивают. Представим, что первое обновление прошло удачно, а это значит, что Тр1 завершится подтверждением. А при втором обновлении может случиться ошибка (нет такой записи, дублицирование PK или что-то еще), что приведет к завершению Тр2 откатом. В итоге имеем нарушение целостности данных. Все плачут :-( А все потому, что до самой последней модификации мы не знаем, будут ли ошибки, поэтому смело подтверждать первую транзакцию не стоит, возможно, в конце все приведет к откату.

Правильным решением будет использование как раз того самого 2PC. Идея этого алгоритма заключается в том, что локальные транзакции не завершаются до тех пор, пока на всех источниках не пройдут обновления. Это позволяет всем локальным транзакциям завершится (хоть и чуть попозже) одинаково. Если все прошло нормально - то подтверждением, если хоть одно обновление прошло с ошибкой - то откатом. Схема получается следующая:

1. начало локальной транзакции на первом источнике (Тр1)
   
2. обновление данных на первом источнике
   
3. начало локальной транзакции на втором источнике (Тр2)
   
4. обновление данных на втором источнике
   
5. если ошибок нигде не было, то (а) подтверждение Тр1 и (б) подтверждение Тр2
   
6. если были ошибки, то (а) откат Тр1 и (б) откат Тр2
   

Соответственно, этапы 1-4 называются фазой подготовки, а этапы 5 и 6 - фазой завершения глобальной транзакции. В зависимости от наличия ошибок обновления глобальная транзакция, как и локальная, может завершиться подтверждением или откатом.

Эта идея 2PC может быть реализована на любой платформе и любыми средствами, главное, чтобы был работающий механизм локальных транзакций. Но тогда получается, что разработчик, желающий использовать распределенные транзакции, должен мучится и кодировать 2PC-алгоритм в своей бизнес-логике?
Не обязательно. Как раз для того, чтобы снять с прикладного разработчика задачу реализации в коде таких алгоритмов, существует класс программных продуктов - Transaction Monitors.

Transaction Monitor и JTA
TM (Transaction Manager или Transaction Monitor) - специальное ПО, которое берет на себя задачу реализации алгоритма 2PC, снимая её с прикладного разработчика. Существует множество реализаций от разных производителей, например Microsoft Transaction Server или BEA Tuxedo. Но в случае платформы j2ee не надо докупать отдельный продукт, TM является частью сервера приложений. Естественно, что реализации TM различных производителей j2ee-серверов различаются рядом характеристик, но мониторы всех серверов доступны прикладному разработчику через унифицированный API - JTA (Java Transaction API), регламентированный JSR-ом за номером 907.
При использовании TM в j2ee-сервере разработчику достаточно лишь посылать сигналы монитору о старте и подтверждении/откате глобальной транзакции, а сигналы локальных подтверждений/откатов монитор разошлет RM-ам самостоятельно.
Таким образом, бизнес-логика наших j2ee-приложений трансформируется (и вместо самостоятельной реализации 2PC доверяем это транзакционному монитору):

1. посылка сигнала TM о начале глобльной транзакции ГТр
   
2. обновление данных на первом источнике, обновление данных на втором источнике
   
3. если ошибок нигде не было, то подтверждение ГТр, если были ошибки, то откат ГТр
   
4. TM сам разошлет сигналы локальных подтверждений или откатов всем задействованным RM

рис. 7

Этапы 1, 2 - фаза подготовки; этапы 3, 4 - фаза завершения глобальной транзакции.

Что же из себя представляет Java Transaction API?
JTA представляет из себя набор классов исключений и интерфейсов, с помощью которых разработчик может управлять глобальными транзакциями:

рис. 8

Ключевым интерфейсом для прикладного разработчика является javax.transaction.UserTransaction. J2EE-сервер предоставляет разработчику объект, реализующий этот интерфейс, и с его помощью программист может управлять глобальными транзакциями. UserTransaction является, по сути, интерфейсом разработчика к TM и часто этот объект, предоставляемый контейнером, называют транзакционным контекстом, или просто UserTransaction - по имени интерфейса.
Давайте рассмотрим методы транзакционного контекста:

рис. 9

Методы его self-descriptive, я лишь приведу перевод выдержки из спецификации JTA:

• public void begin() throws NotSupportedException, SystemException
  Создает новую глобальную транзакцию и ассоциирует её с текущим потоком - тредом.
  
• public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, SecurityException, IllegalStateException, SystemException
  Завершает текущую транзакцию (ассоциированную с текущим потоком) подтверждением. После выполнения этого метода текущий поток более не ассоциирован ни с какой транзакцией.
• public int getStatus() throws SystemException
  Возвращает статус текущей транзакции. Специально для анализа статуса предназначен интерфейс javax.transaction.Status, у которого определено 10 констант с предопределенными именами статусов транзакции:
  
  
  рис. 10
  

  
  Подробное обсуждение статусов транзакции выходит за рамки данной статьи.
  
• public void rollback() throws IllegalStateException, SecurityException, SystemException
  Завершает текущую транзакцию откатом. После выполнения этого метода текущий поток более не ассоциирован ни с какой транзакцией.
• public void setRollbackOnly() throws IllegalStateException, SystemException
  Помечает текущую транзакцию таким образом, что она в дальнейшем может завершиться только откатом.
• public void setTransactionTimeout(int seconds) throws SystemException
  Устанавливает таймаут текущей транзакции. Если из приложения не вызывался этот метод, то таймаут устанавливается в значение по умолчанию (скорее всего, выставленное в конфигурации сервера).

Таким образом, получив транзакционный контекст, разработчик может пользоваться функционалом Transaction Monitor-а - начинать, подтверждать, откатывать глобальную транзакцию; метить её как подлежащую откату и получать её статус.

Здесь уместно отступление, связанное с неоднозначностью интерпретации спецификации. Дело в том, что спецификация регламентирует два интерфейсных к TM объекта: первый, реализующих уже знакомый нам интерфейс javax.transaction.UserTransaction и второй, реализующий javax.transaction.TransactionManager.
Как гласит спецификация, UserTransaction является интерфейсом к TM для разработчика, а TransactionManager является интерфейсом к TM для самого контейнера и его объектов (например, для EJBObject-ов - сгенерированных контейнером объектов-перехватчиков, стоящих перед EJB instances, экземплярами бинов).
Но спецификация не говорит о том, нужно ли делать доступным объект TransactionManager разработчику. Поэтому доступность TransactionManager-а разработчику определяет каждый производитель контейнера по-своему.
Интерфейс TransactionManager предоставляет более широкий API, нежели UserTransaction:

рис. 11

Как разработчик получает доступ к транзакционному контексту - UserTransaction?
Разработчик из своих приложений получает доступ к UserTransaction в зависимости от типа приложения:

• Удаленные клиенты - из сервиса именования (jndi-дерева)
• Веб-компоненты (сервлеты, jsp, ect.) - так же из из сервиса именования
  
• Session EJB - в зависимости от типа (BMT или CMT) и версии (2.x или 3)- из сервиса именования, из ejb-контекста или как dependency injection

На этом месте возникает резонный вопрос - а как разработчик узнает jndi-путь (имя контекста), по которому доступен UserTransaction? Дело в том, что спецификация JTA обязывает производителя сервера предоставить доступ разработчику к транзакционному контексту, но до определенной версии j2ee явно не регламентировала его jndi-адрес. Так что различные вендоры использовали различные пути, а в приведенном ниже примере (рис. 12 и 13) проиллюстрировано j2ee-приложение для BEA WebLogic 8, где имя контекста UserTransaction было javax.transaction.UserTransaction - по имени интерфейса.
В связи с этим были возможны проблемы с переносимостью приложений между j2ee-серверами (это не касается session ejb, где bmt-компонент получает транзакционный контекст из ejb context или как dependency injection; и не касается session cmt и entity ejb, где вообще нет процедурного доступа к транзакционному контексту, кроме метода setRollbackOnly).
Но на данный момент Sun Microsystems явно рекомендует вендорам следующий путь: java:comp/UserTransaction

Каркас приложения, использующего глобальные транзакции
Давайте вспомним сценарий работы приложения с глобальными транзакциями:

• посылка сигнала TM о начале глобльной транзакции ГТр
  
• обновление данных на первом источнике, обновление данных на втором источнике
  
• если ошибок нигде не было, то подтверждение ГТр, если были ошибки, то откат ГТр
  
• TM сам разошлет сигналы локальных подтверждений или откатов всем задействованным RM

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

рис. 12

• первый этап - получение транзакционного контекста из сервиса именования (jndi-дерева)
• второй этап - посылка сигнала о начале глобальной транзакции
• третий этап - посылка сигнала о подтверждении глобальной транзакции

Но это не полный пример, так как надо учитывать необходимость отката транзакции в случае ошибок (которые в нашем приложении проявятся как exceptions).

рис. 13

Изменения данных, охваченные транзакцией (begin/commit) на рис. 12 и 13, будут целостными - "все или ни одного". Таким образом разработчик через интерфейс к Transaction Monitor-у javax.transaction.UserTransaction способен управлять глобальными транзакциями.

Расширенные вопросы работы TM, XID, интерфейс XA
Как мы увидели, TM берет на себя целый спектр задач. Как же этот сервис контейнера реализует их? Ведь следует помнить, что сервисом пользуется одновременно множество j2ee-приложений, причем те же самые сервлеты, к тому же, выполняются в многопоточном режиме. Как же один и тот же TM понимает, на какие именно RM посылать сигналы завершения локальных транзакций, какие именно RM были вовлечены в текущую транзакцию, если этих транзакций в системе протекает множество, и каждая из них вовлекает различные TM?
Давайте взглянем на функционирование TM более подробно. При старте глобальной транзакции ей присваивается уникальный идентификатор - XID, и этот XID генерируется автоматически TM-ом. Как только бизнес-логика, выполняющаяся в рамках глобальной транзакции, модифицирует данные в каком-либо Resource Manager, TM автоматически связывает идентификатор локальной транзакции этого RM с идентификатором глобальной транзакции, XID-ом. Таким образом, TM постоянно ведет так называемый TLOG (transaction log), в котором меппятся XID-ы на идентификаторы локальных транзакций, которые охвачены этим XID.
Давайте более подробно рассмотрим этот процесс:

рис. 14

В рамках j2ee-контейнера выполняется бизнес-логика (метод сервлета, ejb или простого java-класса). Метод стартует глобальную транзакцию (этап 1), при этом TM-ом создается идентификатор транзакции - XID.
Далее из бизнес-логики происходит модификация данных через resource managers (этапы 2 и 3):

рис. 15

После этого в логике присходит анализ исключений, и в зависимости от их наличия глобальная транзакция завершается или подтверждением, или откатом (этап 4):

рис. 16

Далее на второй фазе (2PC) глобальной транзакции TM рассылает задействованным в ней RM-ам сигнал локального подтверждения или отката (этап 5):

рис. 17

В принципе, этот процесс мы рассмотрели в предыдущем разделе, и пришло время ответить на вопрос: каким же образом TM, которому поступает множество сигналов от различных приложений, знает, каким RM посылать сигналы и какие именно локальные транзакции этих RM завершать?
А все дело в волшебных пузырьках в том, что:

• Во-первых, XID привязывается к треду (см. так же пояснения к рис. 9). То есть, даже в случае веб-приложений, где метод одного сервлета может выполняться в многопоточном режиме, TM всегда четко знает, какой XID завершать, исходя из того треда, который вызывает метод rolback или commit.
  Так же привязка XID к треду дает чудесный эффект: мы мыжем иметь довольно глубокий стек вызовов, и все эти вызовы будут проходить в рамках одной и той же транзакции. То есть, можно в сервлете начать глобальную транзакцию, вызвать из него метод класса (POJO), затем метод ejb, затем модифицировать данные, и все эти изменения пройдут как одна транзакция. При этом тот ejb может так же вызывать другие ejb и методы POJO с тем же эффектом. XID привязывается к треду, поэтому куда бы тред ни зашел, вся эта логика выполнится как одна транзакция.
  
  
  рис. 18
  
  
• Во-вторых, TM ведет транзакционный лог (TLOG), где скурпулезно записывает для каждого XID в какой RM он вошел и идентификатор этой локальной транзакции.

рис. 19

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

Здесь следует сделать небольшое отступление по поводу идентификаторов локальных транзакций. Дело в том, что прикладной разработчик, работая с локальными транзакциями, по сути, не нуждается в их идентификаторах. Для него важно то, что транзакция привязывается к соединению (connection). Поэтому нужно, чтобы на второй фазе глобальной транзакции фабрика соединений RM-а выдала из пула то же самое соединение, что и на предыдущем этапе модификации данных. Соответственно, на этапе конфигурации фабрики необходимо указывать, что это фабрика, способная участвовать в глобальный транзакциях административными средствами сервера. Такая фабрика в том числе будет отвечать за выдачу одинаковых connections из пула в обеих фазах глобальной транзакции.

Интерфейс XA
Далее возникает следующая проблема. Не стоит забывать, что RM-ы могут быть разной природы, т.е. реализовывать различные интерфейсы: JDBC, JMS, J2CA и другие. Соответственно, на второй фазе глобальной транзакции, когда TM-у надо будет рассылать сигналы локальных завершений, ему надо будет это делать через специфичный для RM-а API (см. этап 5 на рис. 17). А это крайне серьезно усложняет TM, ведь популярных API RM-ов немало, и неизвестно, какие появятся в будешем. На выходе имеем излишнее усложнение и проблемы с поддержкой. Следовательно, необходимо абстрагировать TM от API RM-ов.
Как раз для этого в свое время был разработан интерфейс XA (eXtended Architecture). Его цель - обеспечить унифицированный, общий для всех типов RM интерфейс управления локальными транзакциями. При использовании XA-драйверов разработчик пользуется технологическим API (jms, jdbc), а TM пользуется интерфейсом XA.

рис. 20

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

1. Следует использовать XA-драйвера при настройке RM
   
2. В настройках фабрики соединений указывать, что она Global Transactional

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

Темы, не вошедшие в рассмотрение
Статья не может, к сожалению, охватить все аспекты, поэтому ряд тем не вошло в рассмотрение:

• История глобальных транзакций - OMG, X/OPEN, CORBA
• JTS
  
• Эмуляция XA в не-XA-драйверах
• Heuristics
• Distributed vs Global transactions
• Проблемы совместного использования локальных и глобальных транзакций

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

P.S. C первым снегом Вас, коллеги! )))

Доступ к внешним системам и механизм глобальных транзакций на платформе J2EE: часть 1

Disclaimer
Цель этой статьи - дать общее представление и систематизировать знания о процессах взаимодействия с внешними ресурсами и управления глобальными транзакциями из j2ee-приложений. Статья ориентирована на начинающих j2ee-разработчиков.
Более подробно эта и другие темы раскрываются в курсах по направлениям java и j2ee, проводимых на площадке Люксофта. Презентации курсов я выкладываю по адресу http://courses.4shared.com в разделе courses. В данной статье используются материалы курса по JDBC API.

Введение
В статье речь пойдет об одном из наиболее востребованных сервисов платформы j2ee - сервисе JTA (Java Transaction API). Сервисы платформы j2ee - это уже реализованный функционал, являющийся частью j2ee-контейнера. Задача j2ee-сервисов - снять с разработчика приложений инфраструктурные задачи с тем, чтобы он концентрировался только на реализации бизнес-логики.

Процесс взаимодействия с внешними ресурсами из j2ee-приложений
Большинство приложений так или иначе взаимодействуют с внешними системами для получения, обработки и сохранения данных. Наиболее распространенные типы внешних систем: СУБД, JMS, внешние корпоративные системы (КИС/EIS). Соответственно, для каждого из типов предусмотрен свой API доступа:

• для СУБД - JDBC API (Java Database Connectivity)
  
• для JMS - JMS API (Java Messaging Service)
  
• для EIS - J2CA API (Java2 Connector Architecture), циферка 2 добавлена, чтобы не было путаницы с JCA - Java Cryptography Architecture ;-)
  

Взаимодействовать с внешними системами из приложения можно напрямую или с использованием соответствующего сервиса.
Взаимодействие напрямую с внешней системой подразумевает работу с ней с использованием двухзвенной схемы клиент-сервер (приложение-клиент взаимодействует с внешней системой-сервером). при этом используется соответствующий API, в клиенте инкапсулируется информация о местоположении системы и учетная запись доступа.
Но есть более удобный способ - воспользоваться j2ee-сервисом доступа. Этот сервис - промежуточное звено между клиентом и внешней системой. Что же такого полезного реализует этот пресловутый сервис?

1. Сервис сам по себе доступен клиенту через тот же API, что и скрываемая за ним внешняя система.
   
2. Сервис настраивается администратором j2ee-сервера. Такое разделение ролей админа и разработчика позволит резко повысить поддерживаемость приложения: админ может изменять расположение внешней системы и учетную запись доступа к ней без модификации приложения.
3. Сервис обеспечивает пулирование соединений с внешней системой. Это значит, что сервис заранее открывает кучу соединений (т.н. пул соединений) с внешней системой. Теперь при использовании сервиса когда приложению понадобится соединение, то оно попросит соединение у нашего сервиса и получит уже открытое соединение, т.е. не будет тратить время на его установку.
   Почему это так важно и когда следует пользоваться сервисом в обязательном порядке: дело в том, что для stand-alone клиентов (которые на рабочих местах пользователей) время получение соединения не так критично. Тетя-бухгалтер щелкает кнопочку в своем fat-клиенте, при обработке нажатия она подождет пол-секунды и не расстроится ;-) Одна тетя - одно приложение.
   А вот если приложение работает на сервере, т.е. на него приходится множество жаждущих клиентов (много теть - один сервлет), то эти пол-секунды установки соединений выливаются в большие проблемы с нагрузочной масштабируемостью.

Резюмируя возможные комбинации вида "тип клиента - сервис доступа", можно нарисовать следующую картинку для любых технологий:

рис. 1

Небольшое терминологическое отступление: в общем случае промежуточные системы, через которые производится доступ к СУБД, называются DB middleware. Но т.к. мы говорим о платформе j2ee, то эту роль у нас будет играть jdbc-сервис.
Таким образом, предыдущая картинка с учетом специфики платформы j2ee будет выглядеть так:

рис. 2

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

Реализация сервисов доступа к внешним системам.
Как же устроены эти сервисы и как разработчику приложений работать с ними?
Технически сервис представляет из себя совокупность Resource Managers (RM) - менеджеров ресурсов. Настраивает эти менеджеры, как правило, администратор j2ee-сервера (есть еще вариант автоматической настройки при развертывании приложения, но это детали). RM представляет из себя совокупность следующих компонентов: пула соединений (connection pool) и фабрики соединений (connection factory).
Давайте рассмотрим роль и механизм настройки этих компонентов:

1. Пул соединений.
   Задача пула - минимизировать время получения соединения с внешней системой из приложений.
   Для этого контейнер заранее открывает несколько соединений (пул) и по требования приложения отдает уже открытое соединение. Приложение не тратит время на получение соединения.
   При этом пул, отдав соединение клиенту, помечает его как используемое и не будет выдавать его другим клиентам. Когда клиент закрывает соединение, оно не закрывается физически, а всего лишь помечается как вновь свободное.
   
   Вопрос 1: как этого можно добиться? Как можно перехватить метод закрытия соединения, чтобы оно не закрывалось, а помечалось как свободное?
   Какие настройки необходимы? Пул выступает непосредственным клиентом для СУБД, поэтому его необходимые настройки аналогичны настройке простого клиента для СУБД: местоположение СУБД (т.н. JDBC-URL или DB-URL) и учетная запись, под которой пул аутентифицируется перед СУБД (так же есть возможность указывать учетную запись непосредственно при получении соединения из приложения).
   Так же необходимо указать используемый класс jdbc-драйвера, тем самым, по сути, определив тип используемой СУБД.
   Какие настройки достаточны?
   Помимо необходимых настроек, различные производители контейнеров или разработчики классов пулов предлагают так же возможность тонкого тюнинга пула: начальный и максимальный размер пула; таймауты на получение и удержание соединения; connection leak detection и многое другое.
   
   
   рис. 3
   
   
2. Фабрика соединений.
   Клиент не работает с пулом напрямую. Для получения соединений он использует фабрику.
   
   Фабрика (Factory) - очень популярный шаблон проектирования (design pattern). Используется в тех случаях, когда необходимо инкапсулировать логику создания/получения некоторого объекта или их группы.
   Задача фабрики - скрыть сложность и обеспечить клиентам единую точку получения соединений. Классы пула и фабрики являются частью контейнера (или внешним продуктом, что реже). Поэтому администратору при создании RM достаточно только настроить пул и фабрику.
   Т.к. одной из задач фабрики является обеспечение единой точки получения соединений, возникает вопрос: где клиент найдет фабрику? Специально для этих целей j2ee-контейнер предлагает сервис именования, доступный через JNDI API.
   
   Сервис именования - один из предоставляемых j2ee-контейнером сервисов. Он предназначен для хранения объектов, необходимых приложениям. К этим объектам можно отнести фабрики соединений и EJB. Хранение объектов в сервисе именования организовано в виде дерева, поэтому приложению необходимо знать путь (aka jndi-name) нужного объекта в дереве. Так же сервис именования часто называют jndi-сервисом, jndi-деревом.
   Поэтому клиенту необходимо сначала получить фабрику из сервиса именования, а затем получить у неё соединение с внешним ресурсом.
   
   
   рис. 4
   
   
   
   Какие настройки необходимы? Администратор, настраивая фабрику, дожен указать пул, поверх которого устанавливается фабрика, и jndi-имя этой фабрики, по которому её будут искать приложения.
   Еще одна важная задача фабрики - обеспечить измененное поведение соединений.
   На самом деле фабрика выдает не native jdbc connection, класс которых настраивается в пуле, а класс-обертку. Так сделано, чтобы изолировать клиента от типа СУБД и модифицировать поведение соединений. Например, клиентский вызов метода закрытия соединения не должен приводить к закрытию, а только к пометке соединения как вновь свободного (см. Вопрос 1). Еще один пример необходимости модифицированного поведения будет рассмотрен позже при обсуждении эмуляции интерфейса XA в драйверах, его не поддерживающих.
   
   Приняты следующие названия фабрик соединений для различных типов ресурсов:
   
   • JDBC - DataSource
   • JMS - JMS Connection Factory
   • J2CA - J2CA Connection Factory
     

Резюме
Резюмируя, можно нарисовать следующие схемы работы приложения с RM:

рис. 5

рис. 6

Что дальше?
Во второй части статьи будут рассмотрены: механизм глобальных транзакций, интерфейс XA, JTA API.

PS Любые вопросы и предложения приветствуются ;-)

Обзор платформы JavaEE 5

На сайте IBM появилась неплохая статья - обзор платформы JavaEE 5. Все сжато и обзорно.
Статья здесь.

Ухудшается ситуация с безопасностью Java-приложений

Натолкнулся на статью по поводу текущей ситуации с безопасностью j2ee веб-приложений в еженедельнике PC Week.
Прискорбно ((
Надо быть более внимательными.

Судьба девелопера: куда податься дальше?

Недавно с одним товарищем полемизировали на эту тему. Действительно, многие ребята всерьез озадачены вопросом дальнейшего роста. Куда двигаться? Любое движение, за редким исключением (когда это пинок ;-) - результат продуманной политики, и главное в этом движении - внятно сформулированная цель.
Какие пути развития видятся experienced-разработчикам? На основе моей репрезентативной выборки (знакомые) можно отметить следующие варианты развития:

• в техническую сторону - гуру/архитектор/lead
• в сторону управления - project manager
• в сторону консалтинга - преподаватель/инструктор/пре-сейл (pre-sale)
  
• "между право и лево выбираем вверх" - собственное дело

Каждый из вариантов имеет свою специфику и зачастую требует развития абсолютно несвязанных знаний и навыков.

Хороший технический специалист: гуру/архитектор/lead.
Что ждет? Высококвалифицированные спецы всегда нужны. Особенно это ощущается сейчас, когда хедхантеры готовы на многое, чтобы найти таких людей. Что поделать - кадровый голод )))
В перспективе гуру ждет участие в сложных проектах на уровне технического архитектора, и чем выше квалификация, тем сложнее и масштабнее проекты. В идеальном будущем - позиция вида "главный дядька по архитектуре решений" в какой-нибудь мега-крупной конторе ))
В реальности же все гораздо более прозаично и совсем немного ребят доходят до таких позиций, именно технических, чаще всего сворачивают. Основная проблема - финансовые амбиции. Обидно, когда ты такой умный, а за стенкой сидит паренек, который (страшно сказать!!!) не знает, что такое SAML для веб-сервисов, и получает больше тебя... А паренек занимается не технической стороной дела, а организационной - он PM. Или директор по развитию бизнеса. Или сами-посмотрите-на- табличку-на-двери-того- самого-упыря-достал-уже )))
Потому многие (амбициозные особенно) сворачивают в сторону управления.
Что необходимо? Если у Вас есть абсолютно четкое понимание:

1. Того, что Вам нравится именно технологическая сторона, что Вы - технарь (в самом лучшем и гордом смысле этого слова, а не какое-то там офисное чмо ;-)
2. Того, что Ваша компания позволит Вам расти в этом направлении. (Или Вас зовут в компанию, где в этом плане все будет хорошо ;-)

надо планомерно прокачивать скиллы.
Здесь так же есть пара нюансов. Можно стать отличным специалистом широкого профиля - эдаким техническим архитектором по платформе или по решениям. Например, по "платформе J2EE" или по "портальным решениям". С другой стороны, можно стать гуру по определенному продукту - например, по конкретной софтине BEA WebLogic 9.2.
Оба подхода, конечно, крайности - сложно быть спецом по платформе, не имея опыта на конкретном сервере и, наоборот - быть специалистом по конкретному серверу, не имея представления о платформе. Но задуматься о направлении, о доминанте, конечно, стоит. Эти спецы по-разному востребованы работодателями.
И еще одна важная деталь - сертификация. Сертифицироваться надо, это очень сильно облегчит общение как с текущим, так и с будущим работодателем )
Кому подойдет? Настоящим технарям, любящим свое дело и сложные задачи, не потерявшим интерес к развитию скиллов. Но важно уметь оценивать свои амбиции и уметь сворачивать вовремя )

Управляющий процессами разработки - Project Manager/Program Manager.
Что ждет? PM-ы - достаточно востребованные люди, hh.ru подтвердит ) Из несомненных плюсов - то, что они могут отностительно свободно сменить предметную область без смены скиллов. Это позволит начать карьеру PM в конторе "на-троих.ру", и в будущем оказаться в компании "Мега-Корп.ком".
Конечно же, все очень сильно зависит текущей ситуации: и проект может оказаться провальным, и все что угодно. И компенсация у PM зачастую скромная, тот же hh.ru подтвердит. Но, в целом, направление развития достаточно перспективное.
Отдельно стоит упомянуть сертификацию - она достаточно сложная и длительная по сравнению с техническими сертификациями. Но прохождение её, на мой взгляд, крайне полезно.
Что необходимо? Умение соображать быстро и верно ) Умение управлять людьми и общаться с ними. Деловая хватка.
Умение ждать ) Вовсе не следует ожидать сразу огромных компенсаций.
Кому подойдет? Эти умения и навыки приходят с опытом, но, тем не менее, некоторая предрасположенность к такого рода деятельности должна быть изначально. Далеко не все имеют способности к грамотному управлению людьми, деловому общению и способности к принятию решений.

Несущий свет - консультант/преподаватель/инструктор/пре-сейл )
Что ждет? Инструкторы и преподаватели - не такая частая вакансия на сайтах кадровых агенств, но это отнюдь не значит, что это бесперспективняк )
Я не имею в виду институтских преподов. Это люди, работающие в учебных центрах (как самостоятельных, так и подразделениях материнских компаний) и не имеющие ничего общего с большинством тех самых институтских преподов )
Задача инструктора - внятно донести содержание курса. Курсы по IT-направлениям, как правило стандартные, то есть уже написанные. И инструктор, пользуясь этими материалами, ведет группу на протяжении всего курса, "читает" курс. Длительность курсов различна - от одного до пяти полных (восьмичасовых) дней, иногда - дольше.
Из минусов работы инструктором можно отметить:

• Высокая физическая нагрузка. Внятно, четко и громко говорить пять восьмичасовых дней - далеко не каждый сдюжит.
• Высокая эмоциональная нагрузка. Группы бывают ой какие разные )))
• Высокие требования к инструктору: умение внятно объяснять плюс отличная техническая подготовка. И если со вторым не так все плохо, то с первым - беда, таких людей совсем немного.
• Если УЦ проводит неграмотную кадровую политику, не давая развиваться инструктору, то рано или поздно ему надоест читать одни и те же курсы.
  

Из плюсов же можно отметить:

• Востребованность. Как было сказано выше, вакансии на инструкторов не так часто появляются на сайтах кадровых агенств, но в Учебных Центрах их очень ждут )
• Как следствие - достойные компенсации, по сравнению с теми же разработчиками.
• Можно не работать на УЦ, а быть фрилансером, то есть работать на себя. У этого подхода есть как положительные стороны, так и отрицательные. Если кому будет интересно - пишите, расскажу подробнее, это обсуждение несколько выходит за рамки формата.
• Инструктор - работа интересная. По сравнению с другими направлениями: гораздо меньше рутины, есть возможность заниматься самыми свежими технологиями, общение со слушателями (как правило, хорошими специалистами, хотя как повезет ;-) приносит множество полезной информации.
  

Консультанты и пре-сейлы решают несколько другую задачу. Они не читают стандартные вендорские курсы, а решают проблемы клиентов за счет своей квалификации.
Консультант, как правило, наемный работник, хотя встречаются и фрилансеры. Компания-заказчик арендует консультанта под какой-либо проект, где он рассказыает, "как надо" )))
Пре-сейл обеспечивает техническую подготовку покупки ПО или решения. Сейлы решают организационные и финансовые вопросы, а технический пре-сейл общается с техническими специалистами покупателя и отвечает на все их вопросы. Типа, "а эта ваша софтина как на кластер развернется?", "скока железа покупать, в натуре?" или "а что будет, если ..." ) Так же в задачи пре-сейлов часто входит разработка пилотного проекта, то есть покодить тоже будет возможность.
Из минусов работы консультантом/пре-сейлом можно отметить жесточайшую дисциплину, повышенную ответственность и высочайшие требования к квалификации. Из плюсов - соответствующая компенсация )) Как правило, достойная. Возможность (и обязанность ;-) постоянно расти в профессиональном плане, невысокий уровень рутины.
Что необходимо? Все эти направления объединяют:

• Повышенные требования к квалификации
• Умение и желание общаться с людьми, внятно и четко излагать мысли
• Высокие уровни компенсации
  

Кому подойдет? Всем тем, кто гармонично сочетает в себе технаря и оратора )))

Собственное дело
Как ни удивительно, но достаточно много ребят задумывались или задумываются о каком-либо своем начинании. В силу специфики их текущей работы, это как правило, мысли об e-business. Я это связываю с наличием удивительных success stories, тех же Google или YouTube.
Тема эта очень серьезная и требует отдельного размышления. Так что постараюсь как нибудь их собрать и совместно выработать идеи и рекомендации. Возможно, попробуем написать совместную статью.

Мораль
Многие со мной не согласятся по многим пунктам, но я и не претендую )
Все вышеизложенное - лишь повод задуматься. И чем раньше это произойдет, чем более проактивными будут наши ребята, тем быстрее наступит "щастье" )))
Всех благ!

Отступления:

1. Статья не претендует на истину в последней инстанции. Она основывается на персональной репрезентативной выборке. Мнение читателя не обязано совпадать с мнением автора. Конструктивная полемика приветствуется.
2. В силу специфики блога (Java/J2EE) чаще всего имеется в виду работник, связанный именно с этим направлением.
   
3. Многие неглупые люди (например, М.Фаулер) обозначают определенный негатив к термину "архитектор" из-за его неоднозначности. Я с ними солидарен )) Выше я употреблял этот термин с уточнением "технический" и лишь потому, что этот термин потребовал бы слишком объемной и выходящей за рамки формата расшифровки.
4. "Между право или лево выбирает вверх" - © Гражданская Оборона.
   

Технология JMX

Как и обещал, взялся за статью "JMX за 5 минут". Решил посмотреть, что уже написано по этому поводу на русском.
Нашел неплохие статьи:
статья1
статья2
Опрошу заинтересованных знакомых, если их не устроят эти материалы, напишу свою )))

Статьи по J2EE

Один коллега недавно спрашивал меня по поводу того, где можно почитать (желательно в реферативном, сжатом виде) введение в одну из спецификаций.
Я с удивлением обнаружил, что далеко не все разработчики знают, что на сайте ibm есть куча статей и туториалов на русском языке.
Коллеги, имеет смысл заглянуть сюда: http://www-128.ibm.com/developerworks/ru/views/websphere/libraryview.jsp )))
Статьи далеко не всегда адекватно переведены, зачастую грешат поверхностностью. И, естесственно, что ibm продвигает свои продукты )))
Но, в целом, ознакомиться стоит.

Серия статей

По многочисленным просьбам потихоньку начнаю цикл статей с рабочим названием "За 5 минут". В этом цикле постараюсь сделать краткие обозрения различных java-технологий. Человеческим языком ))
В ближайшее время выложу статью по JMX.

Проектирование ПО мертво?

Все тот же омский коллега порекомендовал статью гуру Мартина Фаулера.
Ссылка на русский перевод: http://www.maxkir.com/sd/designDead_RUS.html