Продаю HTC 3300

Продаю HTC 3300, годик от роду, состояние идельное, полный комплект, все в упаковке со дня покупки. Гарантийник открыт (не стоит дата продажи, т.е. можно вписать любую). Царапин на экране нет, пользовался защитной пленкой. В комплекте 1Гб карта памяти, поясной чехол.
Цена вопроса - 13000 руб часик ;-)
Продаю в связи с подарком мне другого, более продвинутого девайса.

Мероприятие Google Code Day 2007

Google проведет мероприятие для разработчиков в Москве 19 декабря.
Подробности на http://googlerussiablog.blogspot.com/2007/12/google-code-2007_13.html

Спасибо Якову Сироткину за информацию.

Опросы на конференции JavaPolis'2007

На прошедшей конференции JavaPolis проходили опросы посетителей на различные темы, в т.ч.:

• Meetups
• Java 7
• Enterprise
• User groups
• Tools
• Problems
• Статистика использования App servers & Web frameworks
• Closures and Nulls
• Language change

Фотографии результатов (sic!) доступны по адресу http://www.javapolis.com/confluence/display/JP07/Whiteboard+results

Свел результаты в графики:

Популярность серверов приложений:

Популярность веб-каркасов:

Спасибо Роману Д. за ссылочку.

Материалы конференции ApacheCon'2007

Доступны по адресу: http://www.us.apachecon.com/us2007/program/downloads

Security Alert: Многочисленные уязвимости в IBM WebSphere MQ

Многочисленные уязвимости в IBM WebSphere MQ
http://securityvulns.ru/news/IBM/WebSphereMQ/MB.html
Опубликовано: 14 ноября 2007 г.
Источник: BUGTRAQ
Тип: удаленная
Опасность: 5
Продукты: IBM: WebSphere MQ 6.0
Документы: IRM Research, Six Remote Memory Corruption Vulnerabilities in IBM WebSphere MQ 6.0 (http://securityvulns.ru/Sdocument418.html)
Обсудить: http://securityvulns.ru/board8346.html

Источник: security.nnov.ru

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 стать доминирующей архитектурой разработки КИС уже сегодня.

Семинар "Инженерные практики Agile: Knowledge Transfer with Scrum (CLOUD, Deutsch Bank)"

15 ноя	Семинар "Инженерные практики Agile: Knowledge Transfer with Scrum (CLOUD, Deutsch Bank)" Luxoft, 15 Ноября 2007 в 19:00:01 (Москва, Россия)

Тестер от Whizlabs для экзамена SJCP5

Программа-симулятор экзамена Sun Java 5 Certified Programmer.
Спасибо огромное Роману Д. за subj.

Выложил на courses.4shared.com в раздел exams/sun/scjp.

Web 3.0

Как показал мини-опрос, большей части участвовавших интересно, все-таки who is mr. Putin Web 3.0 ;-)
Как обычно, википедиа нам поможет: http://ru.wikipedia.org/w/index.php?title=Web_3.0&redirect=no

Бесплатный семинар Альтернативные системы поддержки процесса разработки ПО

22 ноя	Альтернативные системы поддержки процесса разработки ПО Luxoft, 22 Ноября 2007 в 18:00:01 (Москва, Россия)

Встреча Java User Group в Петербурге

24 ноября(суббота) в 16 часов в Петербурге состоится очередная встреча JUG.

Доклады:
1. Константин Андрюнин, http://ymik.moikrug.ru/, Проблема взрывного роста аудитории: что делать, когда не хватает мощностей?
2. Олег Оболенский, http://highpower.moikrug.ru/, Архитектура непоискового кластера Яндекса.

Место проведения: большой конференц-зал бизнес-центра "Воронцов" http://www.bc-vorontsov.ru/kontakt.bc, ул. Барочная, д. 10.
Вход через дверь с вывеской "Катарсис", конференц-зал находится слева от входа.

Для регистрации пришлите свою фамилию и имя на русском языке на yashaATtelamon.ru. Регистрация мягкая, достаточно просто послать письмо, подтверждения не высылаются.

После официальной части планируется совместное посещение бара для неформального общения.

Бесплатный семинар "Обеспечение эффективной разработки ПО с использованием интегрированной платформы IBM Rational"

Наконец-то они определились с датами: семинар пройдет 27 ноября в Москве и 15 ноября в Питере.
Более подробная информация и регистрация: http://www.interface.ru/home.asp?artId=7496

BEA не продается! Задешево )

