АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
partner Web services). В рассматриваемом примере бизнес-процесс работает с тремя сервисами: - Менеджер (ManagerService); - Компания А (CompanyAService); - Компания В (CompanyBService). Web-сервисМенеджер (ManagerService) имеетпорт типа EquipmentPurchcePT, через который при помощи операции GetPermission может быть получено разрешение на покупку. Операция возвращает разрешение или отказ в виде строки символов. Данный сервис является синхронным. Запрос помещается в сообщение PermissionRequestMessege, а ответ в сообщение типа PermissionResponseMessege. Web-сервис Компания А (CompanyAService)является асинхронным; поэтому он определяет два типа портов: первый – это PriceListАPT, который использует операцию GetPrice для проверки наличия оборудования и цены. Для возврата результата web-сервис определяет отдельный порт типа - CompanyACallbackPT. Этот тип порта определяет операцию CompanyACallback. Для пересылки результата используется сообщение типа PriceResponseMessage. Web-сервис Компания B (CompanyBService)такжеявляется асинхронным; поэтому он определяет два типа портов: первый – это PriceListВPT, который использует операцию GetPrice для проверки наличия оборудования и цены. Для возврата результата Web-сервис определяет отдельный порт типа - CompanyBCallbackPT. Этот тип порта определяет операцию CompanyBCallback. Для пересылки результата используется сообщение типа PriceResponseMessage. Хотя Web-сервисы Компания А и Компания В определяет по два типа портов, они реализует только по одному порту (PriceListАPT и PriceListВPT), а портыCompanyACallbackPT и CompanyВCallbackPTреализуется BPEL-процессом, который является клиентом этого Web-сервиса. Затем необходимо представить сам процесс приобретения оборудования как web-сервис, что можно сделать посредством составления его WSDL-описания. Процесс имеет порт типа PurchaseEquipmentPT. Для обращения к порту используется операция BuyEquipmentисообщение форматаBuyEquipmentRequestMessage. Кроме того, на стороне клиента должен иметься порт ClientCallbackPT, в который отправляется клиенту ответ, содержащий результаты обработки запроса. Для этого используется операция SendPurchaseInfo и сообщение типа BuyEquipmentResponseMessage. Следующим шагом является определение партнерских связей, которые определяют взаимодействия между BPEL-процессом и используемыми Web-сервисами. В рассматриваемом примере определим следующие типы партнерских связей: - purchaseLT - используется для описания асинхронного взаимодействия между клиентом и собственно BPEL-процессом и определяется WSDL-описанием BPEL-процесса; managerLT - используется для описания синхронного взаимодействия между BPEL-процессом и Web-сервисом «ManagerService»; companyALT - описывает асинхронное взаимодействие между BPEL-процессом и Web-сервисом «Компания А». Этот тип партнерской связи определен в WSDL Web-сервиса «CompanyAService»; companyBLT - описывает асинхронное взаимодействие между BPEL-процессом и Web-сервисом «Компания B». Этот тип партнерской связи определен в WSDL Web-сервиса «CompanyBService». За партнерской связью закрепляется одна или две роли. Для синхронных операций определяется одна роль, а для асинхронной – две роли. Для асинхронных операций первая роль описывает вызов операции клиентом, а вторая роль описывает процесс возвращения ответа на запрос, который обычно называют обратным вызовом (callback). Типы партнерских связей определяются в WSDL-описании в специальном пространстве имен (namespace). Для связи purchaseLT имеется две роли. Первая роль - роль описывает сервис, к которому обращается служащий. Клиент использует данный тип порта для того, чтобы связаться с BPEL-сервисом. Вторая роль описывает клиента, к которому обращается BPEL-процесс при реализации обратного вызова. Описание рассмотренных ролей выглядит следующим образом: Второй тип связи – managerLT используется для описания синхронной связи между BPEL-процессом и Web-сервисом «Менеджер» и определяется в WSDL-описании Web-сервиса менеджера. Поскольку взаимодействие синхронно, то только одна роль: Оставшиеся типы партнерских связей, companyALT и companyBLT, используются для описания асинхронных связей между BPEL-процессом и Web-сервисами «Компания А» и «Компания В». Для Компании А описание имеет вид: Для Компании В описание аналогично. BPEL-процесс работает следующим образом. BPEL-процесс запускается при поступлении входного сообщения от клиента. После этого происходит вызов сервиса Менеджер. Это синхронный вызов, поэтому выполнение процесса приостанавливается до получения ответа. После того как ответ получен, посылаются запросы к Web-сервисам Компании А и Компании В. Это асинхронные вызовы, которые выполняются параллельно. После того как ответы, содержащие информацию о стоимости требуемого оборудования, полученные предложения сравниваются по цене в рамках бизнес-процесса и выбирается лучшее предложение. Затем информация о выборе передается служащему. Рассмотренный выше алгоритм описывается в блоке, заключенном в теги Однако перед тем как описывать последовательность действий требуется определить переменные. Переменные (Variables). Переменные в BPEL-процессах используются для хранения и повторного использования значений, полученных в от сервисов. Для работы с сообщениями используется XPath. В рассматриваемом примере используются следующие переменные: EquipmentRequest; PermissionRequest; PermissionResponse; EquipmentDetails; АResponse; ВResponse; Response2employer. Для каждой переменной требуется определить ее тип. При определении переменных можно использовать типы, используемые в WSDL описаниях, а также простые типы XMLSchema. В рассматриваемом примере использованы для всех переменных типы WSDL-сообщений: messageType="prch: BuyEquipmentRequestMessage"/> messageType="prch:PermissionRequestMessage"/> выходные данные от менеджера --> messageType="prch: PermissionResponseMessage"/> messageType="cmp: PriceRequestMessage"/> messageType=" cmp: PriceResponseMessege"/> messageType="cmp: PriceRequestMessage"/> messageType=" cmp: PriceResponseMessege"/> BPEL процесса --> messageType="cmp: BuyEquipmentResponseMessage"/> Основная часть BPEL-процесса.Основная часть BPEL-процесса заключена в теги portType="prch:PurchaseEquipmentPT" operation="BuyEquipment" variable="EquipmentRequest" createInstance="yes" /> ... Далее требуется вызвать сервис Менеджер. Для этого требуется сформировать для него входное сообщение посредством копирования части сведений о требуемом оборудовании: ... ... Теперь может быть вызван сервис ManagerService. Для этого используется ... portType="prch:EquipmentPurchasePermissionPT" operation="GetPermission" inputVariable="PermissionRequest" outputVariable="PermissionResponse" /> ... Следующий шаг должен вызвать Web-сервисы обеих компаний. Для этого требуется подготовить входные сообщения (для простоты будем считать, что они идентичны для обоих сервисов). Сообщение PermissionRequest может состоять из нескольких частей, но нас будет интересовать только одна часть – тип оборудования, полученная из запроса клиента: ... ... Входные данные включают сведения, которые требуются Web-сервисам компаний. Поскольку они заданы в одном и том же формате, их можно передать непосредственно (используя простую копию). В реальной же ситуации обычно необходимо выполнить преобразование. Это можно было бы сделать, использовав либо XPath с выражением Теперь можно вызывать Web-сервисы компаний поставщиков. Для параллельного вызова сервисов применяется активность Результаты, полученные от компаний, сохраняются в переменных AResponse и BResponse соответственно: ... Web-сервиса Компании А и ожидание ответа --> portType="spl:PriceListAPT" operation="GetPrice" inputVariable="EquipmentDetails" /> portType="spl:FlightCallbackPT" operation="CompanyACallback" variable="AResponse" /> portType="spl:PriceListAPT" operation="GetPrice" inputVariable="EquipmentDetails" /> portType="spl:FlightCallbackPT" operation=" CompanyBCallback" variable="BResponse" /> ... На следующем шаге осуществляется выбор лучшего по стоимости предложения посредством использования активности ... B --> ... В элементе Если предложение от A лучше, чем от B, копия переменной AResponse помещается в переменную Response2employer. В противном случаекопируется переменная BResponse. Затем посредством использования активности ... portType="emp:ClientCallbackPT" operation="SendPurchaseInfo" inputVariable="Response2 employer" /> Средства разработки. Поскольку BPEL фактически представляет собой диалект языка XML, скрипт BPEL можно создавать либо вручную, либо, что более предпочтительно, воспользоваться одним из существующих программных инструментов для генерации скриптов. Скрипт BPEL - это документ XML, соответствующий структуре BPEL-документа. Он интерпретируется во время исполнения процессором BPEL, который выявляет ключевые слова и выполняет соответствующую обработку. Корректная и полная реализация стандарта BPEL должна поддерживать следующий набор стандартов Web-сервисов: WSDL 1.1, XML Schema 1.0, XPath 1.0, WS-Addressing, UDDI v2.0, WS-Security (необязательно). Среди свободно распространяемых программных продуктов, предоставляющих возможности генерации скриптов BPEL, можно выделить NetbeansBPELDesigner - компонент NetbeansEnterpisePack, представляющий собой бесплатное дополнение к NetBeans и добавляющий к его функциональным возможностям средства визуального проектирования приложений с сервис-ориентированной архитектурой. NetBeansEnterprisePack содержит средства для проектирования BPEL, схем XML, WSDL файлов, а так же средства обеспечения безопасности Web-сервисов. BPEL Designer позволяет оркестрировать Web-сервисы, а именно: создавать, разрабатывать, запускать и тестировать бизнес-процессы BPEL, соответствующие спецификации WS-BPEL 2.0. Кроме того, данный продукт предоставляет визуальные средства, позволяющие быстро и эффективно оркестрировать Web-сервисы в рамках бизнес-взаимодействия. Среди платных программных продуктов известен OracleBPELProcessManager (BPM) - инфраструктурное решение для проектирования, размещения и управления бизнес-процессами по стандарту BPEL. 11.6. Бизнес-правила Любая организация использует в процессе функционирования определенный набор законов, постановлений правительства, промышленных стандартов и корпоративных политик, которые в совокупности и называются называются бизнес-правилами (business rules). Наблюдение за их выполнением и соблюдением, может осуществляться как непосредственно людьми, так и ИТ-системами. Под бизнес-логикой обычно понимают совокупность правил, принципов, зависимостей, поведения объектов предметной области системы. Иначе можно сказать, что бизнес-логика применительно к ИC — это реализация правил и ограничений автоматизируемых операций. Термин «Бизнес-логика» часто используют как синоним термина «Логика предметной области» (Domain Logic). К бизнес-логике относятся, к примеру, формулы расчета ежемесячных выплат по ссудам (в финансовой сфере), автоматизированная отсылка электронного письма руководителю проекта по окончанию выполнения частей задания всеми подчиненными (в системах управления проектами) и т. п. Согласно определению Business Rules Group (1993), “бизнес-правило — это положение, определяющее или ограничивающее какие-либо стороны бизнеса; его назначение состоит в том, чтобы защитить структуру бизнеса, контролировать или влиять на его операции”. Целые методологии разработаны специально для создания и документирования бизнес-правил и их применения в ИС. Если не создается система, которая в значительной степени управляется бизнес-правилами, тщательно разработанная методология не нужна. Достаточно выявить и задокументировать относящиеся к системе правила и связать их с конкретными функциональными требованиями. Бизнес-правила берут начало вне контекста какой-либо конкретной ИТ-системы, а являются одним из главных источников функциональных требований к ИТ-системам, поскольку они определяют те возможности, которыми должна обладать система для выполнения правил. Не все организации рассматривают собственные важнейшие бизнес-правила как ценность, которой они являются на самом деле. Если эта информация не документирована и не хранится должным образом, то она существует только в головах сотрудников. Сотрудники и разработчики ИТ-систем могут по-разному понимать правила, в результате чего отдельные программные системы могут пo-разному выполнять одно и то же бизнес-правило. Если известно, где и каким образом приложение реализует относящиеся к нему бизнес-правила, то модифицировать приложения в случае изменения соответствующих правил гораздо проще. В больших организациях часто бывает очень трудно определить какое именно приложение ответственно за реализацию того или иного бизнес-правила. Создание общих правил и наличие централизованного хранилища бизнес-правил упрощает согласованную реализацию приложений, на которые эти правила влияют. Типы правил. Известны разные подходы к классификации правил. Схема простейшей классификации, показанная на рис. 11.6, выделяет пять типов бизнес-правил.  Рис. 11.6. Схема простейшей классификации, типов бизнес-правил Факты (facts) представляют собой верные утверждения о бизнесе, которые описывают связи и отношения между значимыми бизнес-терминами. Факты также называют инвариантами, т.е. неизменными истинами о сущности данных и их атрибутах. Бизнес-правила могут ссылаться на факты, однако факты обычно не преобразуются напрямую в функциональные требования к системе. Сведения о сущности, важных для системы, применяют в моделях данных, создаваемых аналитиком или архитектором. Можно привести следующие примеры фактов: - на каждом продукте имеется наклейка, на которую наносится уникальный штрих-код; - каждый сотрудник имеет пропуск; - каждый элемент заказа содержит данные о продукте и сроке поставки; - стоимость билетов не возвращается, если пассажир опоздал на рейс. Ограничения (constraints) определяют состав операций, которые может выполнять как отдельные пользователи, так и ИС. При описании ограничивающего бизнес-правила обычно используются следующие глаголы: должен, не должен, не может, которые могут встречаться в разных комбинациях: - постоянный читатель библиотеки может взять для прочтения до пяти книг; - при входе в зоопарк взрослый может провести бесплатно до двух детей; - все входы в медицинские учреждения должны соответствовать правительственным постановлениям, касающимся использования их людьми с ограниченными физическими возможностями. При реализации проектов в области создания ИС обычно имеется большое количество разных ограничений, например, менеджеры проектов должны соблюдать сроки поставок и лимиты бюджету. Ограничения уровня проекта фиксируются в документации по управлению проектом, а ограничения на проектирование и реализацию, уменьшающие доступные разработчику возможности, обычно записаны в спецификации требований к ИС или спецификации архитектуры. Активаторы операций (action enabler) можно определить как правило, при определенных условиях приводящее к выполнению каких-либо действий (action enabler). Правило может управлять программными функциями, либо действия могут выполняться вручную. Условия, определяющие начало выполнения операции, обычно формулируются в терминах булевой алгебры. Для этого бывает полезно использовать таблицы. В самом общем виде активатор можно описать выражением вида “Если < наступило определенное событие или выполняется некоторое условие >, то <что-то происходит>”. В качестве примеров активаторов могут служить следующие бизнес-правила: - если на складе имеются запрошенный покупателем товар, то его следует предложить запросившему товар лицу; - если на складе отсутствует запрашиваемый товар, то покупателю следует предложить оставить заявку; - если клиент заказал книгу по определенной тематике, то ему следует предложить другие книги по данной тематике, прежде чем принять заказ. Вычисления (computations) – это бизнес-правила, выполняемые с использованием математических формул и алгоритмов, при этом вычисления могут выполняться по внешним для организации правилам, например по формулам исчисления налогов. Бизнес–правила данного типа могут описываться разными способами: в форме текстового описания, в виде формул или в виде таблиц. Ниже дано несколько примеров бизнес-правил для вычислений в текстовой форме: - стоимость доставки товара составляет 10%, но не менее 300 рублей; - при покупке от 6 до 10 единиц товара, скидка составляет 3%, при покупке более 10 - 5%. Вывод (inference), — это правило, которое позволяет создавать новый факт на основе других фактов или вычислений. Часто вывод зачастую записывается в формате “если — то”. Следует отметить, что данный формат применяется также в активаторах операций. Разница состоит в том, что в случае вывода раздел “то” описывает не действие, а заключает в себе факт. Приведем несколько примеров выводов: - если поставщик не может поставить заказанный товар в течение 30 календарных дней с момента получения заказа, то заказ считается невыполненным; - если платеж не поступил в течение 5-ти банковских дней момента отправки счета, счет считается недействительным. Документирование бизнес-правил. Значительная часть бизнес-правил влияют на множество приложений, и поэтому в рамках организации целесообразно управлять этими правилами не на уровне отдельных проектов, а на корпоративном уровне. Если число используемых правил невелико, то для начала бывает достаточно простого каталога бизнес-правил, при увеличении числа бизнес-правил следует создать базу данных таких правил. По мере того, как при работе над приложением определяются новые правила, их добавляют в каталог, а не вписывать в документацию конкретного приложения или, что еще хуже, только в его код. По мере приобретения опыта выявления и документирования бизнес-правил можно переходить к использованию структурированных шаблонов для определения правил разных типов, в которых описываются образцы ключевых слов и разделов, позволяющих согласованно структурировать правила. Использование шаблонов упрощает хранение правил в базе данных и коммерческих инструментах для управления бизнес-правилами. Источниками правил могут быть корпоративные политики, политики менеджмента, профильные специалисты и прочие лица и документы, например, правительственные постановления, а также имеющийся код программных продуктов и определения баз данных. Стандарты. На момент написания книги нет единого стандарта на формат бизнес-правил, однако разработан целый ряд сопутствующих стандартов, наиболее известными из которых являются следующие: OMG Business Motivation Model (BMM), определяющая применение стратегии, процессов и правил в бизнес-моделирования; OMG Semantics of Business Vocabulary and Rules (SBVR), ориентированный на бизнес-ограничений; OMG Production Rule Representation (PRR) Предназначенная для описания правил для продукционных систем; W3C Rule Interchange Format (RIF) - семейство языков бизнес-правил для межсистемного взаимодействия. Альтернативные подходы использованию бизнес-правил. Возможны различные подходы к использованию бизнес-правил при построении ИТ-систем. Можно выделить следующие основные подходы: бизнес-правила используются для формирования требований к системе на этапе проектирования; бизнес-правила «зашиваются» в программный код; используется интерпретатор бизнес-правил; бизнес-правила встраиваются в приложения, реализованные средствами ЯВУ; бизнес-правила встраиваются в bpel-файлы. Если в организации, занимающейся разработкой ИТ-систем, имеется репозитарий бизнес правил, то разработчики систем могут использовать его при формировании требований к разрабатываемым ИТ-системам. После того как требования сформулированы в терминах бизнес-правил, то в процессе проектирования конкретной системы оно трансформироуется в некоторое другое описание, например UML описание. В ряде случаев, естественным является описание функционирования системы в терминах правил. Например, если требуется разработать программу для проверки знания таблицы умножения учащимися младших классов, то можно очень быстро написать такую программу, например, на языке С++ и она будет служить много лет. Прямо противоположный подход состоит в том, чтобы правила не зашивать в код, а хранить их в виде строк в отдельном файле и интерпретировать их с помощью интерпретатора. Подобный подход реализуется при построении экспертных систем, таких как CLIPS [153,154]. Пользователь или разработчик, желающий создать экспертную систему, приобретает оболочку и самостоятельно или с помощью эксперта наполняет ее правилами, которые затем обрабатываются интерпретатором, входящим в состав оболочки. В процессе эксплуатации правила можно легко добавлять или изменять. Возможность приобрести оболочку освобождает разработчика от необходимости разрабатывать собственный интерпретатор. Использование подобных систем ориентировано, прежде всего, на создание систем использующих только правила. Можно выделить смешанные подходы, когда модули, отвечающие за работу с правилами, встраиваются в код, написанный на ЯВУ или в код, описывающий бизнес-процесс. Примером системы, позволяющей совместно использовать Java код и правила, является система Jess [155]. В качестве примера систем, позволяющих использовать правила в системах управления бизнес-процессами, можно привести такие продукты как ILOG JRules и JBoss Drools [156, 157]. Системы управления бизнес-правилами. Под системами управления бизнес-правилами (Business Rule Management System, BRMS) обычно понимают ИС, предназначенные для поддержки и выполнения бизнес-правил организации.  Рис. 11.7. Типовая структура управления бизнес-правилами Типовая структура управления бизнес-правилами включает (рис. 11.7): сервер исполнения бизнес правил; среду разработки бизнес-правил; подсистему тестирования бизнес-правилами; среду управления бизнес-правилами; репозитарий бизнес-правил. Сервер исполнения бизнес правил (Business Rule Engine), который иногда называют движком исполнения бизнес-правил представляет собой компонент системы управления бизнес-правилами, в функции которого входит выполнение (интерпретация) правил. Можно считать, что сервер исполнения бизнес правил предоставляет сервисы принятия решений, которые могут вызывать внешние приложения. Типовой сервер исполнения бизнес-правил реализует следующие основные функции: исполнение правил; горячее развертывание правил; публикацию наборов правил, в частности, в виде веб-сервисов; управление наборами правил; сбор статистики по выполнению правил. Среда разработки бизнес-правил представляет собой графическую среду, предназначенной для разработки и публикации бизнес-правил. Обычно это среда, поддерживающая режим групповой работы. Среда разработки ориентирована на разработчиков и интеграторов, но не на бизнес-пользователей. Подсистема тестирования бизнес-правил позволяет разработчикам выполнять валидацию бизнес-правил. Среда управления бизнес-правилами в отличие от среды разработки предназначена для бизнес-пользователей, не являющихся ИТ-специалистами. Это может быть, например, менеджер, отвечающий за продажи. Репозитарий бизнес-правил представляет собой хранилище бизнес-правил, доступ к которому осуществляется через среду разработки и среду управления. Обычно поддерживается работа с версиями. В самом общем виде функционирование системы управления бизнес-правилами выглядит следующим образом. На этапе разработки при формулировании требований к ИТ-системе определяются возможности системы по настройке парамеров функционирования в терминых бизнес-политик. Например, при разработке системы управления продажами одним из требований может являться обеспечение возможности для конечного пользователя системы (менеджера) реализовывать политику типа: Покупатель, который совершил единовременную покупку на определенную сумму, должен быть переведен в более высокую категорию. Для того, чтобы бизнес-пользователи могли редактировать и писать новые правила, на этапе разработки создается словарь бизнес правил. Этот процесс иногда называют вербализацией (verbalization). Вербализация предполагает создание объектной бизнес-модели (business object model, BOM), которая может строиться на основе, например, объектной модели, определенной в Java проекте. Бизнес-политика представляет собой совокупность нескольких правил. Бизнес-правила являются формализацией бизнес-политики, представленной в форме последовательности "if-then" утверждений, например: If the customer's category is Silver and the value of the customer's shopping cart is more than $500 Then change the customer's category to Gold If the customer's category is Gold and the value of the customer's shopping cart is more than $1000 Then change the customer's category to Platinum После того как правила разработаны, они компануются в исполняемый модуль и его можно вызывать как единую сущность. Если используется СОА, а бизнес процессы реализуются на языке bpel, то сервер исполнения бизнес правил представляет собой сервис принятия решений, на вход которого поступает SOAP послание. Каждое обращение к серверу исполнения бизнес правил можно представить как выполнения одного или нескольких условных операторов. Если менеджер в некоторый момент времени решит, что для получения платиновой карты достаточно совершить покупки только на $700, то он может откорректировать эту цифру через доступную ему среду управления бизнес-правилами. Обычно это делается с помощью графического конструктора. Перед пользователем появляются список правил, отдельные поля которых он может редактировать, при этом не требуется не только перерабатывать код, но даже не требуется перезагружать систему. Если по результатам эксплуатации системы, появится идея дополнить политику еще одним правилом, в соответствии с которым покупателю имеющему серебряную карту и истратившему $1200 сразу выдается платиновая карта, то пользователь открывает конструктор правил и с помощью одного из доступных ему шаблонов создает новое правило, посредством выбора значений элементов нового правила из выпадающего списка, что также можно сделать без перепрограммирования системы. Для конкретных систем данный процесс может отличаться, однако принципиальным является то, что бизнес-пользователь может в определенных пределах изменять поведение системы без внесения изменений в код. Практически все системы управления бизнес-правилами обеспечивают доступ к репозитарию бизнес-правил не только не только через GUI, но и позволяют делать это с помощью API, что позволяет, например, добавлять правила, полученные автоматически, например, с помощью систем извлечения знаний. Преимущества от использования бизнес-правил. Использование бизнес-правила потенциально позволяют достигнуть следующих преимуществ: уменьшение времени разработки; оперативная реакция на изменения требований; возможность повторного использования кода; снижение стоимости разработки и владения ИС. Контрольные вопросы 1. Охарактеризуйте понятие сервисно-ориентированная архитектура. 2. Охарактеризуйте понятие сервис. 3. В чем состоит идея микросервисной архитектуры? 4.Каковы основные достоинства и недостатки микросервисной архитектуры? 5. Что такое REST? 6. Что такое Web-сервисы? 7. Что такое XML? 8. Каковы основные правила построения XML документа? 9. Что такое DTD и XSD? 10. Что такое XML-RPC? 11. Что такое SOAP, какова структура SOAP послания? 12. Что такое WSDL? 13. Какова структура WSDL описания? 14. Что такое UDDI реестр? 15. Какова структура UDDI описания? 16. Что такое бизнес-реестр ebXML? 17. Что такое WS-*? 18. Что такое BPEL? 19. Раскройте содержание понятий оркестровка и хореография веб-сервисов. 20. Каким образом в BPEL описываются асинхронное и синхронное взаимодействия? 21. Какова структура BPEL-документа? 22. Что такое партнерские связи? 23. Что такое бизнес-правила? 24. Приведите классификацию бизнес-правил? 25. Охарактеризуйте системы управления бизнес-правилами? |