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 предоставляет отсрочку получения данных до этапа отработки представления. Кроме этого, в управлении представлениями диспетчер выполняет более ограниченную роль, так как выбор представления обычно уже включен в запрос.