*1

Дэвид Холлингзуорт    

_____

*1 Окончание. Начало см. PC Week/RE, N 17/2001, с. 46; N 18/2001, с 32; N 19/2001, с. 30

6. Модель системной интеграции

WfMC - основная организация, разрабатывающая стандарты для систем workflow, и она пытается охватить как можно больше направлений, описанных выше. Ее программа стандартизации базируется на эталонной модели (см. рисунок).

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

Считается, что внутренние компоненты обслуживания потоков работ являются однородными и входящими в один или несколько продуктов одного и того же производителя. Благодаря такому допущению удается избежать трудностей, связанных с администрированием услуги и обеспечением ее безопасности, - все эти задачи решаются внутри “ящика”. Кроме того, в этой модели не делается никаких различий между единым централизованным ядром и взаимодействующими распределенными ядрами, которые необходимы для поддержки данных о состоянии совместно используемых процессов и создания образа единого однородного обслуживания. В модели предпринята также попытка избежать зависимости от базовой распределенной инфраструктуры за счет применения интерфейсов прикладного программирования API или форматов обмена информацией, обеспечивающих взаимодействие между системными компонентами. При этом предполагается, что все эти компоненты поддерживаются инфраструктурой *1.

_____

*1 Исключение составляет протокол функциональной совместимости между доменами workflow, о котором говорится ниже.

В модель включено пять интерфейсов, реализованных на основе конвенций для API, протоколов и форматов.

     6.1. Обмен описаниями процесса

Задача этого интерфейса состоит в обеспечении обмена описаниями процессов между инструментарием BPR (business process reengineering - реорганизация бизнес-процессов), системами управления потоками работ и репозиториями описания процессов. В его основу положена метамодель, представленная в разделе 5. Поддержка обмена информацией происходит по двум направлениям.

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

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

     6.2. Интеграция клиентских приложений

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

- для функций контроля процесса и его операций (например, пуска, приостановки и прекращения экземпляров процесса или групп таких экземпляров);

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

     6.3. Запуск приложений

Данная функция играет роль единого интерфейса, обеспечивающего:

- общую инфраструктуру для интеграции программных агентов, которые открывают доступ к другим отраслевым услугам (в частности, к репозиториям документов, планировщикам встреч и системам электронной почты), использующим собственные отраслевые API;

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

Простой набор API позволяет выполнять такие операции, как Connect/Disconnect (подключение-отключение), Invoke Application (запуск приложения), Request Status (запрос состояния) и Terminate Application (отключение приложения).

     6.4. Функциональная совместимость процессов

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

Для обмена используются два вида протоколов:

- MIME (Multipurpose Internet Mail Extensions - многоцелевые расширения почтовой службы в Интернете), описанный в документе RFC 1341;

- IDL-связывание для работы с CORBA (обычно через службы функциональной совместимости посредника запросов к объектам).

Данный интерфейс по существу опирается на тот же самый набор API, который служит для запуска процессов из клиентских приложений *1.

_____

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

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

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

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

     6.5. Аудит и мониторинг

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

Описаны также API извлечения информации о состоянии текущего экземпляра процесса или о выполняемых операциях.

7. Дальнейшие направления стандартизации

Разработанные к настоящему времени стандарты внесут большой вклад в интеграцию систем управления потоком работ - если только найдут поддержку среди производителей подобных продуктов. Важным индикатором намерений здесь может служить то, что предлагаемые стандарты workflow-технологии уже переданы на рассмотрение консорциума OMG [1], в котором нынешние спецификации WfMC получили одобрение более чем 35 организаций.

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

Интеграция объектов. Проведенные консорциумом OMG исследования позволили определить потенциальные требования к разработке архитектуры, “внутренней по отношению к менеджеру по управлению потоком работ”. Она призвана упростить интеграцию других бесплатных услуг OMG наподобие OTS (обслуживание транзакций), службы имен, безопасности, отслеживания версий и т. д. Такой подход может обеспечить более тесную интеграцию между различными продуктами управления потоком работ, если все они будут основаны на одной и той же базовой архитектуре обслуживания объектов. Представляет интерес и включение workflow в архитектуру бизнес-объектов OMG под названием Business Objects Framework, позволяющую идентифицировать повторно используемые сервисные элементы для последующего их встраивания в среду деловых приложений.

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

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

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

Интернет и электронная коммерция. Сейчас большой интерес проявляется к поддержке межфирменного управления потоками работ через Интернет. Для этой цели пригоден расширенный вариант разработанных ранее функций на основе электронной почты, поддерживающий более динамичную компоновку процесса (например, с обращением к услугам биржевых маклеров или справочным ресурсам типа “Желтых страниц”). Обсуждается также применение языка XML *1 для кодирования обмена на базе процесса.

_____

*1 XML (Extended Markup Language - расширенный язык разметки) представляет собой обобщенную версию HTML, также построенную на принципах языка SGML.

8. Перспективы на будущее

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

Несколько больше сомнений вызывает утверждение, что workflow-системы станут со временем столь же обычными средствами связи между различными платформами, как, скажем, электронная почта. Чтобы это произошло, необходима стандартизация и изменение корпоративного мышления - пользователи должны осознать всю значимость автоматизированных процессов. Уже сегодня мало кто сомневается в том, что функциональная совместимость систем управления потоками работ значительно улучшит условия торговли между компаниями. Да и демонстрация схемы автоматизированного процесса цепочек поставок [2], в которой общий бизнес-процесс охватывал семь систем различных организаций и выполнялся в автоматическом режиме, вызвал в отрасли огромный интерес *1.

_____

*1 Workflow Canada. Канада, Торонто, июнь 1996; конференция Giga Workflow, Амстердам, октябрь 1996.

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

Литература

1. Object Management Group. Framingham, MA 01701-4568, RFP for Workflow Technology, 1997, http://www.omg.org/library/schedule/Workflow_RFP.htm.

2. Anderson M. J. Workflow Engine Interoperability - What’s in it for Users. Document World (May/June 1997).