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

С появлением сложных Web-систем, цифровых библиотек, корпоративных порталов, поддерживающих и управляющих большими объемами и потоками информации, сформировалось категория подсистем, называемых системами управления содержанием/контентом Web-систем (WCMS - Web Content Management System). Первые WCMS представляли совокупности web-форм для управления данными - как несвязанных web-форм, так взаимосвязанных web-форм, но c фиксированным в программном коде порядком обработки. Сейчас актуальной становится потребность в более гибкой организации управления потоками работ, в поддержке декларативных форм определения и оперативного изменения потоков работ. WCMS должны управлять созданием и модификацией информационных сильно взаимосвязанных ресурсов произвольных типов. Потоки работ могут быть связаны не только с поддержкой информационных ресурсов, но и с выполнением полностью автономных регламентных процедур системы в ответ на, например, программные обращения, на наступление некоторого события и т.п. Описанию попытки создания такой системы, требованиям к ней, проблемам реализации и применению посвящена эта работа.

Одним из наиболее важных требований к системам управления потоками работ является следование ряду стандартов. На данный момент на рынке программных продуктов сложилась непростая ситуация[9] со стандартизацией процесса построения систем управления потоками работ.

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

• XPDL (Workflow Management Coalition) [2],

• BPML (Business Process Management Initiative) [5],

• WSFL (IBM) [7]),

• XLANG (Microsoft) [6].

Все перечисленные спецификации имеют свои характерные особенности, определяющие преимущества в функциональности основанного на их базе решения. Пока стандартизация workflow-систем носит больше теоретический, чем практический характер.

Спецификация XPDL[2], предложенная Workflow Management Coalition (WfMC) [1], представляет собой формальную модель для описания рабочих процессов, относящихся к любым сферам деятельности.

The Web Services Flow Language[7], разработанный компанией IBM, представляет собой XML-язык, описывающий композицию произвольного типа Web-служб в рамках одной модели потоков (Flow Model). Данная композиция описывается последовательностью точек доступа к функциям, предоставляемым различными службами. Порядок запуска сервисов определяется с помощью управляющих потоков и потоков данных между Web-службами. Flow Model предназначена для моделирования бизнес-процессов и потоков работ, основанных на использовании различных Web-сервисов.

В отличие от графовых моделей XPDL и WSFL спецификации BPML[5] и XLANG[6], предложенные Business Process Management Initiative и корпорацией Microsoft соответственно, являющиеся родственными стандартами, реализуют блочную модель потоков работ, приближенную к блочной структуре языков программирования. BPML охватывает наиболее широкий спектр характерных особенностей моделей рабочих процессов данного типа, представляет собой абстрактную модель и XML-язык для описания рабочих процессов. В качестве исполнителей заданий потока работ в модели BPML выступают различного рода Web-сервисы. Для описания сервиса и всех услуг, предоставляемых им потребителю, используется спецификация WSDL (Web Services Description Language). Общение с такими службами может осуществляться, например, посредством протокола SOAP (Simple Object Access Protocol).

Проведенный сравнительный анализ двух видов моделей (блочных и графовых) на примере их основных представителей (XPDL и BPML) с точки зрения организации в них основных конструкций, определяющих модель потоков работ, показал, что все основополагающие конструкции блочной модели BPML могут быть выражены через их прямые аналоги модели потоков работ XPDL. Между тем спецификация XPDL обладает рядом очевидных преимуществ.

На основании проведенного анализа за базовый стандарт описания модели рабочих процессов по редактированию ресурсов репозитория ИСИР выбрана спецификация XML Process Definition Language (XPDL) ввиду наиболее полного соответствия требованиям к функциональности создаваемого решения.

Следование каноническим спецификациям и стандартам дает ряд очевидных преимуществ как в случае систем управления потоками работ, так и в случае других практических решений:

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

• Переносимость и интероперабельность: модели процессов, созданные в рамках одной системы, могут частично или полностью работать под управлением другой (возможно, удаленной) системы.

• Универсальность: расширяемость стандартов делает возможным применение единого механизма описания управления потоками работ в различных сферах деятельности.

Таким образом, следование ряду стандартов позволяет создавать автономные, открытые workflow-системы, что, безусловно, расширяет область и способы их применения для моделирования различных рабочих процессов.

• WorkflowProcess - представляет собой контекст выполняющегося процесса, и его данные могут быть доступны всем остальным компонентам.

