WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     ||
|

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

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

Во второй главе описываются существующие подходы к распараллеливанию «классического» программного обеспечения.

Рассматривается представление программы с помощью формализма единичного статического присваивания и его применения к распараллеливанию ПО. Описываются вызванные невозможностью полноценного анализа ПО ограничения возможностей автоматического распараллеливания и даётся краткая характеристика проводимым в этой области исследованиям. Далее рассматриваются отличия дирижирующих бизнес-процессов от «классического» ПО.

Форма единичного статического присваивания (Single Static Assignment Form, SSA) — это представление программы, в котором каждое присвоение значения переменной приводит к созданию новой переменной. Такая форма чрезвычайно удобна для различных анализов в компиляторах, в том числе и при распараллеливании. Она позволяет легко обнаруживать зависимые операторы: так как значение каждой переменной присваивается только единожды, то читающий её оператор использует результат выполнения оператора, инициализировавшего переменную.

Любая прикладная программа содержит большое количество библиотечных и системных вызовов. Поэтому для её 2 Не исползуется, чтение, присвоение, изменение.

распараллеливания недостаточно проанализировать внутренние потоки данных: необходимо учитывать также состояния прикладных библиотек, операционной системы и, наконец, ЭВМ. Полноценный же анализ всех перечисленных факторов на этапе компиляции невозможен хотя бы ввиду различности конфигураций ПО и ЭВМ. Таким образом, теоретически невозможно и полноценное распараллеливание «классического» ПО, за исключением ПО с крайне ограниченной функциональностью. Соответственно, основные исследования связаны с векторизацией циклов, т.е. организации одновременного исполнения тела цикла для разных итераций, локального распараллеливания, т.е.

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

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

В третьей главе рассматриваются влияние распараллеливания на производительность бизнес-процесса. Приводится формальная модель расчёта времени исполнения распараллеленного процесса.

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

Наихудшее (максимально возможное) время исполнения бизнес-процесса t равно сумме времён исполнения всех действий на max критическом пути W = {a,..., a } в этом процессе: t = t = t(a ).

1 n max W i i Влияние распараллеливания на наихудшее время исполнения БП зависит от местоположения распараллеливаемого участка:

1) распараллеливание шагов a и a, лежащих на критическом k k+пути, в предположении t(a ) t(a ), даст выигрыш t = t(a );

k k+1 max k +2) распараллеливание шагов, лежащих на субкритическом пути, не изменит t ;

max 3) распараллеливание шагов внутри тела цикла даст выигрыш t т * t' - t, где т — максимально возможное количество max C C итераций цикла, а t' и t — наихудшие времена исполнения C C распараллеленного и исходного тел цикла.

Аналогично определяется оценка среднего времени исполнения оптимизированного процесса в случае, когда известно распределение вероятностей p(W ) выбора того или другого пути исполнения W.

i i Среднее время исполнения распараллеленного процесса t' exp = t - t(W )*p(W ) < t exp i i i exp Следует заметить, что приведённые выше оценки не учитывают рост накладных расходов при параллельном исполнении шагов БП. Был проведён ряд экспериментов, в которых сравнивалось время исполнения последовательных и одновременных вызовов.

Эксперименты подтвердили гипотезу о том, что выигрыш от распараллеливания перекрывает возрастание накладных расходов:

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

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

Это требование накладывает определённые ограничения на допустимые методы распараллеливания: (1) все изменения должны производиться в терминах исходного языка высокоуровнего моделирования БП; (2) оптимизация должна производиться явно и отдельным шагом в процессе разработки/внедрения/поддержки БП.

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

Рисунок 1. Жизненный цикл БП.

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

Множество совокупных состояний процесса S = S x S x S, a P e где S — множество состояний шагов процесса, S — множество a P состояний ресурсов процесса, и S — множество внешних состояний.

e Так как сервисы в дирижирующем процессе не могут иметь разделяемого состояния, то S можно исключить из рассмотрения.

