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

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

Модель данных и доступа к данным

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

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

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

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

Передача данных. Для передачи данных между активностями, существуют два подхода: журнальный подход и подход явного потока данных. Журнальный подход аналогичен традиционным языкам программирования: все данные, используемые в сетевой службе, должны явно именоваться и перечисляться. Журнал – это набор всех переменных, в который активности (обращения к операциям) заносят свои результаты, откуда они берут свои входные параметры. Модификации переменных выполняются при получении сообщения "атомарно", прежние значения переменных стираются. Активности могут иметь разный уровень доступа к

переменным (чтение/запись или только чтение). Каждый запуск активности заводит свой отдельный журнал, как каждый запуск программы заводит свой набор переменных.

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

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

4. Модель выбора службы

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

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

Самый простой способ выбора службы – вставка указателя на нее (URL) в спецификацию композитной службы, что эквивалентно статическому связыванию. Особенно этот способ полезен при построении прототипов и тестировании композиций. Очевидный недостаток –

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

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

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

Как и в спецификации CORBA, и в других традиционных системных платформах, композиционные модели могут проводить динамическое связывание не только на уровне целых служб, но и на уровне отдельных операций. Такой подход называется динамическим выбором операции. Например, при организации дальних поездок активность "заказ билетов" может обращаться к разным операциям (и к разным службам), в зависимости от того, хочет ли заказчик ехать автобусом, поездом, лететь на самолете или плыть на корабле. Выбор можно моделировать на оркестровом уровне, вводя условия активации одной из нескольких активностей, определяющие выбор на основе предпочтений заказчика. Этот подход усложняет оркестровку, которой, при росте вариантов выбора становится трудно управлять. Более гибкое решение связано с

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