• Activities - "действия" или "задания" процесса, представляющее собой этап, на котором происходит изменение содержания объектов процесса.

• Transition - переходы между заданиями (могут быть условными и безусловными).

• Workflow Relevant Data - оперативные данные, доступные всем компонентам процесса в ходе его выполнения

• Participants - участники процесса, производящие "действия" над объектами и осуществляющие переходы (участники могут являться как человеческими, так и машинными ресурсами).

• Applications - внешние IT- или другие приложения, используемые для выполнения "действий" участниками процесса.

Стандарт WfMC [1] определяет три фундаментальных понятий - Workflow, Workflow Management и Workflow Management System:

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

• Workflow Management - это набор методов и технологий для автоматизации бизнес процесса в целом или его части посредством информационных объектов, когда информация или задания передаются от одного участника к другому для выполнения действий, соответствующих набору процедурных правил.

• Workflow Management System (WfMS) - это система, которая определяет, создает и управляет выполнением workflow-процессов с помощью специального программного обеспечения.

Системы управления потоками работ обеспечивают процедурную автоматизацию делового процесса, управляют последовательностью действий работника с ресурсами, связанными с различными шагами деятельности. Индивидуальный деловой процесс может иметь время жизни в пределах от нескольких минут до нескольких дней (или даже месяцев или лет) в зависимости от его сложности и продолжительности различных действий. На самом высоком уровне все workflow системы могут быть характеризованы как системы, обеспечивающие поддержку в трех функциональных областях:

• Встроенные функции, которые задаются определением и моделированием процесса workflow (Build-time functions).

• Функции контроля во время выполнения, отвечающие за управлением процессами workflow в эксплуатационной среде и последовательностью различных действий, которые будут обработаны как часть каждого процесса (Run-time control functions).

• Взаимодействие во время выполнения с пользователями или программными системами (Run-time Activity Interactions).

Следующий рисунок иллюстрирует указанные выше основные характеристики workflow-систем и отношений между этими основными функциями:

Рассмотрим назначение указанных архитектурных уровней системы управления потоками работ:

• Уровень определения процесса (Built-time Functions). Данный уровень представлен набором функций, задача которых заключается в декларативном определении бизнес-процесса. Во время этой фазы бизнес-процесс переводится из "реального" мира в "формальный", понимаемый компьютером, с помощью анализа, моделирования и использования набора средств декларативного представления. Результирующая декларация процесса носит название "модели процесса", "шаблона процесса", "метаданных процесса" или "определения процесса". Модель процесса состоит из ряда дискретных "действий", переход между которыми осуществляется в соответствии с набором некоторых правил посредством выполнения операций, исполнителем которых может быть как человек, так и компьютер. Определение процесса может быть представлено как текстовым или графическим описанием, так и декларацией на некотором формальном языке описания потоков работ. Некоторые процессы допускают возможность внесения изменений в их определение в ходе их выполнения. Соответствующая функциональность помечена обратной стрелкой на диаграмме.

• Уровень создания и выполнения процесса (Run-time functions). На этапе выполнения происходит анализ определения процесса специальным программным обеспечением, которое отвечает за создание и управление экземплярами потоков работ, управление и планирование заданий, привлечение соответствующих человеческих, IT- и других видов ресурсов. Функции уровня выполнения являются связующим звеном между моделью процесса в формальном определении и его реальным видом, отражающим взаимодействие пользователей и IT-приложений. Центральным компонентом системы является служба управления потоками работ, которая отвечает за создание и удаление процессов, планирование заданий процесса и взаимодействие с человеческими и автоматизированными ресурсами.

• Уровень средств взаимодействия с пользователями и приложениями (Run-time Activity Interactions). Индивидуальные задания рабочего процесса, как правило, связаны с человеческой деятельностью, для выполнения которой привлекаются дополнительные IT-приложения (например, ряд форм для заполнения). Некоторые операции требуют наличия специальных средств для манипулирования данными (например, занесение новой записи в базу данных). Поэтому необходимо обеспечить гибкое взаимодействие пользователей со службой управления потоками работ для того, чтобы передавать управление между заданиями, назначать операционные состояния процессам, запускать приложения или передавать необходимые данные.

Выделяют следующие функциональные области, адресованные Workflow системам:

• Определение процесса работ: спецификация данных для процесса и его обмена с окружающей средой.