e Операционная семантика P процесса P и a шага процесса a определяет то, как исполнение процесса или его шага влияет на совокупное состояние: : S S. Далее, если шаги в процесса исполняются в некотором порядке {ai}, то P = a1... an Два детерминированных процесса P и P операционно 1 эквивалентны, если =. Показано, что для эквивалентности двух P1 Pпроцессов, отличающиеся только допустимыми порядками выполнения действий,, достаточно:

где, Далее предъявляется структурный критерий эквивалентности для процессов, заданных в виде workflow-графов, и показывается, что распараллеленный процесс P* = (A, f*, R, u) можно построить по процессу P = (A, f, R, u) следующим образом:

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

Распараллеливание процесса, согласно результатам, описанным в предыдущей главе, производится следующим образом:

1. Для процесса строится его SSA-подобное представление.

2. Исходя из SSA-представления, строится граф зависимостей шагов процесса друг от друга.

3. Граф зависимостей сличается с исходным процессом и выявляются последовательно упорядоченные шаги, которые могут выполняться параллельно.

4. Процесс преобразуется таким образом, чтобы обнаруженные в пункте 3 шаги были упорядочены параллельно при сохранении эквивалентности процессов Построение SSA-подобное BPEL SSA представление Анализ SSA и BPEL РаспаралРаспаралле Набор леленный лив ание изменений BPEL Рисунок 2. Распараллеливание БП.

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

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

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

Всем этим требованиям отвечает средство распараллеливания БП, реализованное на языке Java 5.0 в качестве модуля расширения («plugin») для открытой платформы Eclipse. Оно основываться на EMF3-модели BPEL для загрузки, сохранения и обработки BPELпроцессов. Использование EMF-модели BPEL из редактора BPEL Editor for Eclipse позволяет интегрировать средство анализа с этим, а также с любым другим BPEL-редактором. EMF также используется для хранения в памяти SSA-представления. Соответственно, средство состоит из следующих компонент:

3 Eclipse Modeling Framework – инфраструктура моделирования и кодогенерации.

- компонента интеграции с пользовательским интерфейсом Eclipse;

- библиотека манипуляции SSA (на основе EMF);

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

Платформа Eclipse Редактор BPEL Анализатор/оптимизатор EMF-модель EMF-модель SSA EMF – Eclipse Modeling Framework BPEL Ядро Core (OSGI4 и основные plug-in'ы) Рисунок 3. Компоненты средства распараллеливания.

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

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

Для того, чтобы сделать возможным нагрузочное тестирование на ранних стадиях создания БП, был разработан метод генерации окружения БП, заменяющий недоступные службы их сгенерированными заменителями. Метод базируется на подходе быстрого прототипирования производительности программного обеспечения «iPPr»5, созданном в Siemens AG, CT SE 1 при непосредственном участии автора.

Генерация окружения БП производится iPPr автоматически на основе графических моделей окружения. Исходная модель окружения процесса автоматически создаётся по определению процесса и дальше уточняется пользователем для включения в неё, например, информации об используемых заменяемой web-службой ресурсах. В результате, на 4 Основанная на Java платформа, разработка Open Services Gateway Initiative.

5 Instant Performance Prototyping, мгновенное прототипирование производительности.

выходе пользователь получает окружение, полностью готовое к развёртыванию тестируемого БП.

В заключении сформулированы выводы и основные результаты работы.

Работы автора по теме диссертации 1. Hennig A. Instant Performance Prototyping of EJB/J2EE Applications – A car rental example / R. Wasgint, B. Petrovic, L. Olkhovich // Proceedings des 5. Workshop des Arbeitskreis PEAK, Munich, 2004. – Б. изд., 2004. – С. 29-36.

2. Olkhovich L. Using Partly-Emulated Execution Environment for Measuring QoS-related Parameters of Business Processes / L. Olkhovich, E. Rachinsky, A. Hennig // Proceedings des 6. Workshop des Arbeitskreis PEAK, Berlin, 2005. – Б. изд., 2005. – C. 9-18.

3. Olkhovich L. Measuring QoS-related Parameters of Business Processes Using Partly-Emulated Execution Environment / L. Olkhovich // Proceedings of Net.ObjectDays 2005 (ASG PhD Session), Erfurt, 2005. – Б. изд., 2005. – C. 97-110.

Pages:     ||
|



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.