Архитектура распределенных систем программного обеспечения. Учебное пособие издано при поддержке образовательной программы Формирование

• Название: Учебное пособие издано при поддержке образовательной программы Формирование
• Анкор: Архитектура распределенных систем программного обеспечения
• Дата: 13.01.2023
• Размер: 1 Mb.
• Имя файла: mdwrbook.docx
• Тип: Учебное пособие; #885216
• страница: 33 из 36

Компонентная модель

Типы компонентов, включаемых в сетевую службу, и предположения, делаемые о них, в существенной степени отличают одни

службы от других. Одна крайность заключается в том, что модель может предполагать, что компоненты реализуют определенный набор стандартов сетевых служб, например, HTTP, SOAP, WSDL и WS-Transaction. Такие предположения снижают гетерогенность системы. Другая крайность заключается в ограничении самыми общими предположениями. Например, можно ограничиться лишь тем, что компоненты взаимодействуют, обмениваясь XML-сообщениями синхронно (в стиле RPC), либо асинхронно. Модель становится более общей, но следствием может стать усложнение работы по созданию службы.

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

В настоящее время наиболее перспективный язык композиции BPEL предполагает, что компонентами являются службы, описанные на WSDL. Он также полагается на другие стандарты, вроде XPath и WS-Addressing. Будущие версии могут быть интегрированы с протоколом WS-Transaction.

2. Оркестровая модель

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

Предположим, поставщик сетевой службы позволяет заказчикам размещать заказы вызовом операции заказТовара. Поставщик, реализованный на основе технологии композиции служб, выполняет операцию, вызывая другие службы. Его бизнес логика, следовательно, определяется композиционной схемой. На Рис. 5.6 приведена оркестровка композиционной схемы, моделируемой средствами диаграмм активности унифицированного языка моделирования UML. Диаграммы активности являются наиболее широко используемой парадигмой моделирования, как в традиционных рабочих потоках, так и в сетевых службах. В этой парадигме предполагается, что оркестровки от начала выполнения до самого конца определяются описанием последовательности операций.

Бизнес логика сетевой службы, рассматриваемой в качестве примера, такова: когда заказчик вызывает операцию заказТовара, организуется новый запуск композитной службы, которая вызывает операцию проверитьСклад, выполняемую локальной сетевой службой. Эта операция используется поставщиком для проверки наличия товара на складе. Если

товар обнаружен, поставщик подтверждает заказ заказчику вызовом операции подтвердитьЗаказ, которая выполняется сетевой службой заказчика. В противном случае поставщик входит в контакт с оптовым складом и проверяет наличие товара там. Если товар на складе есть, следует подтверждение заказчику, в противном случае заказ не принимается.




Рис.5.6.Модель сетевойслужбыпоставщикав видедиаграммы активности.

Пунктирнымилиниямиотмеченыотношениямежду(внутренними)активностямии

(внешними)протокольнымисообщениями.

Диаграмма Рис.5.6 предполагает, что активности всегда моделируют уведомления о сообщениях (получение сообщений), приходящих к (поступающих от) сетевой службе:

• 
  Уведомления о сообщениях другим сетевым службам (вызовы односторонних операций, предлагаемых компонентами сетевых служб) моделируются средствами активности send(послать), например, send отменитьЗаказ в примере. Такие активности не являются блокирующими.
  
• 
  Обращения к синхронным (запрос/ответ) операциям, предлагаемым
  

другой сетевой службой, моделируются активностью invoke (вызвать), в примере - invoke проверитьСклад. Эта активность является блокирующей, поскольку она ждет ответа от вызываемой службы.

• 
  Получение сообщений, относящихся к компонентам служб, вызывающим односторонние или двухсторонние операции, предлагаемые композитной службой, моделируются активностью receive (получить), например, receive заказТовара. Это тоже блокирующие активности, поскольку выполнение композитной сетевой службы не может быть продолжено до получения сообщения.
  
• 
  Если полученное сообщение вызывает двухстороннюю операцию, композиционная схема будет включать активность reply(ответить), которая будет посылать ответ клиенту.
  

старт при получении нового заказа


начало

поиск на складе выполнен (наСкладе) [наСкладе=false]/start "invoke проверитьВозможностьПоставки"

/start "invoke проверитьСклад"
поиск продуктов на складе

поиск на складе выполнен (наСкладе) [наСкладе=true]/start "send подтвердитьЗаказ"

поиск продуктов у другого поставщика

поиск на внешнем складе выполнен (поставкаВозм) [поставкаВозм=false]/start "send отменитьЗаказ"
заказ отменен


поиск на внешнем складе выполнен (поставкаВозм) [поставкаВозм=true]/start "send подтвердитьЗаказ"

заказ подтвержден

Рис.5.7.Описаниепроцессаспомощьюдиаграммысостояний.

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

Существуют альтернативные способы описания оркестровой модели. Диаграммысостояний. Этот формализм основан на расширенной автоматной схеме, что дает возможность определять активности, выполняемые при входе в состояние, при выходе из него или при нахождении в состоянии. Диаграммы состояний также описывают события, условия и действия, связанные с переходами, например, определяют переход, который нужно сделать при возникновении события, если истинно некоторое условие. В этом случае выполняется также и связанное с состоянием действие. Имеются и другие расширения, которых так много, что почти стирается грань между диаграммами состояний и

