CC BY
58
УДК [004:316]:005-044.337:004.434’22’236:658 Вестник СПбГУ. Сер. 10, 2008, вып. 3
Л. Б. Ольхович
АВТОМАТИЗИРОВАННАЯ ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ*)
1. Введение. Сервис-ориентированные архитектуры (Service-Oriented Architectures - SOA [1]) часто используют составные web-сервисы, реализованные через дирижирование другими сервисами. Эффективность такого дирижирования соответственно является ключевым фактором, влияющим на производительность любого составного web-сервиса.
Дирижирование достигается с использованием технологий и стандартов из области бизнес-процессов. BPEL [2] является наиболее распространенным примером. В BPEL составной web-cepenc представляется в виде набора бизнес-процессов, и в этом случае производительность дирижирования напрямую зависит от производительности соответствующего бизнес-процесса.
Существенное отличие между абстрактными и исполнимыми процессами - то, что любые ошибки и неоптимальности в последних немедленно отражаются на предоставляемых сервисах. Поэтому необходимо обеспечение корректности и эффективности исполняемых процессов.
Исследования, проводимые в настоящее время в области бизнес-процессов, в основном рассматривают проблемы оценки и предсказания производительности процессов. Однако в некоторых случаях следует не только оценить, но и повысить производительность процесса, особенно если она неудовлетворительна. Если невозможно уменьшить время исполнения каждого отдельного действия в процессе, так как оно зависит от человеческой либо аппаратной производительности, то все равно может быть возможно повысить производительность процесса в целом за счет устранения неоптимальностей в его структуре.
Цель настоящего исследования - разработка метода автоматической оптимизации производительности бизнес-процессов на основе реконструкции и анализа потока и эволюции данных процесса.
2. Обзор литературы. Предсказание и оценка производительности. Существуют три подхода к предсказанию и оценке производительности бизнес-процессов: аналитические методы, симуляция и измерения [3].
Аналитические методы пытаются предсказать различные параметры производительности путем применения методов формального анализа к моделям процессов [4].
Симуляция, как прямое исполнение модели, выполненной с помощью некоторого специального языка моделирования (визуального либо текстового), является достаточно простым способом предсказания производительности процесса [5].
Измерения относятся к наиболее точным способам сбора показателей производительности процесса; однако исполнение процесса может быть сопряжено со значительными временными и финансовыми затратами. Для их минимизации может быть применено имитационное окружение сжатого времени [6]. Альтернативный подход заключается в проведении измерений в частично-имитационном окружении с параметрами производительности, эквивалентными таковым настоящего окружения [7].
Исследование выполнено при финансовой поддержке Siemens AG, СТ SE1.
© Л. Б. Ольхович, 2008
Мониторинг исполнения и упреждающее управление производительностью процесса. Цель упреждающего управления производительностью - заблаговременное предсказание и избежание ситуаций, когда процесс нарушает требования по производительности (например, временные). В простейшем случае \гогкйо\у-система опознает такие ситуации до их возникновения и возбуждает исключение заранее, делая возможной более изощренную обработку исключений [8]. Другой подход (АБв [9]) заключается в попытке избежать возникновения подобных ситуаций в принципе, выбирая наиболее подходящих поставщиков сервисов среди доступных альтернатив и применяя динамическую перепланировку для обеспечения требуемых показателей производительности. К сожалению, платформа АБв опирается на семантические аннотации сервисов, которые в настоящее время еще не получили широкого распространения.
3. Оптимизация бизнес-процессов. Несмотря на то, что различные методы автоматической оптимизации программного обеспечения уже длительное время успешно используются в компиляторах, они не могут быть применены непосредственно к бизнес-процессам по нескольким причинам.
Компиляторы оптимизируют программный код автоматически, руководствуясь формальной операционной семантикой языка программирования и ассемблера. Наличие полной формальной спецификации операционной семантики позволяет осуществлять как высокоуровневую, так и низкоуровневую оптимизацию и преобразовывать результирующий программный код без изменения его функциональности. Так как у большинства языков моделирования бизнес-процессов формально определенная операционная семантика отсутствует [10, 11], а также из-за возможного наличия у отдельных действий процесса побочных эффектов, не указанных в их определениях, архитектор процесса должен после каждой оптимизации проверять, что процесс остался корректным, любое изменение бизнес-процесса немедленно отразится на сервисах, предоставляемых с его помощью. Это, однако, невозможно в случае, когда оптимизация меняет процесс до неузнаваемости.
Как следствие, оптимизация бизнес-процессов должна удовлетворять следующим требованиям: 1) она должна проводиться под человеческим наблюдением; 2) она
должна проводиться в терминах высокоуровневых конструкций исходного языка моделирования бизнес-процессов.
Неоптимальный поток управления. Как и workflow-гpaфы [12], ВРЕЬ описывает бизнес-процессы как потоки задач [1] - в терминах потоков управления, в основном игнорируя информацию о потоках данных. Это приводит к тому, что действия в бизнес-процессе упорядочены, исключительно исходя из того, что кажется разумным архитектору процесса. Такое упорядочение, однако, может быть не самым эффективным.
В этой статье поток управления, который может быть изменен так, чтобы производительность процесса повысилась при сохранении его функциональности, будет называться неоптимальным. Обнаружение неоптимальностей потока управления позволит архитектору процесса оптимизировать процесс, исключив из его потока управления не необходимые синхронизации и, таким образом, уменьшить времена ответа, исполнения процесса и простоя и поднять производительность.
В рамках данной статьи предполагается, что все действия процесса либо выполняются самой виртуальной машиной, либо являются вызовами -\¥еЬ-сервисов. Так как поставщик сервиса может в любой момент поменять реализацию сервиса, формальное определение интерфейса сервиса должно быть достаточным для определения зависимостей по данным и требуемого упорядочения отдельных действий - вызовов сервисов.
Таким образом, действия в бизнес-процессе должны удовлетворять как минимум двум свойствам ACID : атомарности и изолированности:
- атомарность гарантирует завершение любого действия либо полным успехом, либо полным отказом, а это означает, что промежуточные результаты не отражаются на исполнении процесса;
- изолированность указывает, что никакие два одновременно исполняемых действия не будут воздействовать друг на друга, как следствие, у них не может быть общих данных (разделяемого состояния). Это, в свою очередь, означает, что два действия могут зависеть друг от друга, только если между ними существует поток данных.
Зависимости между действиями. Их можно определить как необходимость успешного завершения некоторого действия для начала выполнения другого действия. В рамках данного исследования предлагается идентифицировать такие зависимости на основании анализа потока данных и эволюции состояний данных процесса.
Когда происходит чтение переменной, никакого изменения состояния переменных процесса не происходит; в то же время их состояние меняется при каждой записи переменной - происходит эволюция ее состояния. Таким образом, необходимым условием для выполнения некоторого действия является не просто наличие некоторой переменной, но и нахождение ее в определенном состоянии.
Тогда, в предположении об изолированности и атомарности действий в бизнес-процессе, зависимость между действиями возникает, когда одно действие использует в качестве входных данных результат выполнения другого действия. Другими словами, зависимость между действиями означает, что одно действие ожидает в качестве входных данных переменную в состоянии, получившемся в результате исполнения другого действия.
Соответственно для вычисления зависимостей между действиями в бизнес-процессе необходимо проанализировать не только поток данных, но и эволюцию состояний переменных процесса.
4. Установление зависимостей между действиями процесса. Указанные выше свойства позволяют определить зависимости между действиями процесса, возникающие в результате доступа некоторого действия к переменной, ранее инициализированной или измененной каким-либо другим действием. Идентификация зависимостей основана на анализе аналогичной сети Петри вспомогательной структуры данных, объединяющей в себе потоки управления и данных и информацию об эволюции данных процесса (для удобства называемой далее просто «сетью Петри»). Сравнение полученной информации о зависимостях между действиями с исходным потоком управления процесса дает возможность обнаружить элементы потока управления, не обусловленные никакими зависимостями и, таким образом, делающие поток управления процесса неоптимальным.
Построение сети Петри. В качестве проверки предложенного метода было разработано программное средство для анализа бизнес-процессов, описанных в виде workflow-графов. В этом средстве трансформация потока управления в сеть Петри
Некоторые исследователи утверждают, что действия в бизнес-процессе должны удовлетворять всем требованиям ACID [13] (atomicity, consistensy, isolation, durability - атомарность, согласованность, изолированность, надежность) даже в случае, когда они не ограничиваются вызовами web-сервисов [14].
**) Семантические аннотации web-сервисов могут предоставить дополнительную информацию о зависимостях между действиями и могут быть легко включены в предлагаемый метод анализа; то же касается и явно определенных транзакций в BPEL.
основывается на трансформации, описанной в [15], за исключением некоторых особенностей, связанных с наличием в результирующей сети также потока данных процесса.
В результирующей сети Петри состояния переменных представлены в виде специальных «мест для данных» (при этом месту соответствует не конкретное значение переменной, а именно ее состояние).
Хотя идея в некоторой степени похожа на CPN [16], между описываемой здесь сетью Петри и CPN существуют важные различия:
1) в получающейся сети Петри потоки управления и данных разделены;
2) «место для данных» соответствует некоторому состоянию переменной в ее цепи эволюции, а не только участию переменной в потоке данных процесса.
На самом деле получающаяся сеть Петри в большей степени похожа на Data Flow Graph [17], чем на CPN.
Так как считается, что состояние переменной не изменяется при операциях чтения и меняется при каждой операции записи, при построении сети Петри используются следующие правила:
- операции, «читающие» переменную, изымают фишку из «места для данных», соответствующего текущему состоянию переменной, и возвращают ее по завершении;
- операции, изменяющие переменную, изымают фишку из «места для данных», соответствующего текущему состоянию переменной, и возвращают фишку в новое «место для данных»;
- операции, инициализирующие переменную, при своем завершении кладут фишку в новое «место для данных».
Операции чтения, за которыми не следуют никакие другие операции с данной переменной в этом же состоянии, не будут возвращать фишку в исходное «место для данных», соответственно по завершении процесса не останется лишних фишек; для параллельных операций чтения фишка будет изъята соответствующим переходом в точке синхронизации.
Анализ сети Петри. Анализ потока управления состоит из следующих шагов:
1) при помощи анализа потока данных и эволюции их состояния устанавливаются зависимости между отдельными действиями;
2) граф потока управления процесса сравнивается с информацией о зависимостях между действиями.
Анализ производится путем «заливки» по Дейкстре сети Петри по дугам потока данных . Соответственно для каждого перехода формируется список «предшествующих» переходов, тем самым задавая отношение предшествования, наличие которого отвечает зависимости между действиями процесса.
Сравнение выделяет из дут потока управления все элементы, которые обусловлены зависимостями между действиями процесса; соответственно остальные дуги потока управления являются источниками неоптимальности, так как означают синхронизации, не отвечающие никаким зависимостям между действиями.
Пример анализа представлен на рис. 1:
- Исходный процесс: действие А инициализирует переменную R, действие В изменяет ее, а действия С и D читают уже измененное значение переменной R.
- Сеть Петри: переходы соответствуют действиям исходного процесса; «место для данных» i?i соответствует состоянию переменной R после действия Л. /после действия в.
Дуги, означающие операцию чтения, трактуются как направленные от «места для данных» к переходу-читателю.
- Граф зависимостей: так как действие В изменяет значение Д, когда она находится в состоянии «после действия Л», между действиями В и А есть зависимость; аналогично - для зависимостей (С и В) и (О и В). Зависимости же между действиями С и В нет, ибо С не меняет значения Д.
Исходный процесс
Сеть Петри
Граф зависимостей
&.
А
В
► С
й
А
В
і
і
С
О
Рис. 1. Анализ бизнес-процесса.
Зависимости между действиями показаны пунктирными линиями, поток управления сплошными, поток данных точечными (то же для рис. 2 5).
5. Оптимизация бизнес-процесса. Используя полученную в ходе анализа информацию о неоптимальностях потока управления и о зависимостях между действиями, процесс может быть полуавтоматически оптимизирован следующим образом:
1. Удаляются дуги потока управления, вызывающие неоптимальность.
2. Создаются новые элементы потока управления, обусловленные «неудовлетворенными» зависимостями между действиями - зависимостями, которым не соответствуют никакие имеющиеся дуги потока управления.
3. Корректность полученного в результате автоматической оптимизации процесса должна быть проверена архитектором.
Пример оптимизации представлен на рис. 2:
1) из исходного процесса удаляется избыточная дуга потока управления 3 => 4, так как между действиями 3 и 4 нет зависимостей;
2) при редукции из графа зависимостей удаляется дуга 5 => 1, ибо она является замыканием дуг 5 => 4 и 4 => 1;
3) удаляются удовлетворенные зависимости 5 => 4, 3 => 2 и 2 => 1;
4) наконец, добавляются дуги потока управления 1 => 4 и 3 => 5, соответствующие двум оставшимся зависимостям: 4 => 1 и 5 => 3.
Восстановление потока управления. Для того чтобы компенсировать удаление неоптимальных дуг потока управления, не внося при этом новых неоптимальностей, производится выявление зависимостей, которым не соответствуют никакие оставшиеся дуги потока управления:
Исходный
процесс
Избыточные
элементы
потока
управления
удалены
Граф зависимостей редуцирован
Удовлетво-
ренные
зависимости
удалены
Оптимизи-
рованный
процесс
Рис. 2. Полуавтоматическая оптимизация жогкАол'-графов.
Обозначения см. на рис. 1.
1) так как для выполнения действия необходимо завершение всех предшествующих ему и из-за того, что зависимости, очевидно, являются транзитивными, из графа зависимостей удаляются все транзитивные замыкания (они уже выражены через дуги потока управления, соответствующие другим зависимостям). Эта процедура имеет однозначный результат, потому что в графе зависимостей корректного процесса не может быть циклов;
2) из оставшегося графа зависимостей удаляются зависимости, для которых существуют соответствующие дуги в потоке управления.
После первого шага, на котором из графа зависимостей удаляются транзитивные замыкания, остаются только зависимости, соответствующие потокам данных непосредственно от одного действия процесса к другому. Таким зависимостям, которые не выражаются через никакие другие, должны соответствовать дуги потока управления.
Необходимо заметить, что представленный здесь алгоритм неприменим напрямую к структурированным бизнес-процессам (в том числе и к ВРЕЬ) из-за необходимости по возможности сохранить имеющуюся структуру.
6. Пример. В качестве примера рассмотрим достаточно типичный для многих организаций процесс закупки нового оборудования. В несколько упрощенном виде он может быть представлен как следующий набор шагов:
1) поступление от сотрудника запроса на покупку оборудования («Получение запроса»);
2) визирование запроса начальником отдела («Визирование»);
3) запрос цены у поставщика («Запрос продавца»);
4) визирование запроса бухгалтерией («Проверка бюджета»);
5) закупка («Закупка»).
Этот процесс очевидным образом легко автоматизируем и представим в виде набора вызовов шеЬ-сервисов.
Рис. 3. Бизнес-процесс до оптимизации. Обозначения см. на рис. 1.
Рис. 4■ Граф зависимостей и неонтимальность в потоке управления. Обозначения см. на рис. 1.
Процесс показан на рис. 3 (для простоты опущен объемлющий последовательный контекст): шаги 4 и 5 объединены в транзакцию, шаг 2 не включен в нее из-за наличия потоков данных, делающих явное задание транзакции излишним.
На рис. 4 представлены зависимости между действиями процесса, полученные в результате анализа эволюции состояний и потока данных процесса (а также с учетом транзакций), и неонтимальность в потоке управления процесса.
На рис. 5 показан оптимизированный процесс. Как из него видно, исходный процесс не требовал последовательного исполнения. Как следствие, возможны его па-раллелизация и уменьшение времени выполнения процесса на тш{время выполнения действия «запрос цены у поставщика», время выполнения действия «визирование у начальника»}.
Заключение. В работе предложен метод полуавтоматической оптимизации бизнес-процессов, основанный на реконструкции и анализе потока данных и эволюции данных
Рис. 5. Бизнес-процесс после оптимизации. Обозначения см. на рис. 1.
процесса. Этот подход был опробован на ациклических workflow-графах и в настоящий момент расширяется для поддержки языка BPEL.
Summary
Olkhovich L. В. Semi-automated business process performance optimization.
A method for increasing performance of a business process using control flow optimization is presented. The method is based on reconstruction and analysis of data flow and data evolution of a business process.
Литература
1. Singh М., Hahns M. N. Service-Oriented Computing - Semantics, Processes, Agents. Hoboken: John Wiley and Sons Ltd., 2005. 588 p.
2. BEA Systems, IBM, Microsoft, SAP AG and Siebel Systems. Business process execution language for web services (BPEL), version 1.1. [Электронный ресурс], май 2003. Режим доступа: http://www.ibm.com/developerworks/library/ws-bpel, свободный.
3. Jonkers Н., Frankеп Н. Quantitative modelling and analysis of business processes // Simulation in Industry: Proc. 8th European Simulation Symposium. Vol. I / Eds: A. Bruzzone, E. Kerckhoffs. Genoa, Italy, Oct. 1996. P. 175-179.
4. Jonkers H., Boekhoudt P., Rougoor М., Wierstra E. Completion time and critical path analysis for the optimisation of business process models. // Proc. of the 1999 Summer Computer Simulation Conference / Eds: M. Obaidat, A. Nisanci, B. Sadoun. Chicago, IL, USA, July 1999. P. 222-229.
5.Miller J. A., Cardoso J., Silver G. Using simulation to facilitate effective workflow adaptation // Proc. 35th Annual Simulation Symposium (ANSS-35 2002). San Diego, California: IEEE Computer Society, USA. 14-18 April 2002. P. 177-181.
6. Jine L., Casati F., van Moorsel A. Design of a business process analyzer j j Proc. of the Intern. Symposium on Information Systems and Engineering, ISE-2002. [Электронный ресурс], 2002. Режим доступа: http://www.scs.org/getDoc.cfm? id= 1932, свободный.
7. Olkhovich L. Measuring QoS-related parameters of business processes using partly-emulated execution environment j j Net.ObjectDays 2005: Proc. of the 6th Intern. Conference on Object-Oriented and Internet-based Technologies, Concepts, and Applications for a Networked World. Erfurt: tranSIT GmbH, Sep. 2005. P. 97-110.
8. Eder J., Panagos E. Managing time in workflow systems j j Workflow Handbook 2001. Publ. in Association with Workflow Management Coalition (WfMC) / Eds: L. Fischer. Lighthouse Point, Florida: Future Strategies Inc., 2000. P. 109-132.
9. Böhme H., Saar A. Integration of heterogenous services in the adaptive services grid. // Grid Services Engineering and Management. Second International Conference, GSEM- 2005. Erfurt, Germany, September 20-22, 2005, Proc. / Eds: R. Hirschfeld, R. Kowalczyk, A. Poize, M. Weske. Lecture Notes in Informatics. Erfurt: Gesellschaft für Informatik, 2005. Vol. P-69. P. 220-232.
10. Van der Aalst W. M. P., Desel J., Kindler E. On the semantics of epcs: A vicious circle //EPK / Eds: M. Nüttgens, F. J. Rump. GI-Arbeitskreis Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, 2002. P. 71-79.
11. Schmidt K., Stahl C. A petri net semantic for BPEL4WS validation and application j j Proc. of the 11th Workshop on Algorithms and Tools for Petri Nets (AWPN-04) / Eds: E. Kindler. Bericht tr-ri-04-251, Universität Paderborn, Sep. 2004. P. 1-6.
12. Sadiq W., Orlowska M. Modeling and verification of workflow graphs: Tech. Rep. N 386. Brisbane, Australia: University of Queensland, 1996. 27 p.
13. Gray J. The transaction concept: Virtues and limitations (invited paper) j j Very Large Data Bases. 7th Intern. Conference, September 9-11, 1981. Cannes, France: IEEE Computer Society, 1981. P. 144-154.
14. Van der Aalst W. M. P. The application of petri nets to workflow management j j J. of Circuits, Systems, and Computers. 1998. Vol. 8, N 1. P. 21-66.
15. Van der Aalst W. M. P. Workflow verification: Finding control-flow errors using petri-net-based techniques j j Business Process Management / Eds: W. M. P. van der Aalst, J. Desel, A. Oberweis. Lecture Notes in Computer Science. Springer, 2000. Vol. 1806. P. 161-183.
16. Kristensen L. M., Christensen S., Jensen K. The practitioner’s guide to coloured petri nets // Intern. Journal on Software Tools for Technology Transfer. 1998. Vol. 2, N 2. P. 98-132.
17. Beck M., Johnson R., Pingali K. From control flow to data flow j j J. of Parallel and Distributed Computing. 1991. Vol. 12, N 2. P. 118-129.
Статья рекомендована к печати проф. А.Н. Тереховым.
Статья принята к печати 21 февраля 2008 г.