В минувшее воскресенье истек срок предложения о покупке компании BEA Systems корпорацией Oracle.
Oracle готова была заплатить за каждую акцию BEA Systems 17 долларов. Таким образом, общая сумма сделки могла составить 6,7 миллиарда долларов США. Однако совет директоров BEA Systems счел эту сумму недостаточной, изъявив желание получить по 21 доллару за акцию (8,2 миллиарда долларов США в общей сложности).
В Oracle офигели и отказались )
Пока... )

Источник: http://business.compulenta.ru/337403/

Программы-симуляторы экзаменов SUN

По многочисленным просьбам выложил на 4shared в раздел exams/sun.
Там симуляторы к SCBCD, SCEA, SCJP, SCWCD.

Семинар по нагрузочному тестированию

29 окт	Семинар по нагрузочному тестированию в Люксофт Офис Люксофт, 29 Октября 2007 в 17:00:01 (Москва, Россия)

Подготовка к экзамену SCWCD 1.3 и 1.4

Выложил информацию на courses.4shared.com в разделе exams/sun/SCWCD

IBM HelloWorld Tutorials

На сайте IBM developerWorks есть набор tutorials для начинающих по различным java-технологиям. По заявлению IBM, основная их задача - сэкономить время разработчику при освоении java-технологий с использованием инструментария от IBM.
Эти tutorials в основном иллюстрируют работу с IBM-овскими инструментами. Что неудивительно ;-)
Почитать их можно здесь: http://www.ibm.com/developerworks/offers/lp/helloworld/

Мастер-класс "Веб-моделирование"

Под эгидой Samsung один из ведущих дизайнеров Лебедева проведет subj.
Программа мастер-класса:

• О чем не говорят в учебниках
• Основы: HTML, CSS, JavaScript
• От HTML к XHTML
• Основы семантической верстки
• Примеры плохого и хорошего кода
• «Резка» макетов: на что нужно обращать внимание
• Думаем о пользователях: как сделать, чтобы вашим сайтом было удобно пользоваться
• JavaScript:
• Основы анимации
• Краткий обзор фреймворков
• Примеры кода
• Способы оптимизации сайта
• Краткий обзор инструментария веб-разработчика

Подробности на http://www.samsung.ru/club/events/event229.html

Небольшой offtopic

Только что дочитал чудную книгу "Как зовут вашего бога? Великие аферы XX века." Сергея Голубицкого. Мне этот автор нравится еще со времен моего первого знакомства с еженедельником "Компьютерра".
Книга хорошая. До объективной оценки "отлично" может не дотянуть у многих читателей из-за специфической манеры повествования автора - она или жутко нравится, или нет ;-)
Если Вы интересуетесь хитроумными финансовыми схемами, их историческими подоплёками, далеко нетривиальными персонажами и их психологией, книга должна понравится. Не уверен, что она понравится законченным "технарям", уж больно красочно и витеивато зачастую выражается автор, да и схем с графиками маловато.
Будете в книжном - полистайте, во всяком случае, 5 мин сразу покажут, стоит её брать или нет.

	Сергей Голубицкий Как зовут вашего бога? Великие аферы XX века. Том 1
	Сергей Голубицкий Как зовут вашего бога? Великие аферы XX века. Том 2

ВКШ Эксперт

For Your Information
Скоро стартует очередной семестр, и ваш покорный слуга в нем будет участвовать ;-)

Высшая Компьютерная Школа "Эксперт" (ВКШ "Эксперт") создана факультетом ВМиК МГУ им. Ломоносова в сотрудничестве с учебным центром "Сетевая Академия ЛАНИТ". Наша цель - подготовка высокопрофессиональных кадров для ИТ-сообщества, обладающих фундаментальными теоретическими знаниями и востребованными практическими навыками.

http://www.hcse.ru

Возможно, для тех, кто пытается совместить учёбу в ВУЗе и работу, этот проект будет интересен.

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

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

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

Securuty alert: Выход за пределы каталога через WebDav в Apache Tomcat (directory

http://securityvulns.ru/news/Apache/Tomcat/Webdav-DT.html
Опубликовано: 15 октября 2007 г..
Источник: BUGTRAQ
Тип: удаленная
Опасность: 6
Описание: Возможно получение файлов по абсолютному пути через DAV-запрос LOCK.
Документы: SECURITEAM: [EXPL] Apache Tomcat File Disclosure (Exploit)
http://securityvulns.ru/Sdocument198.html
Файлы: Apache Tomcat Remote File Disclosure Zeroday Xploit
http://securityvulns.ru/files/TOMCATXPL.pl
Обсудить: http://securityvulns.ru/board8260.html

Источник: security.nnov.ru

Курсы под эгидой Sun (по Java, UML и не только)

Наткнулся на материалы курсов, возможно, кому-нибудь будет полезно: Академические программы Sun Microsystems

Мероприятие Srum-тематики

17 окт	Agile Estimation - Mike Vizdos Luxoft, 17 Октября 2007 в 10:00:01 (Москва, Россия)

Доступ к внешним системам и механизм глобальных транзакций на платформе 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 первым снегом Вас, коллеги! )))