• Способность к взаимодействию: поддержание интероперабельности между различными системами workflow.

• Вызов сторонних приложений.

• Клиентские приложения: поддержание способности к взаимодействию с пользовательскими функциями интерфейса (например, обработка запроса на получение нового задания или завершение выполненного).

• Администрирование и контроль: поддержание интерфейсов для обеспечения контроля системы, а также для облегчения управления взаимодействием с окружающей средой.

Поскольку Информационный Web-портал РАН является системой, предоставляющей конечному пользователю полную оперативную информацию о произвольной сложности ресурсах РАН, он должен обладать гибкими средствами для поддержания актуальности имеющихся данных: быстрой пакетной загрузки больших объемов информации и автоматизированного управления потоками работ по созданию и редактированию атрибутов существующих в системе ресурсов. XML и RDF загрузка решает задачу о внесении в базу данных больших объемов информации. Редактирование и создание отдельных ресурсов с помощью форм требует наличия системы, управляющей декларируемыми потоками работ пользователей. Даже после пакетной загрузки требуется участие администраторов данных, отвечающих на запросы системы по нарушениям форматов, разрешению неоднозначности, выявлению дубликатов, которое также должно осуществляться в рамках ролевых, контролируемых потоков работ.

На базе перечисленных выше требований, была создана служба управления потоками работ по редактированию ресурсов Информационного Web-портала РАН [8], ядро которого составляет система ИСИР РАН [3], новая версия которой использует платформу Java и ряд opensource решений [10-12]. Данный сервис использует службу объектно-реляционного отображения, предоставляемую новой версией ИСИР, для хранения объектной модели рабочих процессов в базе данных, а также службу аутентификации и управления пользовательскими правами доступа к объектам процессов. Для декларативного описания новых типов потоков работ используется часть спецификации XPDL, обеспечивающая необходимую функциональность. Пользовательские интерфейсы системы управления потоками работ построены на базе Java-технологий ИСИР, автоматизирующих процесс построения Web-форм для редактирования ресурсов. Рассмотрим принципы построения и работу сервиса.

Общая объектная модель процесса представлена на рис. 4:

В объектной схеме сервиса, представленной на данном рисунке, не отображен еще один тип объектов - TransitionHistoryItem - представляющий собой элемент журнала протоколирования переходов между заданиями. При осуществлении перехода в полях данного объекта сохраняются следующие данные: ссылка на осуществленный переход, комментарий к переходу, ссылка на совершившего его пользователя, дата перехода и т.п. История переходов процесса доступна для просмотра менеджеру процесса через Web-интерфейс.

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

Маршрут процесса представляет собой направленный граф, узлами которого являются объекты Activity (задание пользователя), а дугами - объекты Transition (переход между заданиями). Процесс может иметь только одно начальное задание и несколько завершающих. Переход по маршруту может осуществляться к одному из следующих в соответствии с декларацией процесса заданий или к любому из предыдущих (включая начальное). В каждый момент времени может существовать не более одного "активного" пользовательского задания для данного процесса. Все остальные задания (узлы маршрута) должны иметь статус "неактивно" или "завершено".

Процесс может находиться в одном из трех состояний: "активен", "неактивен" или "завершен". Если процесс находится в "активном" состоянии, его текущее "активное" задание доступно исполнителям. В "неактивном" и "завершенном" состоянии никакие задания процесса не видны его исполнителям. Помимо этого, статус процесса влияет на автоматическое управление датами создания и завершения процесса. Управление статусами процесса выполняется системой или администратором через соответствующие Web-интерфейсы. "Активное" состояние процесса разбивается на два дополнительных состояния: "активен и просрочен" и "активен и не просрочен". Просроченным процессом считается любой процесс, активное задание которого не укладывается в отведенные для него временные рамки.

В роли редактируемых с помощью данного процесса ресурсов могут использоваться произвольные хранимые объекты "ядра" портала. Любой тип процесса может применяться как к произвольным объектам системы, так и к выделенному набору типов ресурсов, для которых должно существовать более специфичное описание потоков работ.

Задание процесса Activity является точкой маршрута процесса, в которой осуществляются работы по изменению содержания ресурса. На каждое задание накладываются строгие временные рамки, представленные тремя датами: дата постановки (активации) задания, дата крайнего срока исполнения задания, дата фактического завершения выполнения задания.

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

