Майстерня Oracle: Cервис-орієнтований підхід в розробці бізнес-правил (A Services-Oriented Approach to Business Rules Development), Комерція, Різне, статті

Джерело: www.oracle.com/technology/pub/articles/bpel_cookbook/geminiuc.html

Стаття 1 із серії “SOA Best Practices: The BPEL Cookbook “-” Кращі методи SOA: Кулінарія BPEL ” ( 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, то ви можете завантажити його копію 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).

Приклад, як Європейське Космічне Агентство використало можливості та домени

Частина 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” ви дізнаєтеся, як скоротити витрати на супровід і завдяки орієнтованому на сервіси підходу до розробки бізнес-правил та управління поліпшити організаційну гнучкість.





Завантажте для цієї статті
Oracle BPEL Process Manager and Designer


Багато організацій від об’єктно-орієнтованої парадигми управління бізнес-процесами рухаються в напрямку до сервіс-орієнтованого підходу; безсумнівно, сервіси стають фундаментальними елементами розробки додатків. У той же самий час, мова виконання бізнес-процесів (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-сервісів заявляє наявні функціональні можливості прикладного рівня як сервіси. В такому разі багато бізнес-процесів можуть багаторазово використовувати ці сервіси, виконуючи, тим самим, зобов’язання сервіс-орієнтованої архітектури (SOA).

Web-сервіси реалізують функціональну логіку і логіку предметної області. Функціональні методи зазвичай не міняють свого стану в процесі виконання (stateless) і є середньозернистими (medium-grained). Web-сервіси можуть, наприклад, утримувати сервісні методи, операції з об’єктами і запитальні методи для системних даних. Ви можете реалізовувати Web-сервіси, використовуючи багато технологій, і приховувати відмінності між платформами реалізації. Таким чином, цей рівень добре підходить для:


Рівень правил. Машина правил зазвичай є будинком (місцем зберігання) для складної логіки, яка використовує безліч взаємозалежностей між об’єктами і залежать від порядку логічні обчислення. Виділення бізнес-правил як окремого від бізнес-процесу об’єкта призводить до кращого роз’єднання системи, що згодом збільшує зручність супроводу.

Машини правил дозволяють обчислювати набори правил паралельно і в послідовному порядку. Крім того, правила мають можливість обчислювати значення вхідних і проміжних даних і визначати, чи спрацювати правило. Такий модульний дизайн забезпечує більш просте і більш зручне в супроводі рішення, ніж традиційний процедурний код Java.

Крім того, як я згадував раніше, правила декларативні і дозволяють бізнес-аналітикам редагувати графічний інтерфейс користувача на високому рівні. Сучасні машини правил виконуються надзвичайно швидко і забезпечують вбудовану реєстрацію аудиту. Типові риси рівня правил:


Оскільки в рівні Web-сервісів правила пред’являються як сервіси, вони можуть бути багаторазово використані для всіх міжкорпоративних додатків, спрощуючи розробку та інтеграцію нових додатків.

Розробка та супровід

Щоб проілюструвати процес розробки, ми будемо використовувати приклад бізнес-процесу, який називається Eligibility Process (процес прийнятності). Цей процес оцінює, чи годиться сім’я для участі в певній програмі охорони здоров’я. В залежності від атрибутів сім’ї (дохід, загальне число дітей), цей процес відносить родину до Програми Охорони здоров’я 1 або до Програми Охорони здоров’я 2. Під час фази аналізу логіка групується в різні блоки в залежності від її мінливості і складності. Як обговорювалося в попередньому розділі, правила зазвичай моделюють складні повертаються структури, що вимагають багаторазових бізнес-перевірок правильності, а також політики, які часто змінюються або зачіпають великі частини організації. Навпаки, процеси для підрозділів або окремих організацій моделюються в рівні бізнес-процесу.

Типовий процес розробки включає три кроки:


  1. Створіть правила в наборі правил
  2. Пред’явіть набір правил як Web-сервіс
  3. Викличте 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-сервіси:


Специфіка інтеграції правил в платформу 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 і генетичне програмне забезпечення.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*