диаграммами активностей (Рис.5.7).

НАЧАЛО (при вызове операции заказТовара)
invoke проверитьСклад
ВОШЛИ НА СКЛАД

invoke проверитьВозможностьПоставки

наСкладе=false нет операции

наСкладе=true
ОБРАТИЛИСЬ К ВНЕШНЕМУ ПОСТАВЩИКУ

send отменитьЗаказ

поставкаВозм=false
ВЫПОЛНЕНО

(ОТКАЗ)
нет операции

поставкаВозм=true

ГОТОВЫ ПОСЛАТЬ ПОДТВЕРЖДЕНИЕ

send подтвердитьЗаказ

ВЫПОЛНЕНО

(ПОДТВЕРЖДЕНИЕ)

Рис.5.8.Описаниепроцессаспомощьюсети Петри.

Сети Петри. Оркестровая модель, базирующаяся на сетях Петри, объединяет две парадигмы – диаграммы активности и определение состояний процесса с помощью диаграммы состояний. Свойства сетей

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

5.8 приведен все тот же пример, но в виде сети Петри. Некоторые переходы помечены логическими предикатами, управляющими переключением состояний. На основе сетей Петри создано несколько коммерческих моделей и исследовательских прототипов.

π-исчислениеесть алгебра процессов, на основе которой созданы современные языки композиции, например, язык BPEL. π-исчисление можно рассматривать как попытку разработки формальной теории моделирования процессов, аналогичной той, которую реляционная алгебра предлагает для реляционной модели. Как и в случае сетей Петри достоинством модели является наличие точного и хорошо изученного формализма, который способен верифицировать свойства изучаемого процесса.

С точки зрения оркестровой модели π-исчисление вводит конструкции для композиции активностей в терминах последовательного, параллельного или условного выполнения. Запись А.В означает, что активность А происходит раньше активности В, А|В означает, что А и В происходят параллельно, А + В означает, что выполняется либо А, либо В (выбор недетерминирован), а запись [переменная=значение]А означает, что А выполняется, если и только если переменная имеет указанное значение. В примере на Рис. 5.9 дано описание процесса закупки на основе облегченного синтаксиса.

A=receiveЗаказТовара, invokeПроверитьСклад B=[поставкаВозм=false]sendОтменитьЗаказ+

[поставкаВозм=true]sendПодтвердитьЗаказ C=invokeПроверитьВозможностьПоставки.В
Закупка=А.( ([наСкладе=false]C) +

([наСкладе=true]sendПодтвердитьЗаказ)

)

Рис.5.9.Описаниепроцессаспомощьюπ-исчисления.

Иерархии активностей(Рис. 5.10) представляют собой еще один подход к описанию оркестровки. В этой модели процессы описываются в виде постоянно уточняемой активности верхнего уровня с помощью дерева активностей. Конечные узлы (листья дерева) представляют собой фактически исполняемые активности, а промежуточные узлы определяют порядок следования активностей более низких уровней.

обработатьзаказ

sequence

invoke

проверитьСклад

наСкладе=false

перейтипопоискуна складе

choice

наСкладе=true
send

подтвердитьЗаказ

^{поставкаВозм=true} поставкаВозм=false


send

подтвердитьЗаказ


send

отменитьЗаказ



Рис.5.10.Описаниепроцессаспомощьюиерархииактивностей.

Эта формализация не очень практична и недостаточно интуитивно понятна разработчикам, как из-за необходимости осуществлять "искусственные" шаги, так и из-за необходимости думать в терминах хронологического порядка следования шагов (что эквивалентно применению при разработке иерархии и раскрытии левых поддеревьев метода "сначала вглубь"). У этой модели имеются и достоинства. Создаваемая структура позволяет взглянуть на оркестровку с разных уровней абстракции: более высокие уровни абстракции располагаются ближе к корню дерева, более детализированные уровни могут получаться постепенным перемещениям к листьям. Это естественным образом делает определение модульным, позволяя вести параллельную разработку процесса разным группам разработчиков.

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

указанное действие. В таких случаях говорят, что модель следует парадигме событие-условие-действие.

В качестве реактивной системы можно рассматривать композиционный мотор, который реагирует на сообщения, получаемые клиентами или другими системами (события) продвижением по оркестровой схеме (которая может включать и условия) и, соответственно, отправкой других сообщений (действия). На Рис. 5.11 приведен все тот же пример оркестровки, записанный с помощью правил. Хотя правила записаны в некотором порядке, между ними нет отношения упорядоченности.

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

ON receive заказТовара

IF true

THEN invoke проверитьСклад;

ON complete(проверитьСклад) IF (наСкладе==true)

THEN send подтвердитьЗаказ;

ON complete(проверитьСклад) IF (наСкладе==false)

THEN invoke проверитьВозможностьПоставки;

ON complete(проверитьВозможностьПоставки) IF (поставкаВозм ==true)

THEN send подтвердитьЗаказ;

ON complete(проверитьВозможностьПоставки) IF (поставкаВозм==false)

THEN send отменитьЗаказ;

Рис.5.11.Описаниепроцессаспомощьюправил.

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

Недостатком модели является трудность понимания логики процессов, описанных большим числом правил.