Логическое обоснование проекта

Основная обязанность компонента технологического управления — обеспечивать для клиента возможность моделирования технологического процесса и переноса через него цифровых артефактов. Кроме того, компонент позволяет клиентам определять ресурсы и распределять их между операциями технологического про­цесса. Естественно, от компонента требуется возможность повторного использо­вания и расширяемость, а значит, он должен предоставлять общие возможности технологического процесса; предусматривать четкую и универсальную модель функционирования обращающихся к нему приложений; быть невосприимчивым к цифровым артефактам, проходящим через те или иные вариации технологиче­ского процесса. Для создания полнофункционального компонента технологиче­ского процесса требуются сложные идиомы — в частности, ветвление, слияние и зацикливание. Как правило, для реализации возможности технологического уп­равления требуются недюжинные ресурсы.

Компания Inmedius неожиданно столкнулась с непредвиденной трудностью. Приложения, разрабатываемые в рамках Luther, явственно демонстрировали се­рьезную потребность в возможностях технологического управления, однако их комплексной реализации препятствовали следующие факторы:

♦ размер и сложность комплексного технологического управления выходили за рамки имевшихся у компании ресурсов;

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

♦ значительно более комплексные решения были уже созданы другими ком­паниями.

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

Таким образом, стратегия заключалась в том, чтобы спроектировать компо­нент, который впоследствии можно было бы без труда заменить более комплекс­ным компонентом от сторонней компании. Отсюда сформировалась потребность в стандартном интерфейсе компонента технологического управления. Обратите внимание на то, как в данном случае ведет себя архитектурно-экономический цикл. Проект архитектуры Luther способствовало открытию новой коммерчес­кой перспективы (связанной с технологическим управлением), что побудило ком­панию принять явное решение о вхождении или, вернее, отказе от вхождения на данный сегмент рынка. Руководство Inmedius решило, что рассматриваемая об­ласть выходит за рамки базовой компетенции компании.

Группой по технологическому управлению (Workflow Management Coalition) был разработан ряд спецификаций функций и поведения, связанных с техноло­гическим управлением, который впоследствии был признан сообществом. При построении компонентов архитекторы Inmedius исходили из этих спецификаций, однако реализовывали только ту функциональность, которая была необходима для разрабатываемых приложений.

Принятая стратегия сбалансировала знания и опыт сообщества разработчи­ков средств технологического управления и его деятельность в целом. Поскольку коммерческие задачи и отношения между объектами в этом сообществе уже оп­ределены, Inmedius не пришлось разрабатывать их с чистого листа. Кроме того, придерживаясь спецификаций группы по технологическому управлению, компа­ния Inmedius получила возможность замены своего компонента технологическо­го управления аналогичным компонентом от другого производителя. Операция эта, проводившаяся в случае, если конкретному заказчику требовалась функцио­нальность, которую компонент Inmedius оказывался неспособным предоставить, не требовала особых усилий.

Две спецификации группы по технологическому управлению описывали два основополагающих элемента: модель технологического управления и представ­ление ее экземпляров для периода прогона (рис. 17.7). Модель технологического управления состоит из одного или нескольких процессов, в каждом из которых определены действия, переходы между этими действиями и все ресурсы-участ­ники. В каждом процессе задействован диспетчер, который управляет всеми эк­земплярами периода прогона для конкретного процесса; каждый экземпляр пе­риода прогона хранит информацию о состоянии — в частности, о том, какие действия уже завершены, какие активны и кто их назначил, — а также контекст­ные данные, необходимые компоненту технологического управления для приня­тия решений по активному процессу.

Рис. 17.7. Диаграмма классов компонента технологического управления

Одна из проблем, которую Inmedius предстояло решить, была связана с па­раллелизмом. Есть ли необходимость в том, чтобы модель технологического уп­равления могли модифицировать несколько пользователей одновременно? Сле­дует ли разрешать пользователю модифицировать модель технологического управления при наличии ее активных экземпляров для периода прогона? Может ли пользователь запускать новый технологический процесс, если его модель в дан­ный момент модифицируется? Учитывая реализацию, а также отношения между моделью и ее экземплярами периода прогона, было бы весьма проблематично ответить утвердительно на любой из этих вопросов. Следовательно, в области решений перечисленные ситуации нужно запретить.

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