В XML-декларации задания имеется ссылка на приложение, которое предоставляет пользователю визуальные интерфейсы для выполнения этого задания. В соответствии со спецификацией XPDL информация о типе конкретного приложения не включается в описание процесса. Задание должно знать только о том, куда направить пользователя для редактирования ресурса; весь процесс редактирования контролируется самим приложением. В существующем применении данной службы для управления потоками работ по созданию новых ресурсов Информационного Web-портала РАН для модификации атрибутов ресурсов в узлах маршрута используется служба "ядра" для управления формами редактирования ресурсов и её понятие wizard-а. Wizard представляет собой группу форм, служащую для редактирования одного или нескольких ресурсов, отличительной чертой которой является назначение прав на отдельные формы (это отражается и в навигационном меню wizard-а). Это позволяет организовать более гибкое управление ходом выполнения потоков работ.

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

Как и в случае всего процесса, каждое из его заданий может иметь следующий набор состояний: "активно" ("просрочено" или "не просрочено"), "неактивно" или "завершено". Управление статусами заданий выполняется либо системой, либо администратором процесса.

Направленные дуги переходов между заданиями маршрута процесса представлены объектами Transition. Для перехода существует условное понятие направления ("прямое" или "обратное"), которое влияет на управление характерными датами заданий, между которым осуществляется переход. При переходе от одного задания к другому системой выполняется следующая последовательность действий:

1. Если происходит переход в прямом направлении, то текущее активное задание завершается (проставляется статус "завершено", дата завершения, выполнивший его пользователь), а следующее (указанное в декларации) задание активируется (проставляется статус "активно", и дата постановки инициализируется текущей датой).

2. Если происходит переход в обратном направлении, то текущее активное задание деактивируется (проставляется статус "неактивно"), а одно из предыдущих заданий, к которому осуществляется переход (в данный момент завершенное) активируется (проставляется статус "активно", но дата постановки не сбрасывается). Таким образом, если происходит возврат к одному из завершенных заданий, то для этого задания все временные рамки остаются такими же, как и до завершения (в том числе и крайний срок исполнения). Данная политика означает то, что задание считается полностью выполненным только тогда, когда на него нет возвратов ввиду его неверного исполнения.

3. Если задание, к которому должен осуществляться переход не указано, то текущее задание считается последним в маршруте, и происходит завершение всего процесса - изменяется статус процесса и проставляется дата завершения.

4. Информация о совершенном переходе заносится в журнал переходов процесса

На все переходы между заданиями (так же как и на сами задания) назначаются права доступа. При отсутствии явно указанных исполнителей конкретного перехода, он становится доступен всем участникам процесса, имеющим доступ к заданию, с которого осуществляется этот переход.

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

Приведем пример описания процесса, реализующего простейшую схему: менеджер, создав процесс, передает управление процессом автору, который производит наполнение полей создаваемого ресурса. Затем редактор проверяет корректность работы автора и либо передает ресурс автору на доработку, либо менеджеру на утверждение. Менеджер может либо завершить процесс, либо передать его автору или редактору на доработку. Так же он может сам принять участие в редактировании и при этом сразу утвердить ресурс, минуя последний этап контроля.

<Participant Id="P1" URI="urn:hdl:1016.1/kernel/Group#MANAGERS">

<ParticipantType Type="GROUP"/>

</Participant>

<Participant Id="P2" URI="urn:hdl:1016.1/kernel/Group#AUTHORS">

<ParticipantType Type="GROUP"/>

</Participant>

<Participant Id="P3" URI="urn:hdl:1016.1/kernel/Group#EDITORS">

<ParticipantType Type="GROUP"/>

</Participant>

<Title lang="ru">Трех-ролевой процесс.</Title>

<Title lang="en">Three-role process.</Title>

<Description lang="ru">Данный процесс реализует</Description>

<Description lang="en">This process implemnts</Description>

<Appliction>

<Description lang="ru">Создание ресурса.</Description>

<Description lang="en">Resource creation.</Description>

<Description lang="ru">Редактирование ресурса.</Description>

<Description lang="en">Resource editing.</Description>

<Description lang="ru">

Проверка корректности создания ресурса.

<Description lang="en">Resource creation control.</Description>

<Transition Id="Trans-1" From="activity-1" To="activity-2" Direction="forward">

<Description lang="ru">На редактирование</Description>

