Источник: http://www.oracle.com/technology/pub/articles/bpel_cookbook/geminiuc.html
Статья 1 из серии "SOA Best Practices: The BPEL Cookbook" - "Лучшие методы SOA: Кулинария BPEL" ( http://www.oracle.com/technology/pub/articles/bpel_cookbook/index.html )
Изучите концепции продвинутого BPEL и лучшие методы развития, развертывания, и администрирования сервис-ориентированной архитектуры, представленные и осуществленные их архитекторами в реальных практических приложениях.
Сервис-ориентированной архитектуры (SOA - Service-oriented architecture) является совокупностью новых стандартов, предлагающих более открытое и гибкое решения старой проблемы интеграции существующих приложений в новые сложные приложения. Процесс внедрения SOA выполняется в два этапа: сначала вы разбиваете свои существующие приложения на многократно используемые сервисы, а затем вы можете "оркестровать" ("orchestrate") их в гибкие бизнес-процессы.
Чтобы содействовать ускорению внедрения SOA, OTN собрал специально написанные статьи лидеров по SOA и BPEL в эту серию "Лучшие Методы SOA: Кулинария BPEL". В каждом выпуске вы познакомитесь с тем, как автор успешно применил BPEL, чтобы ответить на реальный ИТ-вызов - от применения бизнес-правил до порождения BPEL-процессов на лету, до объединения BPEL с традиционной EAI (Enterprise Application Integration - интеграция прикладных систем предприятия) на среднем уровне (middleware).
Мы приветствуем ваши комментарии и вопросы по этим статьям на Дискуссионном форуме BPEL Discussion Forum. Если у вас есть какой-либо личный опыт работы с BPEL, которым вы бы хотели подеплиться с OTN-сообществом, пожалуйста сообщите нам на этом форуме.
И конечно, если вы заинтересованы в тестировании Oracle BPEL Process Manager, то вы можете загрузить его копию <http://www.oracle.com/technology/software/htdocs/devlic.html?url=/technology/software/products/ias/ bpel /index.html> и запустить ее меньше чем за 15 минут.
Edwin Khodabakchian, VP, BPEL Development
Dave Shaffer, Director Product Management, Oracle BPEL Process Manager
Harish Gaur, Principal Product Manager and "BPEL Cookbook" Editor
Markus Zirn, Director, Strategic Customer Program
Состав серии:
Часть 1. Cервис-ориентированный подход в разработке бизнес-правил (A Services-Oriented Approach to Business Rules, by Kevin Geminiuc, Senior Software Architect, Policy Studies Inc)
Как сократить расходы на сопровождение и улучшить организационную гибкость благодаря сервис-ориентированному подходу к разработке бизнес-правил и управлению
Часть 2. Построение сети web-сервисов с применением BPEL (Building a Web Services Network with BPEL by Yves Coene, Project Manager, Spacebel s.a.; and The Hoa Nguyen, Senior Software Engineer, SDC).
Пример, как Европейское Космическое Агентство использовало возможности и домены< BPEL и< API Oracle BPEL Process Manager для построения дружественной к партнерам сети web-сервисов.
Часть 3. Создание в динамике BPEL-процессов (Making BPEL Processes Dynamic, by Sean Carey, Architect, SPS Commerce)
Как обеспечить динамическое построение посредством манипуляции ссылками конечных точек (endpoint references) во время функционирования.
Часть 4. Использование WSIF-интеграции (Using WSIF Integration, by Matjaz B. Juric, University of Maribor)
Как BPEL-процессы могут естественным образом получить доступ к Java-классам, EJB- и другим J2EE- ресурсам, используя WSIF.
Часть 5. Добавление BPEL в структуру производственной интеграции (Adding BPEL to the Enterprise Integration Mix, by Praveen Chandran and Arun Poduval, Infosys
Усиление оркестровых возможностей Oracle BPEL Process Manager для обеспечения основанного на стандартах процесса бизнес-интеграции, что дополняет традициюнную EAI (Enterprise Application Integration - интеграция прикладных систем предприятия) на среднем уровне (middleware).
Часть 6. Построение мощных Интернет-приложений для потока работ и мониторинга процессов (Building Rich Internet Applications for Workflow and Process Monitoring, by Doug Todd, CTO, Enterra Solutions)
Создание в реальном масштабе времени потока работ (workflow) и инструментальной панели (dashboard) для расширенного мониторинга активности процессов при расширении API Oracle BPEL Process Manager.
Часть 7. Построение на лету BPEL-процесса (Building BPEL Process on the Fly, by Jerry Thomas, Chief Architect, Centerstone Soft)
Как сгенерировать на лету BPEL-процесс, трансформируя посредством XQuery параметры хранения в базе данных, которые находятся в XML файле определения BPEL
Часть 8. Интеграция PeopleSoft CRM с Oracle E-Business Suit, используя BPEL (Integrating PeopleSoft CRM with Oracle E-Business Suite Using BPEL, by Lawrence Pravin, Product Manager, Process Integration Packs, Sierra Atlantic Inc.)
Пошаговое решение для интеграции PeopleSoft 8.9 CRM с Oracle Applications 11 i, используя BPEL
Часть 9. Управление производственной средой BPEL (Managing a BPEL Production Environment, by Stany Blanvalet, BPEL and J2EE consultant)
Как автоматизировать общие административные задачи в производственной среде BPEL, используя API BPEL Process Manager и Dehydration Store
Часть 1. Cервис-ориентированный подход в разработке бизнес-правил
Из предлагаемой первой части серии статей "Лучшие методы SOA: Кулинария BPEL" вы узнаете, как сократить расходы на сопровождение и благодаря ориентированному на сервисы подходу к разработке бизнес-правил и управлению улучшить организационную гибкость.
|
Загрузите для этой статьи |
Многие организации от объектно-ориентированной парадигмы управления бизнес-процессами движутся в направлении к сервис-ориентированному подходу; несомненно, сервисы становятся фундаментальными элементами разработки приложений. В то же самое время, язык выполнения бизнес-процессов (Business Process Execution Language - BPEL) стал фактическим стандартом для оркестровки этих сервисов и управления безупречным выполнением бизнес-процессов. Слияние этих тенденций представляет некоторые интересные возможности для более гибкого и рентабельного управления бизнес-процессами.
Большинство бизнес-процессов - хорошим примером являются процессы принятия решения о выдаче ссуды - содержат много точек принятия решений. В этих точках для принятия решения оцениваются некоторые критерии. Базируясь на этих критериях, или бизнес-правилах, бизнес-процессы изменяют свое поведение. В сущности, эти бизнес-правила управляют бизнес-процессом. Часто правила включаются непосредственно в состав бизнес-процесса или в заказной код на Java, что может вызвать в будущем несколько проблем:
- Бизнес-правила изменяются чаще, чем сами процессы, но изменение и управление встроенными бизнес-правилами является сложной задачей, выходящей за пределы возможностей большинства бизнес-аналитиков. Таким образом, при изменении бизнес-правил программистам часто приходится тратить на решение этой задачи дорогое время.
- Большинству организаций недостает центрального репозитория правил. Следовательно, любое изменение в политике в масштабе всей организации не может быть применено ко всем бизнес-процессам.
- Бизнес-процессы не могут многократно использовать правила. Следовательно, персоналу службы ИТ приходится проектировать правила для каждого процесса, что часто приводит к несогласованности или избыточности.
Лучший способ избежать этих проблем состоит в том, чтобы использовать для отделения бизнес-процессов от бизнес-правил машину правил . При таком подходе правила предъявляются как сервисы, и процессы BPEL, когда они достигают точек принятия решений, используют эти сервисы, задавая запросы к машине. Этот подход намного более гибок - вместо того, чтобы кодировать правила в языках программирования или в процессе, правилами можно управлять графически. Бизнес-пользователи с соответствующими инструментальными средствами могут писать правила сами и проводить изменения после развертывания без помощи сотрудников службы ИТ. Если большинство обновлений и усовершенствований делают сами бизнес-пользователи, стоимость сопровождения может существенно снизиться.
Машины правил и BPEL являются дополняющими друг друга технологиями. Диспетчер процессов Oracle BPEL предлагает инструментальные средства высокого уровня для визуализации, проектирования и управления потоками процесса BPEL, тогда как машины правил от третьих фирм позволяют выразить усложненную бизнес-логику на языке с синтаксисом, подобным английскому, и редактировать ее специалистам в проблемной области, не являющимся программистами.
В предлагаемой первой части "Поваренной книги, или Кулинарии BPEL" я хочу предложить лучшие методы для разделения процессов и правил, базирующиеся на накопленном моей группой опыте. Используя примеры программного кода, я также предложу подход к разработке и изменю стратегию управления для интеграции BPEL с машиной правил. И, наконец, я объясню, как эта архитектура приводит к надлежащему разделению логики между различными уровнями.
Отделение правил от процессов
Интеграция машины правил с инфраструктурой управления процессами требует некоторых предварительных инвестиций. Прежде чем попытаться выполнить такую интеграцию, важно провести разделительную линию между правилами и процессами. Следовательно, главный момент принятия решения в архитектуре системы заключается в том, как реализовать бизнес-политику, бизнес-процессы и поддерживающую бизнес логику. Действительно, архитектор должен сообщить или изобрести лучшие методы, так чтобы проектировщики, проектируя системные функциональные возможности, знали, где должна быть применена каждая из релевантных технологий - BPEL, бизнес-правила и сервисы Java/Web.
Как изображено на рисунке 1, бизнес-логика распределена между тремя различными уровнями инфраструктуры ИТ: бизнес-процесс, Web-сервис и правила. Давайте по очереди обратимся к каждому из них.
Рисунок 1 Архитектура: отделение правил от процессов
Уровень бизнес-процесса. Этот уровень несет ответственность за управление всем выполнением бизнес-процесса. Такие бизнес-процессы, реализованные с использованием BPEL, могут быть долго выполняющимися, транзакционными и постоянными. Логика процесса поддерживает транзакции высокого уровня ("саги") через вызовы Web-сервисов/EJB, а также вложенные транзакции подпроцесса. Машина BPEL поддерживает аудит и инструментовку технологического процесса и таким образом хорошо подходит для
- Отделения менее изменчивых шагов технологического процесса от более изменчивых бизнес-правил
- Реализации процессов для различных сфер деятельности
- Реализации потоков процесса, требующих компенсации
- Поддержки крупномасштабной реализации потоков процесса
- Проектирования потоков процесса, которым требуется аудит
- Оркестровки гетерогенных технологий, типа коннекторов, Web-сервисов и логики, поддерживающей Web Services Invocation Framework (WSIF - инфраструктура вызова Web-сервисов)
Уровень Web-сервисов. Уровень Web-сервисов заявляет имеющиеся функциональные возможности прикладного уровня как сервисы. В таком случае много бизнес-процессов могут многократно использовать эти сервисы, выполняя, тем самым, обязательства сервис-ориентированной архитектуры (SOA).
Web-сервисы реализуют функциональную логику и логику предметной области. Функциональные методы обычно не меняют своего состояния в процессе исполнения (stateless) и являются среднезернистыми (medium-grained). Web-сервисы могут, к примеру, содержать сервисные методы, операции с объектами и запросные методы для системных данных. Вы можете реализовывать Web-сервисы, используя многие технологии, и скрывать различия между платформами реализации. Таким образом, этот уровень хорошо подходит для:
- Реализации среднезернистых методов для конкретной области объекта/домена
- Интеграции унаследованных программных кодов/инструментальных средств от третьих фирм
- Инкапсуляции логики, заказного кода и реализации на прикладном уровне
Уровень правил. Машина правил обычно является домом (местом хранения) для сложной логики, которая использует множество взаимозависимостей между объектами и зависящие от порядка логические вычисления. Выделение бизнес-правил как отдельного от бизнес-процесса объекта приводит к лучшему разъединению системы, что впоследствии увеличивает удобство сопровождения.
Машины правил позволяют вычислять наборы правил параллельно и в последовательном порядке. Кроме того, правила имеют возможность вычислять значения входных и промежуточных данных и определять, должно ли сработать правило. Такой модульный дизайн обеспечивает более простое и более удобное в сопровождении решение, чем традиционный процедурный код Java.
Кроме того, как я упоминал ранее, правила декларативны и позволяют бизнес-аналитикам редактировать графический интерфейс пользователя на высоком уровне. Современные машины правил выполняются чрезвычайно быстро и обеспечивают встроенную регистрацию аудита. Типичные черты уровня правил:
- Содержит объединенную и сложную логику
- Поддерживает эффективное вычисление бизнес-логики, используя параллельное выполнение
- Содержит сложную структуру возврата, построенную на основании многократных вычислений бизнес-правил
- Разрешает трансляцию логики домена в простые правила
- Реализует очень подвижную бизнес-политику
Поскольку в уровне Web-сервисов правила предъявляются как сервисы, они могут быть многократно использованы для всех межкорпоративных приложений, упрощая разработку и интеграцию новых приложений.
Разработка и сопровождение
Чтобы проиллюстрировать процесс разработки, мы будем использовать пример бизнес-процесса, который называется Eligibility Process (процесс приемлемости). Этот процесс оценивает, годится ли семья для участия в определенной программе здравоохранения. В зависимости от атрибутов семьи (доход, общее число детей), этот процесс относит семью к Программе Здравоохранения 1 или к Программе Здравоохранения 2. Во время фазы анализа логика группируется в различные блоки в зависимости от ее изменчивости и сложности. Как обсуждалось в предыдущем разделе, правила обычно моделируют сложные возвращаемые структуры, требующие многократных бизнес-проверок правильности, а также политики, которые часто изменяются или затрагивают большие части организации. Напротив, процессы для подразделений или отдельных организаций моделируются в уровне бизнес-процесса.
Типичный процесс разработки включает три шага:
- Создайте правила в наборе правил
- Предъявите набор правил как Web-сервис
- Вызовите Web-сервис набора правил из BPEL
Для завершения этих задач (см. рисунок 2) в фазе разработки требуются специализированные роли, типа ролей разработчика правил, разработчика потока процесса, бизнес-аналитика и разработчика Web-сервисов.
Рисунок 2 Роли при разработке и сопровождении
1. Создайте правила в наборе правил. Фаза разработки начинается с того, что разработчик правил создает первоначальные правила в интегрированной графической среде разработки, типа системы управления бизнес-правилами ILOG JRules. (Для получения информации о функциональных возможностях бизнес-правил в Oracle Fusion Middleware см. врезку .)
|
Машина правил Oracle Fusion Middleware Этот пример иллюстрирует интеграцию машины правил ILOG с диспетчером процессов Oracle BPEL, но обратите внимание, что в будущих выпусках Oracle Fusion Middleware с диспетчером процессов Oracle BPEL будет интегрирована новая, "родная" машина бизнес-правил. Мастер сервиса принятия решений (Decision Service wizard) в проектировщике Oracle BPEL позволит пользователям включать бизнес-правила в проект BPEL. Он будет включать возможность просматривать репозитории бизнес-правил Oracle, а также машины правил от третьих фирм. Кроме того, пользователи будут в состоянии отобразить переменную BPEL на факты (данные) в репозитории правил, а также утверждать новые факты и выполнять правила. Тогда машина BPEL автоматически выполнит любую трансляцию формата из переменных на базе XML в базирующиеся на Java типы данных для фактов машины правил. После развертывания бизнес-пользователи будут способны обратиться к правилам, связанным с бизнес-процессом, и делать изменения, не развертывая процесс повторно. Такой подход очень упростит интеграцию процессов BPEL с машинами правил и увеличит гибкость архитектуры. |
Перед тем, как приступить к созданию правил, должны быть подготовлены репозиторий правил и объектная модель. Репозиторий правил позволяет вести сопровождение и управление бизнес-правилами на протяжении всего их жизненного цикла. Проблемная область, которой управляют бизнес-правила, выражается с помощью ILOG JRules в форме объектной бизнес-модели (Business Object Model - BOM). BOM представляется через классы Java или схему XML, представляющие исполняемую версию модели. XML Schema может помочь добиться быстроты перестройки данных. Детализированная реализация объектной модели обычно является задачей разработчиков.
После того как разработчики создали объектную модель и репозиторий правил, вы должны решить, какие правила будут обслуживаться аналитиками, а какие должны быть разработаны на языке низкого уровня (информационно-поисковый язык). После создания правил уровня разработчика разработчики проводят работу с аналитиками, чтобы идентифицировать остающиеся правила и загнать их в шаблоны правил, которые могут быть многократно использованы многими нетехническими сторонами. Этот метод упрощает и ускоряет продуцирование правил и уменьшает влияние так называемого человеческого фактора (ошибок оператора).
Чтобы запустить процесс создания правил на основе шаблона, аналитик подключается к репозиторию правил. Когда он (или она) из репозитория открывает пакет правил, они получают доступ к соответствующей BOM. ILOG поддерживает определение правил высокого уровня с помощью собственного языка бизнес-приложений (Business Application Language - BAL). В этот момент аналитик может редактировать существующие правила или создать новые. В течение фазы сопровождения правила могут быть изменены с помощью шаблона, что ограничивает, какие модификации могут быть произведены с правилами.
Редактор правил имеет шаблон по умолчанию и позволяет разработчику создавать условия и действия, используя конструкцию IF - THEN. Как показано на рисунке 3, бизнес-аналитик создает правило, которое проверяет общее количество детей в семье. Если эта переменная равняется 2, то семья получает квалификацию для Программы Здравоохранения 1. Правило возвращает значение true в типе данных eligibilityResult .
Рисунок 3 Создание правила, которое проверяет общее количество детей в семье
После того, как новое правило разработано, оно может быть протестировано на образцах данных с помощью инструментального средства ILOG Rule Builder. Этот отладчик в Rule Builder поддерживает контрольные точки, позволяет пользователям просматривать данные в рабочей памяти и отображает порядок выполнения правил. Когда редактирование и тестирование правила заканчивается, аналитик экспортирует пакет правил в набор правил и возвращается назад к репозиторию.
Приведенный ниже пример программного кода показывает реализацию набора правил Eligibility.
// Набор правил Eligibility получает учетную запись и вычисляет результаты приемлемости для
// различных программ
ruleset eligibility {
in Account account;
out List eligibilityResultsList = new ArrayList();
}
// вычислить приемлемость для программы 1, а затем - для программы 2
flowtask Program1_TaskFlow {
body = {
Program1_Setup;
Program1_Eligibility;
Program2_Setup;
Program2_Eligibility;
}
};
// Определить, какие правила являются установочными правилами для программы 1
ruletask Program1_Setup{
body = select(?rule) {
if("Program1_Setup".getTask(?rule) )
return true;
else
return false;
}
}
// Определить, какие правила являются правилами приемлемости для программы 1
ruletask Program1_Eligibility{
body = select(?rule) {
if("Program1_Eligibility".getTask(?rule) )
return true;
else
return false;
}
}
// Создать результат приемлемости (объект JAXB) для программы 1
rule Progam1.CreateEligibilityResult {
property task = " Program1_Setup";
when {
?account: Account();
?person: Person();
}
then {
bind ?result = new EligibilityResult ();
?result.setPersonId(?person.getPersonId());
?result.setProgramType(ProgramEnum.PROGRAM1);
?result.setEligible(Boolean.FALSE);
modify ?person { getEligibilityResults().add(?result); };
}
};
// простое правило делает ребенка приемлемым (для программы), если ему более
// 6 лет и возвращает результаты назад в карту finalResults
rule Program1.AgeQualification {
property task = " Program1_Eligibility";
when {
?person: Person(?age: getAge().intValue(););
evaluate(?age >= 6);
}
modify ?result {setEligible(Boolean.TRUE); };
finalResults.add(?result);
}
};
2. Предъявите набор правил как Web-сервис. Машины правил типа JRules предлагают инструментальные средства для генерации оболочек Web-сервисов или сеансовых бинов (Session Bin), чтобы создать оболочку для только что разработанного набора правил. Разработчики Web-сервисов будут способствовать созданию оболочки для предъявления набора правил как Web-сервиса.
Язык XML является ключевым стандартом для интеграции правил, EJB, потоков процессов BPEL и Web-сервисов. Язык BPEL естественно использует XML для обращения к данным, в то время как Web-сервисы используют его для преобразования данных в последовательную форму (и будут без модификации использовать его в вызовах Doc/Literal). XML может использоваться непосредственно в правилах. Путем выстраивания в определенном порядке (marshalling) XML может быть непосредственно преобразован в дерево объекта JAXB. Правила могут быть выполнены и для "родных" объектов Java.
Web-сервис должен импортировать XML Schema в соответствующие определения WSDL. Сгенерированные объекты DTO из XML Schema (например, JAXB), могут также помочь гарантировать, что данные оттранслированы беспрепятственно и без ошибок конвертирования.
Web-сервис Eligibility обеспечивает трансляцию из XML в JAXB, а затем вызывает Eligibility Rules Delegate Session Bean. Чтобы скрыть сложность вызова заказных библиотек JRules, следует создать фасадный метод (применяется при проектировании интерфейсов) сеанса. Такой подход делает реализацию "машины правил" "агностической" (то есть, не зависящей от типа операционной среды - прим. пер.), и система может быть легко перенесена к провайдеру новой машины правил. Eligibility Delegate Session Bean выполняет RMI-вызов фасадного метода Eligibility Session Bean. Этот сеансовый бин вызывает набор правил Eligibility в пакете RuleApp, используя ruleSession.executeRules("RuleApp/eligibility").
import ilog.rules.bres.session.IlrRuleExecutionResult;
import ilog.rules.bres.session.IlrStatelessRuleSession;
import ilog.rules.bres.session.ejb.IlrManagedRuleSessionProvider;
import ilog.rules.bres.session.util.IlrRuleSessionHelper;
.
.
.
public List assessEligibility(AccountRoot account) {
List eligibilityList = null;
// получить экземпляр не изменяющего состояния rulesession
IlrStatelessRuleSession ruleSession = null;
try {
ruleSession = IlrManagedRuleSessionProvider.getProvider()
.createStatelessRuleSession();
} catch (ilog.rules.bres.session.IlrRuleSessionCreationException ce) {
String msg = "Failed to retrieve RuleSession Provider";
throw new InfrastructureException(msg, ce);
}
// передайте borrower и credit как входные ("in") параметры
// не изменяющего состояния сеанса.
IlrRuleSessionHelper helper = new IlrRuleSessionHelper(false);
helper.addParameter("account", account);
try{
// выполните правила и обработайте результаты
IlrRuleExecutionResult res = ruleSession.executeRules("/RuleApp/ eligibility", null,
helper.getJavaClassResolver(this), helper.getParameters());
eligibilityList = (List)res.parametersOut.getHandle("finalResults").getValue();
} catch(Throwable t) {
String msg = "Failed to execute rule!";
throw new InfrastructureException(msg, t);
}
return eligibilityList;
}
3. Вызовите Web-сервис набора правил из BPEL. После того, как разработаны все заказные системные компоненты, для разработчиков наступает время интеграции системы с машиной BPEL. Унаследованные системы и новые заказные компоненты оркестрованы потоками процесса BPEL. Именно в это время должны быть разрешены проблемы с совместимостью, преобразованиями типов данных и протоколами Web-сервисов. Разработчики потока процесса и/или системные интеграторы могут реализовать потоки оркестровки в проектировщике процессов Oracle BPEL.
Например, используя приведенный ниже программный код, BPEL вызовет лежащий в основе Web-сервис Eligibility.
<assign name="setAccount">
<copy>
<from variable="BPELInput" part="payload"
query="/tns:EligibilityProcessRequest/tns:Account">
</from>
<to part="parameters"
query="/nsxml0:assessEligibility/nsxml0:Account"
variable="webservice_account"/>
</copy>
</assign>
<invoke name="CallEligibilityWebservice" partnerLink="EligibilityWebservice"
portType="nsxml0:EligibilityService" operation=" assessEligibility "
inputVariable="webservice_account" outputVariable="webservice_eligibilityResults"/>
Фаза сопровождения. Что касается фазы сопровождения - самой длительной фазы любого проекта - перенос бизнес-правил из кода Java в машину правил делает сопровождение намного более управляемым. Как я уже объяснял ранее, бизнес-менеджеры могут изменять правила во время выполнения, используя графический интерфейс, а бизнес-правила и процессы BPEL могут изменяться независимо друг от друга.
Выполнение JRules с помощью диспетчера процессов Oracle BPEL
Ясно, что для проектирования и разработки правил, Web-сервисов и процессов BPEL требуется несколько различных технологий. В этом разделе я хочу обсудить, как во время выполнения эти технологии совместно работают, чтобы выполнить Eligibility Process. Хотя этот пример базируется конкретно на диспетчере процессов Oracle BPEL и ILOG JRules, все сказанное будет применимо и ко многим другим средам.
Вызов машины правил происходит во всех трех уровнях (см. рисунок 4): BPEL вызывает Web-сервис правил, Web-сервис правил вызывает машину правил, код приложения машины правил получает входные данные и возвращает результаты.
Рисунок 4 Вызов машины правил в действии
В контексте нашего примера бизнес-процесса приложение вызывает процесс Eligibility с полезным грузом (payload) XML. Этот полезный груз содержит информацию об учетной записи, например атрибуты семьи. Процесс Eligibility, в свою очередь, вызывает Web-сервис Eligibility. Web-сервис Eligibility обеспечивает трансляцию из XML в JAXB и затем вызывает Eligibility Rules Delegate Session Bean. Последний взаимодействует с фасадным методом сеанса, используя RMI. Фасадный метод сеанса активизирует машину правил, которая затем вычисляет и возвращает процессу результаты приемлемости. Eligibility Process оценит возвращенные данные и назначит учетной записи Программу 1 или Программу 2. В нашем примере мы предлагаем для эксплуатации правил приемлемости удаленный сервер, но их можно было бы точно так же выполнить и локально. (Заметьте, что считается хорошим тоном не совмещать местонахождение сервисов, не обслуживающих процессы, с диспетчером процессов BPEL, чтобы обеспечить лучшую масштабируемость.)
Этот пример фактически иллюстрирует разделение бизнес-логики на правила, BPEL и Web-сервисы:
- Процесс Eligibility Process BPEL явно определяет шаги, которые должны быть выполнены на основании полученных данных Eligibility Results. Базируясь на Eligibility Results, процесс Eligibility Process BPEL будет вызывать различные ветви. Каждая из Программ 1 и 2 выполняет различные шаги, и эти шаги можно легко модифицировать, используя проектировщика BPEL.
- Web-сервис Eligibility выполняет среднезернистые (medium-grained, со средней степенью детализации) задачи для диспетчера процессов BPEL, который инкапсулирует механику того, как посылать корреспонденцию и ставить в очередь задачи. Web-сервис работает с итоговыми данными из общей модели данных, например, с ключами базы данных (типа учетной записи OID), которые могут быть использованы для извлечения детализированных данных для выполнения требующейся задачи.
- Правила Eligibility не изменяют первоначальных данных, и при этом они не обращаются к внешним источникам данных. Контрольный след (audit trail) машины правил тривиален, потому что у вас имеется точная запись данных в/из правила.
Специфика интеграции правил в платформу J2EE через Web-сервисы иллюстрируется на рисунке 5. Правила развернуты в автономном корпоративном архиве (ear - enterprise archive) EligiblityRules.ear и зарегистрированы консолью администратора машины правил. Остальная часть поддерживающей логики развернута в другом корпоративном архиве (EligibilityRuleService.ear), куда включены классы для объектов учетной записи JAXB, которые будут требоваться для EligibilityRules, и фасадный метод сеанса для вызова правил. Фасадный метод сеанса скрывает детали вызова заказных библиотек JRules, а также позволяет перенести систему к новому провайдеру машины правил.
Рисунок 5 Интеграция правил в платформу J2EE с помощью Web-сервисов
Заключение
В предложенном "рецепте" BPEL я представил стратегию распределения бизнес-логики по трем различным уровням: уровень бизнес-процесса, уровень Web-сервиса и уровень правил. Вы можете использовать эти дополняющие друг друга технологии, чтобы минимизировать взаимозависимости между данными и логикой. Однако, чтобы в полном объеме воспользоваться всеми преимуществами, архитектор должен выполнить строгий анализ, позволяющий разложить системные компоненты и спроектировать их, используя целесообразную технологию. В процесс разработки вовлекаются многочисленные технологии и различные роли. Чтобы принять участие в процессе разработки, необходимо предварительно идентифицировать соответствующие ресурсы. Получающаяся в результате архитектура является быстро перестраивающейся платформой, на которой бизнес-пользователи без вмешательства сотрудников службы ИТ обрабатывают большую часть бизнес-изменений.
Кевин Джеминиук [ kgeminiuc@yahoo.com ] в настоящее время работает старшим программным архитектором в Денвере. За последние 15 лет Кевин работал архитектором систем, техническим менеджером, разработчиком и инженером по разработке аппаратных средств. К числу технических интересов Кевина относятся SOA, RFID, AVL и генетическое программное обеспечение.