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

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

---

объектов, и с верификацией правил протоколов. Контроллеру все равно, с кем ведется разговор, с базовой службой или с композитной.

Итак, имеется четкое различие между внутреннейкомпозициейи

внешнейкоординациейсетевых служб.

3. Композиционные модели сетевых служб

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

В качестве первого шага определения композиционной модели обычно вводятся следующие определения:

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

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

• 
  Модельданныхидоступакданным. Определяет методы описания
  

данных и обмена данными между компонентами.

• 
  Модель выбора службы. Определяет способ статической или динамической привязки, то есть, каким образом в качестве компонента выбирается та или иная конкретная служба.
  
• 
  Транзакции. Определяет, какая транзакционная семантика может быть
  

---

ассоциирована с композицией и как это делается.

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

1. 1   ...   28   29   30   31   32   33   34   35   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(ответить), которая будет посылать ответ клиенту.
  

---