Семинары на выставке Softool-2007

В рамках выставки Softool 2007 мы провели целый ряд семинаров, в том числе и по моей тематике.
Выкладываю презентации новых докладов (тех, что еще не были выложены на courses.4shared.com до этого).

J2EE Core Design Patterns: Dispatcher View

Outline карты:

==========================================
Dispatcher View
==========================================

-------------------------------------------------------------
1 Паттерн Dispatcher View [Core J2EE], как и паттерн Service to Worker [Core J2EE], описывает комбинацию других паттернов
каталога CoreJ2EE: Front Controller и View Helper.
Оба этих макро-паттерна описывают различные комбинации контроллера и диспетчера с представлениями и хелперами.
-------------------------------------------------------------

-------------------------------------------------------------
2 Ситуация
-------------------------------------------------------------

2.1 Система контролирует поток выполнения (application workflow или webflow) и доступ к бизнес-данным, из которых создается контент представления.

-------------------------------------------------------------
3 Задача
-------------------------------------------------------------

3.1 Задачи, решаемые шаблоном Dispatcher View - это совокупность задач, решаемых шаблонами Dispatcher и View Helper

3.2 Введение централизованного компонента

3.2.1 для управления контролем доступа

3.2.2 для извлечения данных

3.2.3 для управления представлениями

3.3 Вынос бизнес-логики из представлений

3.4 Разделение бизнес-логики и логики управления представлениями (структурной логики)

-------------------------------------------------------------
4 Требования
-------------------------------------------------------------

4.1 Необходимо, чтобы проверки безопасности выполнялись для каждого запроса

4.2 Код скриптлетов в представлениях должен быть минимизирован

4.3 Бизнес-логика должна быть инкапсулирована не в представлениях

4.4 Логика управления представлениями относительно простая

4.4.1 основывается на значениях, инкапулированных в запросы

-------------------------------------------------------------
5 Результаты
-------------------------------------------------------------

5.1 Централизация управления, улучшение модульности и возможностей повторного использования

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

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

5.2 Улучшение разделения ролей

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

-------------------------------------------------------------
6 Связанные шаблоны
-------------------------------------------------------------

6.1 Front Controller и View Helper [Core J2EE]

6.1.1 Паттерн Service to Worker является результатом комбинации паттернов View Helper [Core J2EE] и Front Controller [Core J2EE]

6.2 Service To Worker [Core J2EE]

6.2.1 Паттерн Service to Worker является комбинацией паттерна Front Controller с диспетчером и паттерном View Helper. Паттерны Service to Worker и Dispatcher View идентичны относительно включенных в них компонентов, однако отличаются разделением задач между ними. Паттерн Dispatcher View предоставляет отсрочку получения данных до этапа отработки представления. Кроме этого, в управлении представлениями диспетчер выполняет более ограниченную роль, так как выбор представления обычно уже включен в запрос.

Сводка J2EE-серверов

Часто возникают вопросы по поводу хотя бы примерных цен на J2EE-сервера.
На TheServerSide.com нашел чудную табличку со сводкой J2EE-серверов, в т.ч. и по ценам:
http://www.theserverside.com/tt/articles/article.tss?l=ServerMatrix.

Enjoy )

Календарь интересных IT-мероприятий

Решил теперь все предстоящие мероприятия для удобства регистрировать в открытом календаре:

J2EE Core Design Patterns: Service To Worker

Outline карты:
-------------------------------------------------------------
1 Паттерн Service to Worker [CoreJ2EE], как и паттерн Dispatcher View [CoreJ2EE], описывает комбинацию других паттернов
каталога CoreJ2EE: Front Controller и View Helper.
Оба этих макро-паттерна описывают различные комбинации контроллера и диспетчера с представлениями и хелперами.
-------------------------------------------------------------

-------------------------------------------------------------
2 Ситуация
-------------------------------------------------------------

2.1 Система контролирует поток выполнения (application workflow или webflow) и доступ к бизнес-данным, из которых создается контент представления.

-------------------------------------------------------------
3 Задача
-------------------------------------------------------------

3.1 Задачи, решаемые шаблоном Service To Worker - это совокупность задач, решаемых шаблонами Dispatcher и View Helper

