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

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

Поставщик служб


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

---

2. 1   ...   19   20   21   22   23   24   25   26   ...   36

---

Внешняя архитектура сетевых служб

Внешняя архитектура включает три важных компонента:

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

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

• 
  Инфраструктуракомпозициислужботносится к набору
  

программных инструментов, полезных при определении и выполнении композитных служб.

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

---

, размещаются в разных местах, а это усложняет ситуацию.

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

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

Компания А (запрашивающий службу) Компания Б (поставщик службы)

	сетевая служба
промежуточный слой сетевой службы (внутренний)

клиент сетевой службы
промежуточный слой сетевой службы (внутренний)

оя
Рис.4.6.Внешняяархитектурасетевыхслужб.

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

---

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

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

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

5. 1   ...   20   21   22   23   24   25   26   27   ...   36

---