<Description lang="en">For editing</Description>

</Transition>

<Transition Id="Trans-2" From="activity-2" To="activity-1" Direction="backward">

<Description lang="ru">На создание</Description>

<Description lang="en">For creating</Description>

<Transition Id="Trans-3" From="activity-2" To="activity-3" Direction="forward">

<Transition Id="Trans-4" From="activity-2" Direction="forward">

<Description lang="ru">Утвердить</Description>

<Description lang="en">Confirm</Description>

<Performer>P1</Performer>

<Transition Id="Trans-5" From="activity-3" To="activity-1" Direction="backward">

<Description lang="ru">На создание</Description>

<Description lang="en">For creating</Description>

<Transition Id="Trans-6" From="activity-3" To="activity-2" Direction="backward">

<Description lang="ru">На редактирование</Description>

<Description lang="en">For editing</Description>

</Transition>

<Transition Id="Trans-7" From="activity-3" Direction="forward">

<Description lang="ru">Утвердить</Description>

<Description lang="en">Confirm</Description>

К отличительным особенностям описанного процесса можно отнести следующее:

• Процесс применим для редактирования пяти видов ресурсов ИСИР (наличие нескольких элементов OBJECT внутри элемента ProcessHeader).

• В роли участников процесса выступают системные группы пользователей.

• Создателем экземпляров процессов данного типа является администратор.

• Процесс содержит как прямые переходы (Trans-4), так и обратные (Trans-5).

• Процесс содержит как общедоступные переходы (Trans-3), так и привилегированные (Trans-4).

• Процесс поддерживает задания с множественными исполнителями (например, activity-2).

Реализованная модель рабочих процессов предполагает наличие трех предопределенных пользовательских ролей:

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

• CREATOR - может создавать новые экземпляры процессов, но не имеет возможностей менеджера по управлению процессами. Может являться исполнителем заданий и осуществлять переходы.

• PERFORMER - является исполнителем доступных ему заданий и выполняет назначенные для него переходы.

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

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

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

Практичность имеющегося на текущий момент решения, выявленные дополнительные потребности свидетельствуют о необходимости дальнейшего развития системы управления потоками работ, реализации на её основе простой системы электронного документооборота, которая будет востребована в WCMS.

Проектирование и разработка системы управления потоками работ по манипулированию ресурсами репозитория ИСИР разбита на несколько этапов. К данному моменту (частично или полностью) поддержана следующая функциональность:

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

• Дополнение выбранного подмножества элементов XPDL конструкциями, поддерживающими рекурсивные процессы и задания (например, группы заданий BlockActivity и ActivitySet, а так же подпроцессы SubFlow). Расширение набора управляющих атрибутов созданной объектной модели.

• Реализация модели пакетов XPDL с возможностью экспорта и импорта элементов описания.

• Добавление остальных компонентов объектной модели XPDL с поддержкой их хранения в реляционной базе данных.

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

• Реализация некоторого унифицированного интерфейса для общения системы с внешними Web-приложениями произвольного типа (возможно, базирующегося на описании интерфейсов Web-служб с помощью WSDL).

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

• Поддержка множественных переходов с одного задания (параллельный запуск нескольких заданий с возможностью их синхронизации).

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

• Реализация подсистемы управления транзакциями заданий на базе службы ведения версий хранимых объектов.

• Усовершенствование подсистемы протоколирования операционных состояний объектов рабочего процесса. Добавление возможности ведения протоколов на различных физических носителях. Интеграция со службой аудита хранимых объектов "ядра".

• Модернизация Web-интерфейсов системы управления потоками работ.

• Выбор и применение одного из существующих средств визуального проектирования для создания XPDL-описаний рабочих процессов.

К задачам второстепенной важности можно отнести поддержку возможности экспорта XPDL-описаний с предварительным преобразованием к другим существующим стандартам декларации потоков работ и реализацию распределенной системы управления рабочими процессами.

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

Поддержка и следование службой управления рабочими процессами по манипулированию ресурсами репозитория ИСИР ряду соответствующих стандартов делает возможным её применение в системах управления контентом Web-порталов, системах электронного документооборота и других сервисах, автоматизирующих управление потоками работ, распределенных между разнообразными участниками производственных процессов. Широчайшая область применения служб подобного типа дает не менее широкие предпосылки к дальнейшему развитию и модернизации данного проекта.