Анализ бизнес-процессов
Первый шаг к обеспечению безопасности бизнес-процесса состоит в анализе бизнес-процесс на предмет слабости его безопасности. В случае демо-примера Loanflow мы отметили несколько возможных слабостей и мест, где были бы полезны аудит и мониторинг. Следующая диаграмма являет пример того, как в демо-примере Loanflow может быть развернут OWSM, чтобы обеспечить безопасность этого бизнес-процесса:
См.
Автоматизация бизнес-процессов
И.М. Слюсаренко, М.Ю Слюсаренко, «InfoSoftCom»
Алексей Телековский
Евгений Патий
Алексей Прошин, директор по инструментальным средствам описания бизнес-процессов компании «ФОРС — Центр разработки»
Ольга Бурносова, консультант
Департамент консалтинга компании «Ай-Теко»
В.Сенкевич, Управляющий директор PayBot LLC
Уильям Батерст,
С.Битюков, старший консультант Oracle СНГ
Источник:
Bhagat Nainani, перевод
Подготовлено Intersoft Lab по материалам зарубежных сайтов
по материалам зарубежных сайтов ,
, старший редактор издательства Oracle Publishing.
Перевод Oracle Magazine RE
Ольга Дубина , Источник:
Александр Шарцев, Зам. начальника управления информационных технологий и систем ООО "ЛУКОЙЛ-Бурение-Пермь"
(Rich Schwerin), старший редактор издательства Oracle Publishing
Владимир Андреев, менеджер по продукции компании Digital Design
IT Manager #6(12)/2003
- менеджер проектов
Маргарита Моисеева,
,
,
Александр Глинских (к.т.н.),
Алексей Рындин (Главный инженер проектов),
Д. В. Ширяев, В. Р. Аншелес, В. Н. Мочалин., ОАО "Череповецкий "Азот", Череповецкий Государственный Университет
document.write('
 |
|
|
|
|
| |||||||||
| |||||||||
|
| PR-акции, размещение рекламы — , тел. +7 495 6608306, ICQ 232284597 | Пресс-релизы — |
|
|
|
| This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009 |
|
|
| Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. |
|
Детская мебель, различная , предлагаемая в нашем интернет-магазине сертифицирована и обеспечена гарантиями. Современные и надежные по низким ценам. |
Автоматизация сквозных бизнес-процессов предприятий с использованием BPEL
С.Битюков, старший консультант Oracle СНГ
Источник:
12 Октябрь 2005 г
Как получается, что организация работает? Почему в результате действий большого количества людей, документооборота, накопления и преобразования данных в информационных системах в конечном итоге получается тот самый результат, который ожидается? Как помыслить о том, что происходит в организации, в достаточно абстрактных и простых терминах и не уходя при этом слишком далеко от реальности?
Бизнес-процесс – одна из концепций, которая предназначена именно для этого. Кстати, существуют и другие термины, обозначающие то же самое, но в некоторых особых видах человеческой деятельности. Например, в государственном и муниципальном управлении принято говорить о регламентах, в том числе электронных, однако мы будем далее говорить о бизнес-процессах как о понятии, наиболее часто используемом в литературе, в первую очередь англоязычной. Можно по-разному определять, что же это такое (и на таком произволе и образуются различные школы и методики), однако важно то, что бизнес-процесс представляет собой некоторое действие, состоящее из более мелких действий, связанных между собой некоторым образом, и зафиксированное некоторым формальным способом. Формализация очень важна, потому что как только она появляется, то вместе с ней приходит возможность применять весь аппарат работы с формальными системами – то есть средства анализа, моделирования, верификации и много чего ещё.
Вокруг этой идей возникла целая индустрия BPM – моделирования бизнес-процессов, Business Process Modeling. Много решений пришло на возникший таким образом рынок, и остались наиболее удачные. И так бы продолжалось и далее, но постепенно стало понятно, что моделирование - это, конечно, тоже важно, но между аналитиком, который рисует диаграммы (так как хорошо известно, что человеку удобнее работать с образами) и программистом, который на основе этих диаграмм осуществляет непосредственное программирование самих процессов, существует некоторая дистанция, преодоление которой неизбежно связано с ошибками – как вследствие простой невнимательности, так и обусловленной различием представлений программиста и аналитика о семантике используемой в диаграммах нотации и, соответственно, придаваемому диаграммам смыслу.
Отладка также непроста, но что самое неприятное, происходит постепенное – по мере разработки систем – рассогласование диаграмм и их реализаций.
Естественно, сразу же возник вопрос – а можно ли сделать так, чтобы диаграммы бизнес-процессов были сами же их реализациями? До определённой степени поставленную таким образом задачу решили Workflow-системы. Однако только до определённой степени, и вот почему.
Особенно на Западе, автоматизация предприятий велась давно. По мере совершенствования технологий оказывалось, что та или иная задача наконец-то может быть автоматизирована. Так автоматизировались всё более и более сложные части – и, наконец, количество начало переходить самым диалектическим образом в качество, и появилась возможность автоматизировать сквозные бизнес-процессы, то есть, фактически, автоматизировать целые функции предприятий. Но тут же выяснилась и главная трудность – системы-то разные, и многие из них весьма древние, унаследованные. А значит, именно интеграционная работа начинает выходить на первый план. Традиционные же Workflow-системы на интеграцию в большинстве своём не ориентированы.
В рамках архитектуры SOA любая система представляется как набор сервисов – однако такие сервисы не обязаны быть SOAP-ориентированными WEB-сервисами. Многие сервисы бывает просто нецелесообразно представлять в таком виде – например, когда происходит обмен большими объёмами данных, то передача их по протоколу SOAP будет подразумевать их представление в виде XML, то есть не только расходы процессорного времени на его обработку, но и, что много хуже, существенно большую нагрузку на каналы связи. Для таких сервисов реализуются специализированные адаптеры – например, адаптеры доступа к файлам, базам данных, ERP-системам, и многим другим информационным ресурсам. Впрочем, существуют стандарты разработки адаптеров “вообще” - например, JCA (Java Connector Architecture), и эти стандарты обычно поддерживаются BPEL-средствами.
Реализовать несколько сот связей между полутора дюжинами “островками автоматизации” - это не под силу знаменитому Average Joe, даже если он будет трудиться по ночам и выходным. Однако эту проблему решили в рамках архитектуры SOA (Service-Oriented Architecture), в рамках концепции единой информационной шины, что позволяет сократить число связей. Впрочем, эта проблема – не единственная, которая решается в рамках архитектуры SOA.
Итак, подведём некоторый промежуточный итог. Важными оказались: формализация бизнес-процессов, их наглядное представление, отождествление описания и реализации, возможность интеграции разнородных систем, единая информационная шина. Добавив сюда XML, веб-сервисы и ряд других стандартов, получаем новый стандарт BPEL.
Похожим образом рассуждали аналитики крупнейших компаний IT-индустрии, когда вели разработки и принимали различные стандарты описания бизнес-процессов. Некоторые стандарты были более удачными, некоторые – менее, однако именно по BPEL (более точно, BPEL4WS 1.1) индустрия достигла широкого консенсуса. BPEL “выстрелил” - появился совершенно новый рынок – рынок BPEL-ориентированных интеграционных средств.
BPEL – это не только могучее средство интеграции, но также и алгоритмически полный язык, система типов которого – это система типов XML; язык с весьма выразительными управляющими конструкциями, поддержкой параллельного исполнения, детальной обработкой исключений, поддержкой транзакций, взаимодействия процессов между собой и много чем ещё. Однако при всём при том BPEL довольно сильно ограничивает аналитика в некоторых вещах. Грубо говоря, BPEL не позволяет осуществить произвольную передачу управления внутри бизнес-процесса – нарисовать “стрелку-переход” между любыми двумя “квадратиками”, изображающими простые действия. В этом ограничении есть определённый смысл.
Ещё на заре развития программирования стало понятно, что идея произвольного перехода в программе является порочной.
Дейкстра выдвинул тезис о необходимости так называемого “структурного программирования”, то есть, фактически, отказа от использования оператора произвольного перехода GOTO в пользу циклов. Эта идея оказалась плодотворной, и с тех пор все основные языки программирования высокого уровня её реализуют. Настолько радикальным зачастую бывает представление о вреде GOTO, что язык попросту не содержит такой конструкции.
Интересной особенностью BPEL является механизм корреляций. Для того, чтобы понять, зачем он нужен, необходимо в первую очередь обратить внимание на то, что есть разница между описаниями процессов и их экземплярами – примерно такая же как между классами и объектами. Одному описанию процесса в каждый момент времени может соответствовать сколько угодно экземпляров процессов, и взаимодействие между экземплярами процессов может быть устроено довольно сложно. Однако как при взаимодействии определить, какой именно экземпляр процесса должен получить данные? Механизм корреляций позволяет декларативным способом описать правила поиска экземпляра по передаваемым данным. Наличие таких довольно тонких возможностей демонстрирует степень проработанности стандарта.
Бизнес-процессы могут подразумевать взаимодействие не только с информационными системами, но и с людьми. Более того, наивное представление о бизнес-процессах вообще не подразумевает ничего иного, кроме людей. Поэтому поддержка так называемых “human workflow”, то есть таких бизнес-процессов, которые бы описывали информационное взаимодействие именно между людьми, чрезвычайно важна.
Конечно, люди могут ничего другого не делать, кроме как набирать и редактировать XML-данные. Однако такой способ включения людей абсолютно неприемлем, и обычно в workflow-системах предусматривается некоторый специализированный интерфейс, представляющий те же самые данные в удобном для человека виде – что включает в себя много чего и, в принципе, допускает настоящее программирования представления информации.
В то время как технологические предпосылки определили конкретное историческое развитие данной технологии, политические тоже сыграли свою роль.
Считается порочным, когда предприятие функционирует “непрозрачным” способом (по крайней мере для собственника) – то есть когда невозможно, грубо говоря, взять лупу и внимательно рассмотреть каждый конкретный бизнес-процесс, когда существует какая-то тайна, кроме чётко ограниченной коммерческой. Считается также, что предприятие выигрывает, когда оно может легко входить и выходить из конфигураций, предназначенных для достижения конкретных экономических целей – а это подразумевает определённую унификацию того, как предприятия взаимодействуют друг с другом. Но и в таких конфигурациях тоже протекают бизнес-процессы, пересекающие границы предприятий.
Изменчивость во внешней по отношению к предприятию среде порождает изменчивость во внутренней, то есть непрерывная интеграционная работа становится отличительной чертой современного предприятия, и чем более оно включено во взаимодействие с другими предприятиями, чем быстрее темп отношений – тем более от успеха именно интеграционной работы начинает зависеть успех предприятия. Некогда проектировать, программировать и отлаживать; традиционное программирование становится всё менее пригодным для решения повседневных задач бизнеса. Необходимо сделать как-то так, чтобы аналитики могли сразу придумывать правильные процессы, и как можно быстрее запускать их в работу. Современные средства разработки для BPEL как раз это и обеспечивают.
Неудивительно поэтому, первые успешные внедрения BPEL оказались именно в сфере телекоммуникаций и финансов.
Компания Oracle предлагает готовое BPEL-ориентированное интеграционное решение Oracle BPEL Process Manager 10g. В состав этого решения входит средство разработки на базе Oralce JDeveloper 10g и сервер, который сам существует в двух вариантах. Первый вариант – для разработчиков, основан на Oracle Containers for Java (OC4J) и базе данных Oracle Lite.
Второй вариант – для промышленного использования, исполняется под управлением Oracle Application Server 10g и СУБД Oracle 10g. Кроме того, в поставку входит Worklist Application и BPEL Console. Последнее приложение предназначено для управлением процессами в реальном времени, их аудита и контроля.
См.
Исторически, это решение разрабатывалось независимой компанией Collaxa, которая впоследствии была приобретена. С тех пор решение сохранило ряд довольно полезных свойств, которые включают в себя независимость от сервера приложений (Oracle BPEL Process Manager может функционировать под управлением, например, JBoss и BEA Weblogic, а также некоторых других), а также специализированный plug-in для среды разработки с открытым исходным кодом Eclipse 3.0. В целом, можно ожидать, что индустрию BPEL-ориентированной интеграции ждёт большое будущее. Выгоды, которые получают предприятия от внедрения описанной технологии, весьма значительны – даже если относиться с некоторой долей скепсиса к её глобализационным перспективам – поскольку такие возможности как автоматизация партнёрских отношений, реализация композитных услуг являются важными конкурентными преимуществами, которые получают предприятия, внедряющие данную технологию. Для организаций государственного и муниципального управления внедрение данной технологии является частью реализации концепции электронного правительства.
II. Моделирование процессов с применением BPMN
В качестве стандарта для моделирования бизнес-процессов получает признание BPMN (Business Process Modeling Notation - нотация моделирования бизнес-процессов), разработанная организацией Business Process Modeling Initiative (BPME.org).
Основное назначение BPMN заключается в предоставлении нотации, легкой в использовании и понимании для бизнес-пользователей, включая бизнес-аналитиков, моделирующих бизнес-процессы, технических разработчиков, которые создают системы для выполнения этих процессов, и менеджеров различных уровней, которые должны быстро читать и понимать процессные диаграммы, чтобы принимать деловые решения.
BPMN напрямую отображается на языки исполнения бизнес-процессов, такие как BPEL и BPML. BPMN предоставляет нотацию для моделирования, а BPEL является языком описания исполнения процессов.
К ключевым особенностям BPMN относятся:
Пулы и лейны (Pools and lanes - бассейны и дорожки) — эти сущности используются для демаркации процессов и систем. Пул используется, чтобы разделить различные бизнес-сущности или участников. Действия (activities) внутри пулов – это модульные (self-contained) процессы. Лейны (Lanes) используются для описания и разделения действий в пулах (как бы водные дорожки в бассейне – прим.ред). Они, как правило, используются для группирования действий по функциям или ролям. События и действия (Events and activities) — События используются для представления того, что происходит в процессе бизнес-деятельности. У этих событий обычно есть причины/эффекты (следствия), и они могут влиять на сам поток. Действия ссылаются на работу, которая исполняется, либо как единая задача, либо как набор задач (подпроцесс). Соединенные объекты (Connect objects) — различные сущности BPMN могут быть соединены через последовательность операций, поток операций (sequence flow), чтобы отметить порядок, в котором действия выполняются, поток сообщений, чтобы отметить сообщения между сущностями, или ассоциацию, используемую для ассоциирования текста и других артифактов с объектами потока (flow objects). Проектирование сложного процесса (Complex process design) - BPMN может использоваться, как для высокоуровневого описания процессов, так и для описания сложных процессов со многими уровнями детализации.Процессы могут включать детализирующие представления (drill down views) для описания деталей более низкого уровня (lower levels of detail) внутри отдельных диаграмм. Моделирование и контроль сообщений (Model message and control) — в дополнение к спецификации порядка операций в потоке BPMN обеспечивает представление об объектах данных для моделирования того, как документы, данные и другие объекты используются и изменяются во время процессного потока. BPMN предоставляет нотацию моделирования, которая обеспечивает переход от бизнес-определений к карте исполнения процесса (process execution map). Объекты BPMN обладают богатым набором атрибутов, которые позволяют легко отображать эти объекты в описания BPEL, стандарт defacto для исполнения процессов. Нотация BPMN расширяема и позволяет использовать ассоциации и аннотации для установления взаимоотношений с другими артифактами внутри или вне вашей системы. Например, можно соотнести бизнес-процессы с функциями, которые они выполняют, с данными, которые они используют, с системами, на которых они развернуты, и т.д. Рассмотрим пример процесса LoanFlow (), который используется типичным брокером займов (loan broker). Этот брокер займов принимает запрос от клиента, выполняет кредитную проверку (credit check) с обращением к внешней службе и затем направляет это прошение к двум различным агентствам по предоставлению займов (loan agencies). После получения предложений от них лучшее будет отобрано и клиент будет уведомлен об этом.
На этапе моделирования обычно специфицируются участники (LoanBroker, CreditRating service, StarLoanService, UnitedLoanService и клиент). Процесс LoanFlow оркестрирует взаимодействия между этими сервисами. Для этого необходимо специфицировать последовательность событий и поток сообщений между этими сущностями, используя BPMN. иллюстрирует высокоуровневую модель процесса в BPMN и детализацию для подмножества этого процесса, когда соответствующий менеджер (loan offer) обращается к двум различным агентствам по предоставлению займов.
III. Имитация и анализ
Для выполнения имитации во время этого этапа жизненного цикла процесса должны быть сделаны следующие оценки: Время (период времени), необходимое для исполнения, и цена каждого действия Определены нужные для каждой задачи ресурсы Вероятность совершения различных событий или условий в потоке.
Эти оценки могут быть сделаны на основе исторических данных или, возможно, быть просто обоснованными догадками. После этого выполняется имитация, применяющая различные диапазоны вероятности и режимы заполнения новый событий. Эта имитация обычно помогает проанализировать процесс и получить такие сведения, как:
Вычислить среднее (average elapsed) время транзакции, полную, от начала до конца (end-to-end) пропускную способность и стандартные отклонения (deviation) для определения того, насколько эти отклонения соответствуют допустимым по соглашениям об уровне обслуживания SLA (Service Level Agreements); Идентифицировать “узкие места” при использовании процесса и ресурсов; Определить количественно человеческие и другие ресурсы, необходимые для завершения задач, чтобы соответствовать заданным SLA; Вычислить ожидаемые оценки ошибок и рейтинги уровней обслуживания по 6 сигма (six sigma); Определение оптимизации, необходимой для перехода процесса на уровень “как должно быть”;Продолжая пример LoanFlow из Секции II, можно смоделировать режим заполнения и время обработки прошений о займе для каждого агентства, о предоставлении займов, а затем “прогнать” имитацию, чтобы оценить пропускную способность или время ответа для сквозного потока. Также, если мы предположим, что есть некоторое, достаточное для выполнения этой задачи, количество агентов по займам в StarLoan и UnitedLoan, и мы зададим некоторое среднее время для обработки прошения о займе, то имитация поможет определить использование ресурсов и число нужных ресурсов на основе ожидаемых запросов на займы.
Интеграция OWSM и BPEL
Уильям Батерст,
27 Октябрь 2005 г
Источник: сайт Oracle Java Newsletter, август 2005,
IV. Документирование и внедрение
Во время этого этапа высокоуровневая модель процесса преобразуется в модель исполняемого процесса. До автоматизации процесса он, как правило, документируется в форме, которая может быть использована персоналом и партнерами. Этот документ включает информацию, которая определяет поток бизнес-процесса (business process flow), роли вовлеченных сущностей, исключительные ситуации, ожидания и требования к ресурсам. Все это нужно для будущей поддержки и улучшения процесса. И это также может помочь в достижении соответствия некоторым требованиям регулирующих органов.
Следующий после документирования шаг – это внедрение бизнес-процессов. Язык BPEL (Business Process Execution Language) становится очевидным стандартом внедрения для объединения множества синхронных и асинхронных сервисов в коллективные (collaborative) потоки и транзакции. При разработке BPEL воспользовались результатами более чем десяти исследований его предшественников – языков XLANG и WSFL. Он включает следующие концепции:
Web Services/WSDL - как компонентная модель XML - как модель данных Шаблоны синхронного и асинхронного обмена сообщениями Детерминированная и недетерминированная координация потока Иерархическое управление исключительными ситуациями Долгоживущая единица работы/компенсации (Long-running unit of work/compensation) Oracle BPEL Designer предоставляет графический и дружественный интерфейс для построения BPEL-процессов. Что выделяет Oracle BPEL Designer – так то, что BPEL – это его “родной” формат. Это означает, что процессы, построенные с применением этого инструмента, 100% переносимы, и, кроме того, он позволяет разработчикам просматривать и модифицировать исходный код на BPEL, не снижая полезности этого инструмента.Если высокоуровневый процесс смоделирован на BPMN, он прежде всего экспортируется к скелетному (skeletal) BPEL-процессу, который как правило, состоит из областей действия процесса (process scopes), действий по вызову/получению (invoke/receive activities) и партнерских связей к соответствующим сервисам (partner links to the appropriate services).
Следующие шаги должны быть выполнены в Oracle BPEL Designer, прежде чем данный процесс может быть развернут:
Идентифицирование операций web-сервисов, которые вызываются различными сервисами; Специфицирование типов XSD для сообщений, которыми обмениваются различные сущности; Моделирование карты трансформаций для различных типов сообщений, посылаемых и получаемых из различных систем; Специфицирование положения конечных точек (endpoint) и параметров соединения для вовлеченных сервисов.Если мы рассмотрим пример LoanFlow, описанный ранее, то для кода на BPEL, сгенерированного из средства моделирования BPMN, потребуется включение URL для этих сервисов, XSD для прошения об займе и предложения займа, а также определение трансформаций данных между документами, которые передаются между сервисами. показывает процесс LoanFlow, смоделированный в Oracle BPEL Designer.
IX. Заключение
BPM-системы полного цикла критичны для разработки эффективных бизнес-процессов, которые должны быстро реагировать на изменяющиеся бизнес-условия. Oracle AS Integration – это в настоящее время наиболее полная BPM-платформа на рынке. Она обеспечивает реализацию всего жизненного цикла процесса, включая моделирование, имитацию, внедрение, исполнение, мониторинг и оптимизацию бизнес-процессов.
А Вы попробуйте без Goto
litnimах, Сбт 09 Фев 2008 14:16:15: > Споры о GoTo ведуться давно
А Вы попробуйте без Goto смоделировать шаблон Arbitrary Cycles - http://www.workflowpatterns.com/patterns/control/structural/wcp10.php Litnimах, Срд 30 Янв 2008 14:36:52: > В частности, меня например напрягает накручивать сложное переплетение из IDEF и UML
А не надо это делать. Смотрите BPMN, и открытый продукт Intalio BPMS designer.
Не сказано по-моему, главное - BPEL - самодостаточный язык очень высокого уровня, бизнес-уровня. Он не нуждается в других языках, реализующих интерфейсы низкого уровня. Связка BPMN + BPEL позволяет разворачивать реальную сквозную автоматизацию, не прототип, прямо на глазах у менеджеров в процессе описания модели. Кирилл, Втр 29 Май 2007 16:37:03: 2аноним
UML в рамках RUP применяется в том числе и для описания бизнес-процессов.
А в чём уникальность BPEL я уже и сам вразумел. Это очередная парадигма отображения бизнес-процессов -- в данном случае сервисо-ориентированная. В этом смысле BPEL конечно интересен. Но ничего не ясно как люди могут включаться в процесс. Все примитивы BPEL касаются только сервисов и их взаимодействий, но нет и намёка на людей, исполнительные механизмы, различные хранилища данных. Можно конечно и человека как сервис включить в модель :) Хотя возможно я пока слишком поверхносно познакомился с возможностями методики. Но уже ясно одно -- BPEL не является универсальным решением. В частности, меня например напрягает накручивать сложное переплетение из IDEF и UML, к тому всё равно в конце концов возникают проблемы взаимодействия с реляционными БД. Я думал BPEL позволяет всё это делать в рамках единой методологии. аноним, Втр 29 Май 2007 16:10:59: >>В чём вообще уникальность BPEL?
>>Чем плохи традиционные старые методы
>>бизнес-моделирования (IDEF разные, UML)?
BPEL - для управления бизесс-процессами, это наподобие языка программирования. по-моему и есть язык программирования
BPEL - Bisness Process Execution Language
у IBM используется в сервисно-ориентированной архитектуре SOA
а UML вообще-то совсем для другого - для визуального моделирования разработки софта применяется
>когда происходит обмен большими объёмами данных,
>то передача их по протоколу SOAP будет
>подразумевать их представление в виде XML, то
>есть не только расходы процессорного времени на
>его обработку, но и, что много хуже, существенно
>большую нагрузку на каналы связи.
не совсем так, зависит от того, как представляются данные Кирилл, Пнд 28 Май 2007 12:39:57: Складывается впечатление, что очередная пурга, написанная автором для повышения количества статей. О BPEL вообще ничего нет. В чём вообще уникальность BPEL? Чем плохи традиционные старые методы бизнес-моделирования (IDEF разные, UML)? Как решаются в рамках BPEL проблема объектно-ориентированного маппинга? Max, Вск 27 Май 2007 19:45:59: Споры о GoTo ведуться давно. И однобоко представлять, что изгнание этого механизма из ЯП это неоспоримое благо. Можно привести множество аргументов за GoTo. Вывод: не GoTo, а догматизация или демонизация его есть вред. Кроме того, спорна и сама концепция Дейкстра с его структурным программированием. Ведь там в угоду простоте выплескивают вместе с "водой" и "ребенка" - душу программирования - работу с именами, в частности вычислимыми.
Далее. Если уж говорить о вреде произвольного перехода, то операции циклирования не менее вредны. Ведь они изначально ориентированы на "замкнутость в актуальностях", т.е. на абсолютную централизацию - когда и сама операция циклирования и "тело цикла" выполняются на одном узле. Сегодня же догматизировать это - значит закрывать глаза на распределенность. Интересно, что в этом отношении сделано в Oracle BPEL? Какие модели применяются? Насколько данный продукт сохраняет инвестиции в него вложенные? Беренцев Антон, Чтв 10 Май 2007 10:31:53: Хороша в качестве введения. Легко и доступно читается. Хотелось бы больше конкретики по Oracle BPEL. Комментарии заморожены.
| |
|
| Уникальный продукт, не имеющий аналогов, . Застывает через несколько часов. | © 2004–2009 Проект CITCITY.ru |
Полный цикл управления бизнес-процессами с применением инструментов, поддерживающих стандарты
Bhagat Nainani, перевод
12 Октябрь 2005 г
Оригинал: , An Oracle White Paper, ноябрь 2004
V. Развертывание и исполнение
Наиболее критичным этапом в жизненном цикле процесса является его развертывание на платформе, которая может оркестрировать поток и выполнять различные задачи этого процесса. Оркестрирование набора сервисов в сквозной поток процесса требует выполнения множества технических требований, включая соединение (binding) с разнородными системами, шаблоны для синхронного и асинхронного обмена сообщениями, манипулирование данными, координация в потоке, управление исключительными ситуациями, недетерминированные события, компенсирующие транзакции (compensating transactions), управление версиями, и т.д. Назначение стандарта BPEL – обеспечение более богатого, но в то же время более простого уровня абстракции/стандарта для удовлетворения этих требований. Продукт Oracle BPEL Process Manager обеспечивает наиболее зрелую, масштабируемую и полную реализацию механизма исполнения BPEL, доступную сегодня. Некоторые из ключевых функций этого сервера: Поддержка стандартов — механизм включает непосредственную поддержку стандартов BPEL и web-сервисов; Производительность и масштабируемость – высокопроизводительный BPEL-механизм исполняет одновременно множество BPEL-процессов и обеспечивает возможность “отжимки” ("dehydration"), так что состояние долгоживущих потоков автоматически поддерживается в базе данных. Возможно применение кластеров для обеспечения масштабируемости и отказоустойчивости; Продвинутые функции – другие важные функции включают автономную работу с версиями, секционирование процесса и продвинутое управление исключительными ситуациями; Множество платформ развертывания - BPEL Server использует OC4J как базовый J2EE-сервер приложений с поддержкой большинства основных коммерческих серверов приложений; Встроенные сервисы интеграции — они позволяют использовать продвинутые возможности соединений и трансформаций из стандартного BPEL-процесса. Эти возможности включают поддержку для трансформаций и соединений с использованием механизма XSLT/Xquery, а также множества тиражируемых приложений и унаследованных систем . Расширяемая схема соединения WSDL обеспечивает соединения по протоколам и форматам сообщений, другим нежели SOAP. Соединения доступны для JMS, электронной почты, JCA, HTTP и многих других протоколов для связи с сотнями внутренних (back-end) систем. Сервис пользовательской задачи (User task service), предоставляется как встроенный BPEL-сервис для обеспечения интеграции людей и выполняемых ими вручную задач в BPEL-потоки. BPEL Console предоставляет web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживаются данные аудита и информация истории процесса и отчетов, и все это доступно через BPEL Console и Java API.
На показана архитектура BPEL Process Manager и сопутствующих компонентов.
VI. Мониторинг
Измерение ключевых метрик процессов и “видимость” (visibility) в реальном времени исполнения процессов критичны для оценки производительности развернутых бизнес-процессов. Oracle Business Activity Monitoring (BAM) – это критичный компонент нашего полного BPM-решения.
BPEL-процессы могут быть инструментированы с датчиками (sensors), чтобы осуществлять мониторинг критических действий и переменных. BAM позволяет соединять эти индивидуальные метрики в составные события. Панель BAM позволяет реализовать мониторинг, анализировать и своевременно отвечать на события или исключительные ситуации, которые происходят внутри предприятия.
Ключевые концепции Oracle BAM таковы:
Бизнес-события (Business Events) – перехват таких интересных событий как изменение информации о клиентах, изменения в описи товаров, заказах на покупку из широкого ряда информационных систем предприятия (EIS). Составные события (Composite events) – определение, агрегирование, соотнесение и фильтрация событий от различных конечных систем. Метрики и ключевые индикаторы эффективности (КПЭ или KPI) – выполнение сложной обработки составных событий для генерации метрик и КАЭ. Сигналы (Alerts) – уведомление пользователей через различные каналы (электронная почта, голосовая почта, пэйджеры,..) на основе превышения пороговых значений и/или порогов рисков для некоторых ключевых метрик. Визуализация в масштабе реального времени - широкий набор средств визуализации в масштабе реального времени на BAM-панели для показа данных самых последних событий и детализации при анализе основных факторов.См.
Продолжим наш пример с LoanFlow из Секции II . После того, как процесс развернут, BAM-панель может быть использована, чтобы ответить на критические бизнес-вопросы:
(a) Запросы на займы, предоставленные сегодня, на этой неделе, в этом месяце. (b) Предложения займов по агентствам (c) Среднее время обработки одного займа (d) средняя кредитная оценка (скоринг) лиц, желающих получить заем.Также BAM-панель может отобразить сигналы:
(a) были предоставлены займы многим лицам с низкой скоринговой оценкой (b) процент отвергнутых прошений о займах больше 10%.Последний факт можно использовать для переоценки критериев отбора или для того, чтобы предпринять некоторые предупредительные действия. Рисунок 6 показывает BAM-панель с некоторыми ключевыми метриками для процесса LoanFlow.
VII. Оптимизация и перепроектирование
BAM закрывает отсутствующее звено между исполнением процесса и перепроектированием. Традиционно имитация процессов основана на предположениях и догадках. Проблема такого подхода в том, что надежны только результаты, а предположения делались на этапе моделирования. При применении BAM, как данные реального времени, так и исторические данные, накопленные за период времени, могут быть использованы, чтобы промоделировать процесс “как есть” (“as-is”) и создать оптимальный процесс “как должно быть” ("to-be"). Благодаря таким успешным итерациям процесс может быть тонко настроен, что приведет к значительной экономии ресурсов и средств.
События в BAM также могут быть использованы для оптимизации развернутых процессе в реальном времени, благодаря изменениям потока бизнес-процесса. Сигналы (alerts) BAM также могут начать новые бизнес-процессы для обработки исключительных ситуаций или быть использованы для прерываний процессов.
Еще раз рассмотрим пример LoanFlow. На этапе оптимизации должны использоваться данные реальной обработки на основе ежедневных/ежемесячных отчетов и затем прогоны инструмента имитации для обнаружения возможных узких мест и уровней обслуживания (predict SLA). Это может привести к перепроектированию процесса. Например, к добавлению новых сервисов при оформлении займа, что соответствовать требованиям по времени ответ. Некоторые из этих метрик также могут использоваться в реальном масштабе времени. Например, если какое-то из агентств слишком долго не отвечает, процесс может продолжать работу только с одним предложением займа (применительно к одному агентству), чтобы удовлетворить SLA-требованиям обслуживания.
VIII. Партнеры
Корпорация Oracle установила партнерские отношения с рядом поставщиков, чтобы предоставить средства моделирования и имитации вместе с Oracle BPEL Process Manager и инструментом Oracle Business Activity Monitoring. В число этих поставщиков входят Popkin Systems and Software Ltd () — продукты Popkin System Architect и Popkin Simulator II могут быть использованы для моделирования и анализа процессов. При этом применяется BPMN и экспорт в формате BPEL для развертывания на платформе Oracle.
За более подробной информацией о моделировании процессов с использованием этих средств, их внедрении и развертывании с Oracle BPEL Process Manager, обращайтесь по адресу
Защита потоков BPEL-процессов
Одной из возможностей Oracle Web Service Manager Оракула является способность защитить потоки BPEL-процессов. OWSM защищает BPEL, используя PEP (Gateway Policy Enforcement Point – Шлюзовая точка претворения политики), в который перехватываются SOAP-запросы и выдаются ответы в различные точки BPEL-процесса. Даайте рассмотрим демонстрационный пример Loanflow, приведенный в учебнике BPEL 101 Tutorial, чтобы проиллюстрировать, как OWSM защищает BPEL-процессы. BPEL-пример Loanflow демонстрирует автоматическое получение банковской ссуды:
Заявитель представляет банку на рассмотрение свою заявку. Банк проводит кредитную проверку заявителя ссуды и получает оценку его кредитоспособности. Если эта оценка хорошая, то банк направит заявку двум кредитным бюро и выберет лучшее для клиента предложение.В этом демонстрационном примере “оценка кредитоспособности” - синхронный Web-сервис. BPEL-процесс будет ждать ответ от этого кредитного сервиса перед переходом к следующим шагам. Затем демо-пример начинает параллельный диалог с двумя асинхронными сервисами обработки ссуд (Star Loan и United Loan).
Диаграмма 1. Демонстрационный BPEL-пример Loanflow
Этот сценарий интересен тем, что в нем смоделирован бизнес-процесс, который обращается с конъюнктурные данными (например, номер [карточки] социального обеспечения), но этот бизнес-процесс не защищен. Мы же видим, что:
Нет никакой авторизации или аутентификации, обязательно представляемых каждой заявкой. Номер Social Security ([карточки] социального обеспечения) заявителя представлен в открытом коде. Очень важна проверка достоверности сообщения. Например, может статься, что любая ссуда запрашивает свыше ста тысяч долларов. К BPEL web-сервисам можно обратиться по интернету. Если запрос сначала проходит шлюз, то они должны быть виртуализированы и уже доступны. Нет никакой журнализации или представления трафика сообщений в течение всего потока.См.
Этот пример показывает насколько мощной может стать комбинация BPEL и OWSM.
OWSM усиливает BPEL за счет:
Контроля Доступа (Access Control)
BPEL- процесс может быть защищен, если перед ним поставить шлюз. Только аутентифицированние/авторизированные (authenticated/authorized) пользователи могут начать поток [получения] ссуды. Например, если перед BPEL-процессом находится COREid-шлюз политики аутентификации/авторизации (authentication/authorization), то он позволит проход только привилегированным пользователям. Контроль доступа может также быть применен для отдельных сервисов BPEL-процесса.
Частичного/полного шифрования сервисных запросов (Partial/full encryption of service calls)
Клиент, посылающий запрос к BPEL-процессу, может послать зашифрованное сообщение, и BPEL-процесс должен быть способен расшифровать это сообщение в некоторой точке BPEL-процесса, когда это будет необходимо. BPEL-процесс должен поместить шлюз перед сервисом, который должен получить расшифрованное сообщение.
Клиент имеет возможность послать зашифрованное сообщение, которое должно быть расшифровано в некоторый момент в BPEL-процессе. Если вернуться к демо-примеру Loan, клиент может послать зашифрованное сообщение BPEL-процессу. Web-сервис Loan Flow BPEL-процесса получает зашифрованный запрос. На следующем шаге нужно вызвать сервис, который даст кредитную оценку. Поэтому желательно поместить шлюз, который может расшифровать сообщение, перед этим - Credit Rating Service - сервисом.
DMZ-виртуализации асинхронных BPEL-сервисов (DMZ Virtualization of asynchronous BPEL services)
Архитекторы служб безопасности и web-сервисов часто хотят виртуализировать возврат (callback) к BPEL-процессам. Это означает то, что клиент не должен непосредственно общаться с BPEL-процессом. Вместо этого, возвраты должны проходить через некий модуль доступа (proxy) и только затем быть соответственно маршрутизированы (route). Для подобных запросов OWSM может установить режим шлюза (Gateway mode) и proxy-модуль. Одновременно OWSM также может выполнять и другие интеллектуальные задачи обработки, как-то: проверка достоверности сообщений (message validation), регистрация (logging) и применение дополнительных политик безопасности (extra security policies).
Мониторинга (Monitoring)
OWSM-шлюз, который защищает BPEL-процесс, посылает свои данные OWSM-монитору. ИТ-служащие могут использовать монитор, чтобы увидеть в реальном времени в общее состояние, производительность и безопасность BPEL-процесса. Например, по диаграммам аутентификации/авторизации они узнают, какие BPEL-процессы совершили попытки несанкционированного доступа. Используя монитор, ИТ-служащие могут задать правила мониторинга и автоматически получать алерт-сигналы по электронной почте, когда имеют место определеные состояния.