3.2 Введение централизованного компонента

3.2.1 для управления контролем доступа

3.2.2 для извлечения данных

3.2.3 для управления представлениями

3.3 Вынос бизнес-логики из представлений

3.4 Разделение бизнес-логики и логики управления представлениями (структурной логики)

-------------------------------------------------------------
4 Требования
-------------------------------------------------------------

4.1 Необходимо, чтобы проверки безопасности выполнялись для каждого запроса

4.2 Код скриптлетов в представлениях должен быть минимизирован

4.3 Бизнес-логика должна быть инкапсулирована не в представлениях

4.4 Бизнес-логика может быть относительно сложной, она основывается на значениях, полученных в run-time

4.5 Логика управления представлениями может быть относительно сложной, с множеством представлений, потенциально отображаемых при одном и том же запросе

-------------------------------------------------------------
5 Результаты
-------------------------------------------------------------

5.1 Централизация управления, улучшение модульности и возможностей повторного использования

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

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

5.2 Улучшение разделения ролей

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

-------------------------------------------------------------
6 Связанные шаблоны
-------------------------------------------------------------

6.1 Front Controller и View Helper [Core J2EE]

6.1.1 Паттерн Service to Worker является результатом комбинации паттернов View Helper [Core J2EE] и Front Controller [Core J2EE]

6.2 Dispatcher View [Core J2EE]

6.2.1 Паттерн Service to Worker является комбинацией паттерна Front Controller с диспетчером и паттерном View Helper. Паттерны Service to Worker и Dispatcher View идентичны относительно включенных в них компонентов, однако отличаются разделением задач между ними. Паттерн Dispatcher View предоставляет отсрочку получения данных до этапа отработки представления. Кроме этого, в управлении представлениями диспетчер выполняет более ограниченную роль, так как выбор представления обычно уже включен в запрос.

Русскоязычные курсы по java- и j2ee-направлениям

Еще раз напоминаю, что курсы перенесены с rapidshare на ресурс courses.4shared.com.

• раздел courses - курсы по java и j2ee
• подраздел SJ5CP - материалы для подготовки к экзамену Sun Java5 Certified Programmer Exam, включены отличная книга и программа-симулятор экзамена
  
• раздел books - книги
• раздел j2ee_patterns - русскоязычные описания шаблонов проектирования (design patterns) Core J2EE Patterns в виде карт памяти, mind maps
  
• раздел job_interviews - дока по вопросам на собеседованиях по java и j2ee, представляет из себя шпаргалку, сжатое описание большинства необходимых технологий
• раздел papers - white papers и всяческие пресс-релизы с обзорами
• раздел seminars - презентации семинаров по java и j2ee, проводимых у нас в компании

Apple Party в клубе Cisterna

В программе будут:

• розыгрышы MacBook и всей линейки iPod
• крутые конкурсы, типа "убей новую макось до кернел паник за 60 секунд"
• конкурс на самую смешную фотку в PhotoBooth по пьяни
  
• и конкурс на лучшую мелодию, написанную в Garage Band левой пяткой с завязанными глазами :)
• так же у нас будет стоять фотограф и фотографировать девушек на обложку нового номера журнала Мак.ру

С 21:00 будет играть DJ Чирков совместно со скрипкой.
Клуб находится на м. Проспект мира, адрес - Проспект Мира, д. 26, стр. 1
Вход бесплатный.

Подробности: http://quipkoren.livejournal.com/512037.html

Форум IT-Лидер 2007

«Информационные технологии как инструмент реинжиниринга бизнес-процессов»

17 октября 2007 года, Московский Международный Дом Музыки

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

Обсуждение тем Форума пройдет в формате открытой дискуссии при телевизионной поддержке делового канала РБК-ТВ. Основными спикерами станут зарубежные аналитики и практики в области информационных технологий, а также CIO крупнейших организаций России. Каждое обсуждение будет предваряться серией десятиминутных видеопрезентаций о практическом опыте ключевых спикеров, после чего участники мероприятия смогут обсудить все затронутые вопросы.

Организационную поддержку мероприятия осуществляют Ассоциация Менеджеров России, журналы CIO, Intelligent Enterprise и компания КРОК. Генеральный информационный партнер Форума – группа компаний РосБизнесКонсалтинг. Информационный партнер – информационное агентство “Алгоритм”. Генеральный спонсор – EMC. Cпонсоры - HP, Avaya, Nortel.

Участие в Форуме бесплатное.

Более подробно можно узнать по адресу http://www.itleader.ru/forum_2007.shtml